<div dir="ltr"><div><div>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.<br><br></div>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.<br><br></div><div>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.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 12:13 PM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can't we just as easily provide tools to find out what version of Juju provides a particular feature? Certainly a CLI of:<div> $ juju supported-features</div><div>  leader-election</div><div>  container-addressibility</div><div><br></div><div>Or even possibly something that talks to something like the charm-store:</div><div> $ juju known-features</div><div> leader-election: juju >= 2.2</div><div> container-addressibility: juju >= 2.0</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>John</div><div>=:-></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 7:01 PM, Horacio Duran <span dir="ltr"><<a href="mailto:horacio.duran@canonical.com" target="_blank">horacio.duran@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ideally we will provide tools for the user to determine this, unless I understood wrongly the requirement.<br><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding <span dir="ltr"><<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<p dir="ltr">Rick</p>
<div class="gmail_quote"><div><div>On Dec 15, 2014 11:51 AM, "Nate Finch" <<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>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.<br><br>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.<br><br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">last copy of context to juju-dev<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard <span dir="ltr"><<a href="mailto:adam.collard@canonical.com" target="_blank">adam.collard@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On 15 December 2014 at 15:06, Marco Ceppi <span dir="ltr"><<a href="mailto:marco.ceppi@canonical.com" target="_blank">marco.ceppi@canonical.com</a>></span> wrote:</span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div></blockquote><div><br></div></span><div>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).<br><br></div><div>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.<br></div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div></span><div>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.<br><br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>Agreed.</div></div></div></div>
</blockquote></div></div>
</div></div></blockquote></div></div>
<br></div></div><span><font color="#888888">--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></font></span></blockquote></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div></div>
</div></div><br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div></div>