There was a big discussion about this in Brussels, and the conclusion was that we should not do per-feature flags in the metadata, because the list of all flags becomes too large too fast, and too hard to understand for people using charms.
That is not to say that we can't have a list of features and the version at which they're available to help charm authors figure out the right min version to set. Your idea of having juju talk to the charm store to get that info sounds great. It's an interesting idea to get jujud to enable/disable features to simulate older versions of Juju so you don't accidentally use features that exist in newer versions of Juju than your charm specifies.... but that sort of seems like something that's beyond the scope of this project. On Mon, Dec 15, 2014 at 12:13 PM, John Meinel <j...@arbash-meinel.com> wrote: > > Can't we just as easily provide tools to find out what version of Juju > provides a particular feature? Certainly a CLI of: > $ juju supported-features > leader-election > container-addressibility > > Or even possibly something that talks to something like the charm-store: > $ juju known-features > leader-election: juju >= 2.2 > container-addressibility: juju >= 2.0 > > I'm personally on the side of having charm *authors* talk about the > features they want. Because then in juju-world we can enable/disable > specific features based on them being requested, which makes charm authors > get the features they need right. (e.g., if the charm doesn't say it needs > leader-election, then it doesn't get leader tools exposed.) > > min-version, otoh, leads to people just setting it to the thing they are > using, and doesn't give Juju a way to smartly enable/disable functionality. > It also suffers from when we want to drop a feature that didn't turn out > quite like what we thought it would. > > John > =:-> > > > > On Mon, Dec 15, 2014 at 7:01 PM, Horacio Duran < > horacio.du...@canonical.com> wrote: >> >> Ideally we will provide tools for the user to determine this, unless I >> understood wrongly the requirement. >> >> >> On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding <rick.hard...@canonical.com >> > wrote: >> >>> Then we should take up the burden to help others realize that their code >>> will work with older versions of juju. Perhaps I am assuming, but if I am a >>> charm author and I am wondering what my minimum version of juju is I will >>> select the one I am currently using. Running tests and older versions are >>> not something I'm going to do want to take up the burden on. This means >>> that users of juju will have a smaller set of charms available to them >>> because of this declaration even though it may actually work. >>> >>> Rick >>> On Dec 15, 2014 11:51 AM, "Nate Finch" <nate.fi...@canonical.com> wrote: >>> >>>> OK, so, many people in juju-core have talked about this with Eco, and >>>> we came to the conclusion that per-feature flags would be way too confusing >>>> for the charm consumer. When I want to deploy a charm, I don't wnat to >>>> have to figure out what version of juju supports leader election so I can >>>> know if the charm I want is supported by my version of juju. I just want >>>> to see a min version and compare it to my version of juju. >>>> >>>> This does put a little more burden on charm authors, to do that >>>> translation themselves, but they would need to be able to do that anyway to >>>> understand what versions of juju support their charm. This way we at least >>>> take that burden off the person deploying the charm. >>>> >>>> Also, we very specifically only support min version. This just means >>>> we'll need to be backwards compatible. There won't be leader election 2.0 >>>> that makes 1.0 not work. >>>> >>>> On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch <nate.fi...@canonical.com> >>>> wrote: >>>>> >>>>> last copy of context to juju-dev >>>>> >>>>> On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard < >>>>> adam.coll...@canonical.com> wrote: >>>>>> >>>>>> On 15 December 2014 at 15:06, Marco Ceppi <marco.ce...@canonical.com> >>>>>> wrote: >>>>>> >>>>>>> I'm against this idea, what if something changes in the >>>>>>> implementation of leader_election? Now there's a requirement to track >>>>>>> version of features released and complexity grows. >>>>>>> >>>>>> >>>>>> Well if that were to happen, the charm author would have to know >>>>>> which version of Juju they need anyway? In fact the version based >>>>>> tracking >>>>>> of this makes it even worse, let's for the sake of argument assume that >>>>>> leader election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in >>>>>> Juju 1.24.0. If the charm is using the "1.0 model" they have to say "I >>>>>> require Juju >= 1.22.0 and < Juju 1.24.0". In the capability model they >>>>>> simply state "I require a Juju capable of leader_election_2" (or some >>>>>> other >>>>>> better token that describes the change in a semantic way). >>>>>> >>>>>> I think the capabilities based model can easily extend into a >>>>>> provider based constraint as well. So the charm can say "I require >>>>>> container addressing" and MAAS Provider will be fine but everything else >>>>>> will fail as per the current spec. Using a capabilities model is more >>>>>> expressive and can be extended. Using version numbers is clunky. >>>>>> >>>>>> >>>>>>> It seems much easier (testing and comprehension-wise) to have the >>>>>>> author say "Won't work unless you have this version of Juju or higher". >>>>>>> This makes testing, linting, and other typical charm author actions >>>>>>> simpler >>>>>>> while yielding virtually the same result. >>>>>>> >>>>>> >>>>>> I don't think manually mapping features to Juju versions is simple >>>>>> for anyone now, let alone the expanded base of charm authors that we're >>>>>> targetting. >>>>>> >>>>>> >>>>>>> As for your use case of "bugs in juju break user experience" is an >>>>>>> already existent risk and can be improved in other ways that I think are >>>>>>> outside the scope of this. >>>>>>> >>>>>> >>>>>> Agreed. >>>>>> >>>>> >>>> -- >>>> Juju-dev mailing list >>>> Juju-dev@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>>> >>>> >>> -- >>> Juju-dev mailing list >>> Juju-dev@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
