Date
1 - 9 of 9
When will dea be replaced by diego?
James Bayer
you can use diego today in place of DEAs.
diego requires the other cf components other than DEAs and Health Manager.
toggle quoted message
Show quoted text
diego requires the other cf components other than DEAs and Health Manager.
On Sun, Sep 6, 2015 at 11:49 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
Hi,
Is there any plan when dea will not be supported and be replaced by diego?
Can I push application into diego without CF alongaside?
Any help will be appreciated.
Thanks,
Maggie
--
Thank you,
James Bayer
Thank you,
James Bayer
Layne Peng
I think what he ask is, when the Diego-release will merge to cf-release. And also no need to install cf cli diego plugin, no need to enabe-diego to your app, then start. For the https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline . it is said to be mid-september, is it right?
Matthew Sykes <matthew.sykes@...>
The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.
With that, I'm not in product management but, in my opinion, the definition
of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.
That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
toggle quoted message
Show quoted text
no longer seem relevant.
With that, I'm not in product management but, in my opinion, the definition
of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.
That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:
I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com
Matthew Sykes
matthew.sykes(a)gmail.com
Thanks Matthew for the additional details and pointers. It seems that the
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?
Guillaume.
On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?
Guillaume.
On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.
With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.
That said, the current path towards that goal has us going to a single API
server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management (James
and Amit are in a better position to comment) but the current direction
appears to be to break down Cloud Foundry into a number of smaller
releases. We already have a cf-release, garden-release, and diego-release
as part of a diego deployment but there are others like an etcd-release
that the MEGA team is managing and a uaa-release that the identity team
have done. These are all pieces of a new deployment strategy that was
proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com
Matthew Sykes <matthew.sykes@...>
Hi Guillaume. The proposal document was created by Amit and I had assumed
it was public. I'll try to make sure he sees this chain today so he can
address it. Sorry to send a unusable link.
toggle quoted message
Show quoted text
it was public. I'll try to make sure he sees this chain today so he can
address it. Sorry to send a unusable link.
On Tue, Sep 8, 2015 at 3:02 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:
Thanks Matthew for the additional details and pointers. It seems that the
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?
Guillaume.
On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:The notes you're pointing to were a straw man proposal; many of the dates
no longer seem relevant.
With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.
That said, the current path towards that goal has us going to a single
API server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management
(James and Amit are in a better position to comment) but the current
direction appears to be to break down Cloud Foundry into a number of
smaller releases. We already have a cf-release, garden-release, and
diego-release as part of a diego deployment but there are others like an
etcd-release that the MEGA team is managing and a uaa-release that the
identity team have done. These are all pieces of a new deployment strategy
that was proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged into
cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's the
first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:I think what he ask is, when the Diego-release will merge to cf-release.
And also no need to install cf cli diego plugin, no need to enabe-diego to
your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com
--
Matthew Sykes
matthew.sykes(a)gmail.com
Matthew Sykes
matthew.sykes(a)gmail.com
Amit Kumar Gupta
Done, anyone with the link should be able to comment now.
Best,
Amit
On Tuesday, September 8, 2015, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
Best,
Amit
On Tuesday, September 8, 2015, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
Hi Guillaume. The proposal document was created by Amit and I had assumed
it was public. I'll try to make sure he sees this chain today so he can
address it. Sorry to send a unusable link.
On Tue, Sep 8, 2015 at 3:02 AM, Guillaume Berche <bercheg(a)gmail.com
<javascript:_e(%7B%7D,'cvml','bercheg(a)gmail.com');>> wrote:Thanks Matthew for the additional details and pointers. It seems that the
deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?
Guillaume.
On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matthew.sykes(a)gmail.com');>> wrote:The notes you're pointing to were a straw man proposal; many of the
dates no longer seem relevant.
With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and API
versioning. We feel it's necessary to maintain continuous operation across
deployments. In particular, we want to be sure that operators can perform
forward migration with minimal down time before it becomes the default
backend in production. We're currently referring to that target as v 0.9.
That said, the current path towards that goal has us going to a single
API server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management
(James and Amit are in a better position to comment) but the current
direction appears to be to break down Cloud Foundry into a number of
smaller releases. We already have a cf-release, garden-release, and
diego-release as part of a diego deployment but there are others like an
etcd-release that the MEGA team is managing and a uaa-release that the
identity team have done. These are all pieces of a new deployment strategy
that was proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged
into cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's
the first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com
<javascript:_e(%7B%7D,'cvml','layne.peng(a)emc.com');>> wrote:I think what he ask is, when the Diego-release will merge to
cf-release. And also no need to install cf cli diego plugin, no need to
enabe-diego to your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matthew.sykes(a)gmail.com');>
--
Matthew Sykes
matthew.sykes(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matthew.sykes(a)gmail.com');>
Thanks a lot Matthew and Amit, the document can now be publicly
accessed/commented.
Guillaume.
toggle quoted message
Show quoted text
accessed/commented.
Guillaume.
On Tue, Sep 8, 2015 at 4:09 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
Done, anyone with the link should be able to comment now.
Best,
Amit
On Tuesday, September 8, 2015, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:Hi Guillaume. The proposal document was created by Amit and I had
assumed it was public. I'll try to make sure he sees this chain today so he
can address it. Sorry to send a unusable link.
On Tue, Sep 8, 2015 at 3:02 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:Thanks Matthew for the additional details and pointers. It seems that
the deployment strategy proposal mentionned in [2] is lacking read/comment
permissions. Any chance to fix that ?
Guillaume.
On Tue, Sep 8, 2015 at 2:07 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:The notes you're pointing to were a straw man proposal; many of the
dates no longer seem relevant.
With that, I'm not in product management but, in my opinion, the
definition of "done" and "ready" are relative.
The current bar that the development team is focusing on is data and
API versioning. We feel it's necessary to maintain continuous operation
across deployments. In particular, we want to be sure that operators can
perform forward migration with minimal down time before it becomes the
default backend in production. We're currently referring to that target as
v 0.9.
That said, the current path towards that goal has us going to a single
API server Diego[1]. With this change in architecture, the scaling and
performance characteristics will probably change. While it's likely these
changes won't have measurable impact to smaller environments, it remains to
be seen what will happen with the larger deployments operated by public
providers. This is where the whole notion of "replacement" starts to get a
bit murky.
As for "merging into cf-release," again, I'm not product management
(James and Amit are in a better position to comment) but the current
direction appears to be to break down Cloud Foundry into a number of
smaller releases. We already have a cf-release, garden-release, and
diego-release as part of a diego deployment but there are others like an
etcd-release that the MEGA team is managing and a uaa-release that the
identity team have done. These are all pieces of a new deployment strategy
that was proposed[2] a few months ago.
Given that path, I don't know that diego-release will ever be merged
into cf-release; it's more likely that it will be stitched into the
"cf-deployment" described in that proposal.
So, to your question, the 0.9 release may be cut in September. That's
the first release that operators will be able to roll forward from without
downtime. If you want Diego to be the default backend without having to
mess with plugins and configuration, you can already do that today via
configuration[3].
[1]: https://github.com/onsi/migration-proposal
[2]:
https://docs.google.com/document/d/1Viga_TzUB2nLxN_ILqksmUiILM1hGhq7MBXxgLaUOkY/edit#heading=h.qam414rpl0xe
[3]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/aea2a53b123dc5104c11eb53b81a09a4c4eaba55/bosh-templates/cloud_controller_api.yml.erb#L287
On Mon, Sep 7, 2015 at 2:08 PM, Layne Peng <layne.peng(a)emc.com> wrote:I think what he ask is, when the Diego-release will merge to
cf-release. And also no need to install cf cli diego plugin, no need to
enabe-diego to your app, then start. For the
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline
. it is said to be mid-september, is it right?
--
Matthew Sykes
matthew.sykes(a)gmail.com
--
Matthew Sykes
matthew.sykes(a)gmail.com