On Fri, 20 Jun 2014, Cory Johns wrote: > 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.
This is a move into the Juju store, which is slightly different from juju-core. It's more about storage and the ability to juju publish a bundle and we'll have to look at some form of juju deploy of the bundle, though that creeps into the realm of replacing the deployer and is another chunk of work. I don't think that the scope of work at this time can look into the full featured stacks with tracking the changes/upgrades over time. > 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. Yes, I think we agree that the feature set of full stacks would be useful, but that's beyond the current scope of work at this time. Thanks for checking out the proposal. -- Rick Harding Juju UI Engineering https://launchpad.net/~rharding @mitechie -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
