juju2.0beta10: websockets API usability Application Deploy failure to inform of required addCharm pre-requisite

[Chad Smith]

In beta10 we broke websockets API consumers by requiring that Client AddCharm be called before Application Deploy. Beta9 took care of this under the hood and now our api call chains have to discover why application deploy errors out with the following message:

{u'error': {u'message': u'charm "cs:trusty/ubuntu-0" not found', u'code': u'not found'}

When we break api contracts, is there a possibility that we can add slightly more informational error messages which might point api consumers to the "missing" AddCharm method call that they might need to call?

[Adam Stokes (adam-stokes)]

Also keep in mind that if you do not perform the Resources.AddPendingResources prior to deploying your charm those resources will not be made available during deployment. So both of those should highlighted in the error message if possible

[Adam Stokes (adam-stokes)]

I think we should also mark this as critical as anything API related is heavily used outside of the official Juju client (autopilot, deployer, macumba, conjure-up, juju-gui)

[Cheryl Jennings (cherylj)]

This particular API has been deprecated for several releases, but unfortunately that was not properly documented.

beta 11 should have most of the API changes and they are documented in this thread to the juju-dev mailing list: https://lists.ubuntu.com/archives/juju-dev/2016-June/005715.html

[Chad Smith (chad.smith)]

Cherly I'm not sure if your 'deprecated' comment is implying that Landscape shouldn't use AddCharmWithAuthorization? If so, what should we be using?

[Ian Booth (wallyworld)]

Cheryl's comment referred to calling Deploy() without first calling AddCharmWithAuthorization(). What was deprecated was the behaviour of Deploy() which did an explicit AddCharm() under the covers.