Hey vcap-dev,
Diego’s march towards production-readiness continues. I wanted to send a quick update to the list with some resources and with some information about some upcoming features that we’ll be adding. Apologies for the length of this e-mail!
We’ve created github.com/cloudfoundry-incubator/diego. This is a simple landing page that directs you to various Diego-related resources. We ask that any general Diego-related issues be opened on this repo.
In particular, I’d like to highlight two things:
In terms of timelines we have a number of features still to go to close the gap between Diego and the DEAs. More importantly we are working through a suite of performance tests to validate that Diego will scale to the initial targets we have in mind (we hope to support ~400 Cells at first and to have a vision for hitting the low 1000s of Cells). We anticipate that the results of these performance tests will lead us to make several breaking changes and would like these to land before calling Diego ready for production. As that time approaches we will let the list know. For now Diego remains in beta.
During the beta period we will not be making strong uptime guarantees during a Diego deploy. In fact some deploys may require manual intervention. Diego compeletely supports downtimeless rolling deploys at this time, however we’re reserving the right to break backward compatibility instead of burdening the cost of making all our changes backward compatible during the beta period.
These are likely to land during the beta period.
Diego does not currently support the cf files
API. We plan to resolve this by broadening the scope of access to the containers and giving developers the ability to have full SSH access into running containers. Along with this will come the ability to:
If there is interest I would be happy to provide the architectural details in a separate e-mail. And, yes, we plan on making SSH access configurable (by space & application) so that operators can disable it if they desire. If it proves feasible we are also considering enabling/disabling SSH access at a finer grained level (e.g. allow SCP but not console access).
There are stories in Diego’s tracker backlog. Search for the ssh
label.
We plan on extending Diego and the CC API to support Placement Constraints. The idea here is relatively simple: individual Diego cells can be assigned arbitrary tags and users can specify a PlacementConstraint
(simply a set of tags) on their applications. Diego will ensure that only Cells that have the tags associated with the application’s PlacementConstraint
will host the application.
We plan on modelling this like the ApplicationSecurityGroups
are modelled. PlacementConstraints
are specified by a CF admin on a per-space basis. We will support different PlacementConstraints
for staging vs running. We will allow setting a blanket default PlacementConstraint
that will apply when none is specified.
For our first iteration we will only support PlacementConstraints
that specify tags that must be present on a host Cell. One can imagine extending this to specify tags that are preferred or that should be disallowed.
If you’d like to learn more - there are stories in Diego’s tracker backlog. Search for the +placement-constraints
label.
Thanks for reading! As always, feedback is welcome :)
Onsi
Hi onsi,
I too am interested in the design of ssh feature. Can you share it please.
Thanks
Shashi
--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/2102f87e-9922-4057-8fba-eda37d858b4f%40cloudfoundry.org.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAOQcXyWwEMCiZev1DibMhUP6KOf6zy-gB%3D-5k2ksJcEdJGL9fw%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sXw9ResevYrJw3T0ymrArXmmY3TLHKTr_CpJ7SJCoX53A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CACA2FRzKQM5fbha9Ab1YScVQXvBjiXBqfMui2sxNNzFB%2BY_b3A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/65091a29-921e-46fb-866a-b432214415c1%40cloudfoundry.org.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-zj4c8YnfNt06zkUsMo%2BuRPyt5i8GEQrK4JDUiE1PUwNA%40mail.gmail.com.
Question about Placement Constraints. One of our requirements for this is the need to control which placement tags a router can route instances too. For example, If we have 2 tags "internal" and "DMZ" we'd like to have a router in our DMZ zone only route traffic to instances tagged at "DMZ".
This sounds pretty straightforward and could be a follow-on feature thought it’s not going to part of the first iteration on the PlacementConstraint
s.
Also with placement constraints will you support an application being able to specify multiple tags and if so will diego attempt to evenly divide instances across the multiple tags? Or will we only support a single tag for an app and force the user to create multiple apps with the same route if they want an app in more than one pool?
You may specify multiple tags on an application but these will be AND
ed together. To be clear: if an app has tags [alpha, beta]
then it will only be scheduled on Cells that have both alpha
and beta
tags. Diego will find the set of Cells that satisfy this constraint and then distribute the application evenly among those Cells. To be double clear: if you have some Cells tagged alpha
and others tagged beta
the application will not be placed. While we could make the logic a bit more complex and include the ability to OR
tags together I’d prefer to keep the first pass simple.
With that said, it sounds like part of the problem you are trying to solve is to ensure that an application is spread out across different pools of Cells. We currently support this using zones. Cells can be assigned a zone (typically an availability zone though you are free to interpret this as you wish) and Diego will do tis darndest to distribute application instances for a given app across zones. This behavior plays nicely with the PlacementConstraint
s we’re proposing. Cells with that satisfy a PlacementConstraint
may span multiple zones. Diego will find those Cells and then distribute the application across zones. In a sense you could think of zones as a special kind of tag that the end-user specify in in a PlacementConstraint
— Diego knows to distribute across zone
tags.
Onsi
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDrfE4kTri-Jc0w2gznSk3g-dXwYDKkoW0Mp3uZgQq_7ag%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-wH5v3vG0Xx-o30RXOnqTJupWT9mt9%3DDWzbt4f9TDtVcw%40mail.gmail.com.
Thanks for the clarifications Onsi. I think the functionality you describe regarding tags and zones will work well for what we have in mind.I understand that full pinning of a router to a Placement(s) isn't in the current plans. However, if the opportunity arises to help this functionality along, like perhaps adding placement data to published route data, it would be great if you could give it some consideration.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDqmZFZQ6xw8c2gHANYtjx--X3B1dSCmtpT7K_OgGyuQxw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-xSGk9gRWmeV6pUNdmdYLi371tEtET-GBQW_HsKi-v4iA%40mail.gmail.com.
Hi Phil,
Hi Onsi, Matthew,Thanks for the great update! Sorry, a bunch of questions at once, which are mainly things I spotted going through the Trackers for these new features.
https://www.pivotaltracker.com/n/projects/1003146/stories/90748242Is this link broken or is it private? https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/accepted_proposals/placement_pools.md
It’s a private link that the team uses to communicate internally.
> As a consumer of Diego, I can craft an LRP that allows me to spin up an SSH daemonNoticed, on this ticket there is lot of chatter about https://github.com/cloudfoundry/cfdreddbot but I can't access that. What is this repo?
cfdreddbot monitors the various CF repos and asks contributes to sign the CLA (if necessary).
> Changing the PlacementConstraint associated with a space is allowed. At this point the applications in the space need to be restarted but CC has no way to orchestrate this. The same issue exists with the Application Security Groups.Could you clarify why the CC has no way to orchestrate restarting the applications of space? Is it just that the functionality to gracefully migrate the app instances to other Cells does not exist?
There are three classes of changes that can happen to an app:
stack
, updating the application bits, changing the allocated memory)CC, today, relies on the client to orchestrate changes in the first two categories. For example, when you cf scale -m XX
the cf client creates a new set of application instances with the desired memory, waits for them to come up, then shuts the older, smaller, instances down. Similarly, when you cf push
the cf client stops the existing application, stages the new one, then launches the new application (hence the need to orchestrate a blue-green deploy independently via separate applications).
Onsi
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAC8vboyDOJmxTpVja3RO7_M7_S8sSH15dBsZ34hFa0B1SXrRHQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAFwdB-wdkf8%2B6oD3s2xeu1QvJP2BCOmDz-h2BSpZMyNoqW1P3w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/F47E6FFE-5C2D-4325-9296-3E9F3369D14B%40activestate.com.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CANbAaBTDkAETWPAz33OXyKEzG92%2B3VKUDe_oPh6ioGV3X9uQqA%40mail.gmail.com.
cf files
API. We plan to resolve this by broadening the scope of access to the
containers and giving developers the ability to have full SSH access
into running containers.--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/3ad54432-0d44-456e-8a49-0e070a529a54%40cloudfoundry.org.
To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.
--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sUyd1Q6uQhS5xO508y_aebWqQTzoRcPEX%3DzVpgk7c796g%40mail.gmail.com.