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
|
|
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
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
|
|
|
|
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
-- Matthew Sykes matthew.sykes(a)gmail.com
|
|

Guillaume Berche
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@...>
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
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
|
|
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 <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');>
|
|

Guillaume Berche
Thanks a lot Matthew and Amit, the document can now be publicly accessed/commented.
Guillaume.
toggle quoted message
Show quoted text
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
|
|
Thanks Matthew. Very detail reply. :) It seems the all-in-one release won't come out soon.
|
|