Bundles proposal

[Richard Harding]

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