Request: clients should not be responsible for parsing constraints

[Pen Gale]

Currently, if a client like the gui or python-libjuju wants to deploy a bundle with constraints, it will get a string like the following back from the plan generator specifying those constraints:

    "mem=7G"

The GUI then expects the client to translate this into the following json:

    {"mem": 7168}

Basically, the client needs to know that juju wants memory specified in Mb, and translate the string to Mb. Similarly, for other constraints, the client needs to know what conventions juju core expects, and translate the strings that the user has specified into those conventions. The conventions are documented in constraints.go, but are not available as an API call.

It would be much nicer if core instead accepted:

    {"mem": "7G"}

or even

    {"constraints": "mem=7G"}

That way, we won't have to maintain constraints.py and constraints.js, duplicating the work already done in constraints.go.

[Cory Johns (johnsca)]

To clarify, this is about the websocket API and not the GUI or python-libjuju specifically.

The clients call the client_facade.GetBundleChanges API call with the bundle yaml and get back a plan of steps consisting of other API methods to call with the args to provide them. However, the call to AddMachines in the plan has the constraints returned as an unparsed string, while client_facade.AddMachines expects the constraints to be given as constraints.Value serialized structure.

The Juju Go client uses constraints.Parse but that doesn't appear to be exposed anywhere, so neither the GUI nor python-libjuju can use it and have to reimplement all of the constraint parsing logic themselves.

The easiest solution would be to expose constraints.Parse in the API. Perhaps a better solution would be to have the plan come back with the constraints already parsed, but that will raise backwards compatibility issues.

[Cory Johns (johnsca)]

Actually, I should say that the easiest solution from our side is what Pete suggested to have the AddMachines API also accept the unparsed constraints string and do the parsing on that side if necessary. But having to make another API call to parse the constraints wouldn't be too terribly bad either, I don't think.

[Anastasia (anastasia-macmood)]

PR against develop: https://github.com/juju/juju/pull/6639