api should have error codes, currently having to sniff error message strings is fragile

[Kapil Thangavelu]

else we're introducing alot fragility into api consumers.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-11-25 20:43, Kapil Thangavelu wrote:
> Public bug reported:
>
> else we're introducing alot fragility into api consumers.
>
> ** Affects: juju-core Importance: Undecided Status: New
>

Many errors do have codes:
 state/api/params/apierror.go

const (
 CodeNotFound = "not found"
 CodeUnauthorized = "unauthorized access"
 CodeCannotEnterScope = "cannot enter scope"
 CodeCannotEnterScopeYet = "cannot enter scope yet"
 CodeExcessiveContention = "excessive contention"
 CodeUnitHasSubordinates = "unit has subordinates"
 CodeNotAssigned = "not assigned"
 CodeStopped = "stopped"
 CodeHasAssignedUnits = "machine has assigned units"
 CodeNotProvisioned = "not provisioned"
 CodeNoAddressSet = "no address set"
)

However, I think the Client API that was written for the GUI predates
us adding Codes to standard errors, so might not be using them.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKWLGoACgkQJdeBCYSNAAMFJwCfSKln21mMFyDQ/C2Z2R06sDvX
+qIAmwXEdUNzmtkUIBSODwJ8umUur++6
=WwTW
-----END PGP SIGNATURE-----

[Adam Stokes (adam-stokes)]

Another example of what we see when interacting with the api:

#!/usr/bin/env python3
import sys
sys.path.insert(0, '../macumba')
import macumba
from pprint import pprint

JUJU_URL = 'wss://localhost:17070/'
JUJU_PASS = 'pass'

if __name__ == "__main__":
    j = macumba.JujuClient(url=JUJU_URL, password=JUJU_PASS)
    j.login()
    ret = j.deploy('precise/wordpress', 'wordpress', machine_spec='1')
    pprint(ret)

[~/Projects/macumba]> python test/functional/deploy_charm.py
{}

This is a result of deploying a charm via api where no machine was ever created:
[~/Projects/macumba]> juju status
environment: local
machines:
  "0":
    agent-state: started
    agent-version: 1.20.1.1
    dns-name: localhost
    instance-id: localhost
    series: trusty
    state-server-member-status: has-vote
services:
  wordpress:
    charm: cs:precise/wordpress-25
    exposed: false
    relations:
      loadbalancer:
      - wordpress
    units:
      wordpress/0:
        agent-state: pending

Doing the same deploy and not specifying a ToMachineSpec results in the same return:

[~/Projects/macumba]> python test/functional/dump_status.py
{}

Other than polling a FullStatus we have no way of determining a success/fail charm deployment

[Nate Finch (natefinch)]

One thought - it might be a good idea to give error codes numbers as well as strings.... that does two things:

1.) it makes it a lot more obvious that the code is something that SHOULD NOT CHANGE. Strings are generally seen as only for human consumption and might get tweaked by someone trying to "help". Most people seeing CodeNotFound = 576 will make the assumption that this is a magic number that should never get changed.

2.) It makes it a lot more obvious that places that *consume* the error codes are actually consuming error *codes*, not doing error-prone message parsing (as evidenced by the fact that people didn't think these were actually error codes).

[Kapil Thangavelu (hazmat)]

i don't care if its numbers or not.. i do want actual codes in a separate
respone field, its not readily apparent its an error code because those
codes are coming back as a contextual message in the response not a
separate code field. so different apis return different things there some
contextual, some actual error codes which means its worthless without a
distinguishing field imo.

On Wed, Aug 13, 2014 at 6:44 PM, Nate Finch <email address hidden>
wrote:

> One thought - it might be a good idea to give error codes numbers as
> well as strings.... that does two things:
>
> 1.) it makes it a lot more obvious that the code is something that
> SHOULD NOT CHANGE. Strings are generally seen as only for human
> consumption and might get tweaked by someone trying to "help". Most
> people seeing CodeNotFound = 576 will make the assumption that this is
> a magic number that should never get changed.
>
> 2.) It makes it a lot more obvious that places that *consume* the error
> codes are actually consuming error *codes*, not doing error-prone
> message parsing (as evidenced by the fact that people didn't think these
> were actually error codes).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1254790
>
> Title:
> api should have error codes, currently having to sniff error message
> strings is fragile
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1254790/+subscriptions
>

[John A Meinel (jameinel)]

I don't see this as something that can be done as a simple "bugfix" in a stabilization release (beta) release. It is much more of a significant change to the API (feature level work).
I like it a lot, but it doesn't feel like it should be targetted to 1.21-beta1.

[Anastasia (anastasia-macmood)]

We have re-worked APIs considerably for Juju 2. There will be no further work on this for Juju 1.x series.

@John,
If it's something that you and tech board feel strongly about, please create a new bug against "juju".