I'd like to give some feedback about how Juju should be using Facades and versioning and how I'd expect it to be expressed in the client code.
As a base statement, my feeling is that if I write some code that talks (via a bunch of intermediates) to Juju on the other end, there is going to be a certain set of constructs that I know how to handle, that are true at the time I write the code. (eg, AddCharm takes the URL of a charm to import.) If Juju ends up changing how a particular API functions (say by adding a new parameter that is mandatory), if you haven't actually made changes to your client to handle that new information, calling the new API is just asking for trouble in one way or another. So the versioning that we do for Juju is each Facade is independently versioned, but with the intent that all Versions that are exposed in an official release we will maintain compatibility. So if Client v1 supports AddCharm in Juju 2.0, then you should be able to call exactly the same Client.v1.AddCharm in Juju 2.1 and have it do all the things that it did in 2.0. Someone who compiles their app against at the point in time where 2.0 is released, should grab the list of facades for 2.0, and then the Login negotiation should always be asking for the 2.0 compatible version numbers. I think tracking known versions in libjuju and then negotiating vs the Juju API it connects to is good, but some of that will inherently need to be exposed to the user of libjuju. Some things ultimately need to be known to the Application. If we add the ability to decorate your instances with custom tags in Juju 2.2, then when libjuju connects to a Juju 2.0 server, the Application needs to find out from libjuju that it won't be able to do the decorating. Other things might be optional fields that the Application isn't actually using, in which case libjuju will pass them with appropriate defaults to 2.2 but they aren't supplied, abort with a clear error if they are supplied but talking to a version that doesn't support them, but happily call the old version if they aren't passed. The other option is that the Application directly asks libjuju to operate in (eg) 2.0 mode. So libjuju has cached the list of Facade Versions for 2.0 and expressly negotiates exactly those versions with the server, and presents the libjuju client side as a 2.0 client. Arguably if you want that, you could just grab the 2.0 version of libjuju, and not update your libjuju until your App is ready to make use of 2.1 features. Degrading gracefully is a little hard, and generally means you have to involve a human in the analysis, rather than just grabbing the facade description and representing that as a Python object. I'm happy to discuss more directly how we've tried to approach it in Go code, and see where that might be helpful for Python developers. There are a few places where Python gets to benefit from things like named optional parameters that we don't have the same luxury in Go. John =:-> On Wed, Jan 18, 2017 at 11:38 PM, Adam Collard <adam.coll...@canonical.com> wrote: > Hi all, > > Something that came up at today's Juju Show[0] was how versioning of > libjuju should work. Should we have 1:1 releases of libjuju with associated > Juju's (I'm -1 - it could get very messy very quickly) or can we have one > libjuju version talking with multiple Juju versions? > > As far as I understand it, the way that libjuju uses generated code from > the Golang source makes it non-trivial to generate dynamically from a > remote connection. > > Strawman: what if we split the current generated blob[1] into each facade, > and further into each facade version. libjuju is constantly updated with > the stubs of latest facade version from Juju releases as they come out. > When libjuju connects, it does a negotiation to work out what's the latest > facade version that both it and the remote API know about. > > Thoughts? > > Adam > > [0] https://www.youtube.com/watch?v=Lsbo7f7yMxY > [1] https://github.com/juju/python-libjuju/blob/master/ > juju/client/_client.py > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
