Do not land code on blocked branches

[John Meinel]

Just going off the bits that Ian pointed to, the section of code was if you
called ServiceDeploy with a CharmStore URL (eg cs:mysql) but you had not
already called AddCharm.

The "juju" cli client already knows to call Client.AddCharm with the given
URL, whereas the internal api/client/client.go does a double check if it
gets called with a charm URL that isn't already in state.

Now, I don't know how Quickstart would be triggering
apiserver/client/client.go
The error here: in traceback looks like:
connecting to wss://
52.6.157.186:17070/environment/47724da5-9b38-4141-8f92-03d8f4225de9/api
environment type: ec2
bootstrap node series: trusty
charm URL: cs:trusty/juju-gui-27
requesting juju-gui deployment
juju-quickstart: error: bad API response: charm "cs:trusty/juju-gui-27" not
found
2015-05-01 18:28:59 ERROR Command '('juju', '--show-log', 'quickstart',
'-e', 'aws-quickstart-bundle', '--constraints', 'mem=2G', '--no-browser',
'/var/lib/jenkins/repository/landscape-scalable.yaml')' returned non-zero
exit status 1
Traceback (most recent call last):
  File "/var/lib/jenkins/juju-ci-tools/quickstart_deploy.py", line 51, in
run
    for step in self.iter_steps():
  File "/var/lib/jenkins/juju-ci-tools/quickstart_deploy.py", line 70, in
iter_steps
    self.client.quickstart(self.bundle_path)
  File "/mnt/jenkinshome/juju-ci-tools/jujupy.py", line 335, in quickstart
    self.juju('quickstart', args, self.env.needs_sudo())
  File "/mnt/jenkinshome/juju-ci-tools/jujupy.py", line 294, in juju
    return subprocess.check_call(args, env=env)
  File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
    raise CalledProcessError(retcode, cmd)


So it would appear that we had code to allow users to call
Client.ServiceDeploy(cs:mysql) and the server would lookup the charm and
deploy it for the user, but we stopped doing that as a Juju CLI since 1.16.

However, I think this is *our* bad because this is a very important client
(quickstart and probably others) that has been relying on this behavior in
all our recent releases.

Compat with juju-cli != compatibility with Juju API users.

AFAIK we don't have a great way to respond to clients that behavior is
deprecated, but we can bump the Version of the API and change the behavior.
We definitely should have done that here rather than just remove the
behavior.

John
=:->

On Sun, May 3, 2015 at 3:59 PM, Richard Harding <rick.harding at canonical.com>
wrote:

> On Sun, 03 May 2015, Ian Booth wrote:
>
> > >
> > > Curtis has filed three new bugs for these so far, and there appears to
> > > be one or two more to come:
> > >
> > > <https://bugs.launchpad.net/juju-core/+bug/1450912>
> >
> > The issue here is that quickstart is relying on Juju 1.16 behaviour.
> There was a
> > block of code with a comment:
> >
> > // Remove this whole if block when 1.16 compatibility is dropped.
> >
> > The code block was removed because 1.18 was our minimum compatibility
> version.
> > But it seems we have to restore the 1.16 behaviour. Note that this is
> not an
> > upgraded environment where we need to retain compatibility with older
> > deployments. It is a fresh 1.24 install which should be able to rely on
> 1.18 and
> > later behaviour only.
>
> Ian, can you be more specific on the chunk of code that was removed or
> branch I can look at for this? I'll happily file a bug and update
> quickstart, we just need to know what's changed there. Having a branch in
> hand or a bug will assist us in getting that updated as fast as possible.
>
> In searching through the quickstart code there's no hard requirement or
> notes on 1.16.
>
> Thanks
>
> --
>
> Rick Harding
>
> Juju UI Engineering
> https://launchpad.net/~rharding
> @mitechie
>
> --
> 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/20150503/f835770b/attachment.html>