api/cli compatability between juju minor versions

[Andrew Wilkins]

On Sat, Jul 26, 2014 at 4:49 AM, William Reade <william.reade at canonical.com>
wrote:

> On Sat, Jul 26, 2014 at 7:56 AM, Curtis Hovey-Canonical <
> curtis at canonical.com> wrote:
>
>> Ladies and Gentlemen.
>>
>> The Juju QA meet with Robie Basak to discuss backporting juju 1.20.x
>> to trusty. Robie was planning to supersede 1.18.1 with 1.20.2. I
>> suffered an anxiety attack.
>>
>> My current understanding is that we promise API/CLI compatibility
>> between one minor version and the next. Features are can be
>> deprecated, and they can be removed in the next minor release. Thus
>>   1.18.1 > 1.20.2 will work
>>   1.18.1 > 1.21.0 may not work
>>
>
> I'm rather bothered that this notion still has currency. We could get away
> with that in the past, but juju is in trusty, and we can't go breaking
> people now. Any significant changes to the CLI or API need to be saved up
> for a juju 2.0.
>
> It's fine to add new features, so long as they fail gracefully when
> attempted against older environments -- but if you're removing or changing
> an API, or removing or changing the meaning of a command line flag, you are
> Doing It Wrong. Developers, team leads, since there has apparently been
> some lack of clarity: be told, again, loudly:
>
> Thou Shalt Not Break Compatibility With 1.18. We Are Stuck With It.
>
> This scenario outline what can happen:
>>
>>     An enterprise machine uses trusty and juju 1.18.1 It manages several
>>     permanent 1.18.x environments [1]. The machine also has several juju
>>     scripts to create and destroy juju envs to do ephemeral work.
>>     The machine doesn't get package updates from 1 year.
>>
>>     Package updates are enabled; juju 1.25.0 is installed. The users of
>>     the machine didn't see the package was updated, they know nothing of
>>     the new features. Can they still manage there eternal 1.18.x envs? Do
>> the
>>     automated scripts continue to create and destroy ephemeral envs [2]
>>
>> As Ubuntu promises stability within a series, we cannot replace a well
>> understood juju with newer version of juju that redefines or removed
>> features.
>>
>> I know that the client is responsible for provisioning during
>> bootstrap and add-machine. Redefinitions of behaviours can happen. I
>> think they already have. For example, I see
>>     commit 5d0c7aeb7d3049672df587cb11f455465cce4a57
>>    [bug=1302005] cmd/juju: deprecate --series, added --upload-series
>> introduced in 1.19.2 as a planned change. 1.20.2 still supports
>> --series. I can see that 1.21-alpha1 still supports --series, but when
>> is --series obsoleted?
>>
>
> I don't think we can drop --series.
>
> I also don't think any juju code can ever be relied upon to provision any
> juju version different to itself, which may indicate a subtle bug around
> client add-machine for the manual provider... Andrew, do you think it could
> be reasonable to push that into the provisioner? We'd need to distribute
> the env public key to the machines being added, but that doesn't seem like
> the end of the world...
>

The client asks the server for the script to execute to provision the juju
agent. I don't think there's a problem. We *could* move manual provisioning
mostly server-side; the client would be responsible for ensuring the
machine is set up for passwordless ssh and sudo, and then call an API to do
the rest. This is not in 1.18, so it's not that useful right now.

If Juju is going to promise api/cli compatibility support for more
>> than 1 minor version, how long do we support? 2 years? Precise is more
>> than 2 years and we see the series is still popular.
>>
>
> LTS. 5 years. I tend to abbreviate this in casual conversation as
> "forever" because it seems to put people in the right mindset.
>
> Eventually, Juju will want to break compatibility, maybe it will need
>> to. Ubuntu will need to create co-installable packages. Users will
>> knowingly install newer version of juju to get new features. Old
>> versions will still be installed an usable. User can reinstall old
>> versions if they discover compatibility issues they cannot mitigate
>> quickly.
>>
>
> Those breaks should be saved up for major version upgrades.
>
> Cheers
> William
>
>
>>
>> [1] We know that trusty 1.18.1 client users are deploying and
>> upgrading envs to 1.18.4. We know these version are compatible
>>
>> [2] The new envs will be 1.24.x
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> 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/20140728/c03c7bf5/attachment.html>