On Wed, 23 Jul 2014, Gustavo Niemeyer wrote: > Going back to bundles, not having to update a bundle when a new, > entirely different, release of Ubuntu comes out, is of course much > more expressive, and people love expression, but carries with it a > relevant semantic load. It also means neither we nor anybody else has > any idea about what people actually get when they deploy a bundle, and > whether the bundle will even work tomorrow once a new major upgrade is > pushed to the repository. Our focus should not be to encourage that, > but to help people express what they mean clearly and easily. If they > want a new release of the bundle with a slightly different meaning, > that should be trivial, but it should not be trivial to express lack > of clarity.
I think it's important to look at this from the viewpoint of the effort required to have the non-specific charm definition in a bundle. - If the user builds their bundle from the Juju GUI all charms are completely qualified. Series, name, and version are at a firm definition and the bundle is completely safe to redeploy and is repeatable. - If the user exports an existing live environment, the above is true as well. Everything is firmly qualified. - If the user hand constructs a bundles.yaml file they are able to type whatever they desire into that `charm:` field. I would argue that it's quite reasonable for the user to be able to copy/paste a command line target and expect it to work just as their `juju deploy` cli did. - If the user were to take a bundles.yaml from the GUI and proceeds to edit it to remove the series specifier, they're expressing their desire explicitly and it's something we know stakeholders require (ecosystem team). Give this, the vast majority of bundles are fully qualified. In the JAAS scenaraio, where users are building bundles through the webui and they're stored directly, we can encourage/enforce qualified names by controlling the UI interaction. However, we want to maintain the escape hatch for the stakeholders that require it. If we want to remove this support then we need to involve them in a process to come together, agree on the decision, and update our existing tools to not permit it. > > We also have to worry about historical usage as we've always supported the > > vague behaviour and many of the current of bundles take advantage of it. > > Yes, bundles were very organically developed. But I won't re-raise that rant. Ok, I'll let history be history. However, if you have any feedback on bundles I'd love to have a chance to hear your thoughts as our team is working on moving bundles and their definition to the charmstore and will bring up moving to being a first class juju-core entity in Nuremburg. -- Rick Harding -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
