On Thu, Jun 19, 2014 at 6:52 PM, Richard Harding <[email protected]> wrote: > On Thu, 19 Jun 2014, Benjamin Saller wrote: > Haven't we talked about this type of content as a different data type > though than a bundle? Is this something we should work towards at this > time?
I think that is what Ben is talking about, that as we move bundles into the core as first-order entities, that is the correct time to address expanding their scope to include the additional functionality we have realized they should cover. >> I also understand that in some world views a bundle would represent a >> supportable collection of services and this might imply the topology is >> fixed but any complex system that evolves is likely to have some topology >> mutation. While we can manage this without first class support it would be >> difficult to expect the GUI to the the 'right' thing for our project unless >> bundles include this idea. > > I'm not sure I completely follow here. The idea is to get a model for a > topology definition. In the GUI we can allow users to deploy the toplogy in > 'ghost' form and then mutate it before submitting it to the environment to > construct it. If we move the idea of the uncommitted state down into juju > core then the same idea could be possible via cli invocation of a bundle. > I'm not sure why bundles have to include the idea of mutation itself. I'm > nervous about things that make bundles not able to be reused as much as > possible because they cannot stand alone. What we've found that we need from a "stack" (ere bundle) is the ability to encapsulate the intelligence to handle upgrades that include modifications to the topology, providing logic to perform the transition on an existing system, while retaining the overall identity of the bundle. As a concrete example, with CF we are in the position that we expect an upgrade from one CF release to the next to potentially include splitting an existing service into two distinct services, or merging two existing services into a single new service. We can sometimes handle the former case by simply having the charm be responsible for both new services, but that isn't always ideal, and it still doesn't cover the second case. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
