Bundles proposal

[Richard Harding]

On Thu, 19 Jun 2014, Benjamin Saller wrote:

> Some of my recent work with charming Cloud Foundry has led us towards a
> slightly different understanding of bundles. In the case of something like
> cloud foundry the topology will change between releases of their code, in
> version 'b' they might add a new service that 'a' didn't have and in 'c'
> they might replace two existing components with a new one that subsumes
> them. In cases like this being able to preserve identity in the runtime is
> a very interesting feature of 1st class bundle support. Right now a bundle
> IsA topology but in our depiction it HasA topology. While I have no proof
> that service spanning identity that survives mutation is general enough to
> inform these requirements it really is something we want to deal with.

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 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.

--

Rick Harding

Juju UI Engineering
https://launchpad.net/~rharding
@mitechie