Juju core tasks for GUI project

[roger peppe]

On 5 June 2013 12:34, William Reade <william.reade at canonical.com> wrote:
> On Wed, May 29, 2013 at 11:51 PM, Gary Poster <gary.poster at canonical.com>
> wrote:
>>
>> Hi all.  I've talked several times to many of you about four things that
>> the GUI project needs from Juju core soon, and we have verbal approval
>> from Roger, William, Mark Ramm, and others.  I'd like to list these
>> tasks here and see if I can get written agreement, visibility on
>> scheduling these, and possibly clarity on what else I need to provide to
>> move things along.
>>
>> The GUI team can also provide devs for these goals if sufficient
>> direction is provided and we all agree that it is a good use of resources.
>>
>> == (1) SetUnit API ==
>>
>> Goal: Provide an API that lets users set the desired number of units for
>> a service, and have Juju increase or decrease the units to match.
>>
>> Rationale: Concurrency.  Using AddUnit, two people both trying to go
>> from 5 to 10 units will quite possibly act concurrently and move from 5
>> to 15 (add 5 and add 5).  Similarly, if two users want to decrease from
>> 15 units to 10, and they happen to choose different units in RemoveUnit,
>> they may decrease to 5.
>>
>> Looked at another way, AddUnit is not idempotent, and, effectively,
>> RemoveUnit isn't either if all you want to do is reduce unit count.
>>
>> Previously identified design challenge: how does Juju decide which units
>> should be removed?  One solution bandied about: user can choose to
>> remove from newest to oldest or from oldest to newest, defaulting to the
>> latter.  Perhaps user can also optionally provide a list of specific
>> unit ids to iterate through and remove first, before switching to policy.
>
>
> This will take some work in state, involving either a DB schema change or
> some *very* fancy footwork, on top of the obvious API work.
>
> It would probably be wiser to defer this work until we have either
> implemented major-version upgrades, or have entirely obscured state behind
> the API; both of these are very high priorities for us. I don't think core
> has the bandwidth to take this on in the next ~6 weeks, because we're
> chasing those goals already, but I'd be very happy to make myself available
> for a pre-discussion with anyone who felt up to a significant challenge (and
> to discuss or comment on proposals that fleshed the idea out, particularly
> wrt removal strategies -- or, potentially, that did an end-run around the
> removal-strategy problem by implementing SetMinimumUnits [0]).

I like SetMinimumUnits (I'd suggested the idea before but that name
makes it nicer still). It means that removal strategy is entirely in the
hands of the client, whether it's a GUI user clicking "delete" or an auto-scaler
removing the least performant node.

>>  - Implement a restricted level of authorization.  A user with this
>> authorization cannot use API calls that mutate Juju, cannot access Juju
>> debug log output, and cannot see the values of "restricted" service
>> configuration options, as identified by the previously discussed flag.
>
>
> (...and cannot see sensitive environment config values, like credentials, as
> identified using the existing SecretAttrs mechanism.)
>
> This is gated on the user model changes that we have planned, but which we
> won't get to imminently. It's explicitly planned for core, but I'd be happy
> to discuss handing over a chunk that unblocks you; I don't currently have a
> solid feel for how realistic it is.
>
>>
>>  - Implement optional anonymous restricted API access.  This is
>> initially turned off, and can be turned on by an administrator.
>
>
> This, though, doesn't *necessarily* depend on the user model, and seems like
> it's potentially quite high-value. I'd be happy to get some help here.
>
>>
>> Status: Roger had a very quick prototype of everything except the charm
>> config option "restricted" flag working at some point.
>
>
> Roger, I'd like to hear your thoughts here.

If we assume that we can nicely partition API calls into "restricted"
and "non-restricted" calls (and I *think* we can) then making
a restricted API is as simple as providing an object in the API
with only the restricted methods. The object implementing the non-restricted API
embed the restricted API and add restricted methods.

The implementation is trivial and can fit nicely with our recent
directions in the API server implementation, I think.

> [0] hmm, this approach might be possible without breaking compatibility,
> even today. Deserves further discussion.

I think so.

The main difficulty with SetMinimumUnits that I see is that the planned
GUI interface is still SetNumUnits, and you have to be quite careful
how you implement unit removal, otherwise two clients might both
decide to remove different sets of units and we might end up with fewer than
desired. I *think* that if client choice of units to remove is deterministic
(e.g. lowest number), then things should be ok.

  cheers,
    rog.