Versioning of libjuju

[John Meinel]

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.collard at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170119/3404ea52/attachment.html>