[Maas-devel] Allow API to use <system_id | hostname> for all operations that currently require the system_id

[Gavin Panella]

On 29 May 2014 03:39, Julian Edwards <julian.edwards at canonical.com> wrote:
> On Wednesday 28 May 2014 11:27:16 Newell Jensen wrote:
>> * Currently, for every single node related operation (other than updating
>> hostname), we need to obtain the system_id. This is affecting usability.
>
> I presume you are talking about the usability of maas-cli here?
>
>> * Every single operation that currently requires a node's system_id, should
>> accept the hostname (other than when updating a node's hostname of course).
>
> I think we need to discuss this problem some more before jumping to a hasty
> change.
>
> Some background is required here:
>
> 1. The API was designed as a machine interface, it was never intended to be
> exposed directly to end users
>
> 2. maas (used to be maas-cli) was designed as a convenience method to access
> the API from the command line, mostly for testing purposes.  It is a *very*
> raw interface that is auto-generated from the API capability itself, so
> reflects changes in the API as soon as they happen.  It was not really
> designed to be used as a serious API client for end users.

I built most of maas-cli, and I had hoped it would have been nicer to
use, but it didn't work out that way. It filled a gap at the time, one
that we had about minus a week to fill, and it shows :)

>
> For this reason, I think we need to look at this in the context of some of the
> upcoming work on general usability.
>
> My opinion is that changing the API is the wrong thing to do here.  If we want
> to make the command line more usable, I think we need to move maas back to
> maas-cli and write a wrapper (called maas) around it to add a sugary layer for
> end users.  This can include something that accepts hostnames for operations
> involving nodes.  It can also include something that makes the parameters to
> some of the operations a lot easier to understand.

I think we need to do the work to split the MAAS CLI into two parts:
the front-end, and an auto-generated stub API. I've mentioned this
many times before, but I've never gotten around to it.

With that we could sugar-up the API as necessary, wrapping a better
CLI around it. For those bits that we haven't sugared yet (or where
the client is older than the server and doesn't have the corresponding
sugar yet) we could still expose the functionality as it is now, or
have a "raw" mode that reproduces the current behaviour in full.

>
> Now would be a great time to start this work!  Those who attended the Austin
> sprint will have more details on what was discussed for the command line
> client.

We discussed the split, but deferred a lot of stuff to discussion with
the Canonical UX team.