juju min version feature

Mon Dec 15 17:13:55 UTC 2014

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.duran at 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.harding at 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.finch at 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.finch at canonical.com>
>>> wrote:
>>>>
>>>> last copy of context to juju-dev
>>>>
>>>> On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard <
>>>> adam.collard at canonical.com> wrote:
>>>>>
>>>>> On 15 December 2014 at 15:06, Marco Ceppi <marco.ceppi at 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 at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141215/c19aacd1/attachment.html>