Bundles proposal

[Cory Johns]

On Thu, Jun 19, 2014 at 6:52 PM, Richard Harding
<rick.harding at canonical.com> 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.