Juju core tasks for GUI project

[William Reade]

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]).


> == (2) Restricted mode and (3) the "restricted" config data flag ==
>
> Goals:
>  - Implement a "restricted" (or "private") flag for charm config
> options.  It defaults to false.  The value of the flag is remembered and
> exposed within Juju.  It is used for identifying values that should not
> be shared within a restricted level of authorization.  Examples are
> database password fields within a config.
>

It should be trivial to implement this, and I have no objections. Core
bandwidth remains a problem, but I'm happy to hand this work over with no
more than a 5-minute pre-impl sync-up call with whoever wants it.


>  - 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.


> == (4) debug log over API ==
>
> Goal: When you implement the debug log over the API, you include
> additional features.
> - We can ask Juju to filter the debug log by unit.
> - A history of N lines will be sent initially.
>
> Rationale: One of the GUI's core stories this cycle is diagnostics.  We
> want to let GUI users who see a unit with a problem have a chance to
> look at some quick diagnostics before they decide what to do next--kill
> the unit and restart, ssh into the unit and investigate, and so on.
> This has been one of our key findings in user testing.  Access to the
> Juju debug log for a unit is our top priority for this goal.
>

debug-log needs to go over the API for us to complete the api-everywhere
work regardless. John, you're heading up the API work; would you please
ensure this requirement doesn't get lost in the cracks?


> What can we do to get these scheduled and coming soon?


Grab me for quick discussions re: (1), (2), (3), so we can get a clearer
idea of the relative costs and benefits, and what you'll be able to
reasonably do; I'm happy to support whatever work you guys have bandwidth
for (and I'm sorry we can't just implement them for you straight away
ourselves). Re (4), hopefully you'll get everything you need for free by
sitting and waiting.

Cheers
William

[0] hmm, this approach might be possible without breaking compatibility,
even today. Deserves further discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130605/a70e12c7/attachment-0001.html>