Juju core tasks for GUI project

[Gary Poster]

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.

== (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.
 - 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.
 - Implement optional anonymous restricted API access.  This is
initially turned off, and can be turned on by an administrator.

Rationale: Respond to Canonical IS. They want to expose readonly GUI
views of Juju environments to Canonical developers.  They can use this
to let devs investigate, duplicate, and give feedback on deployments.
They will protect the GUI behind Apache and OpenID.  Once full RBAC is
implemented, that would mean that optional restricted API access was no
longer needed.

Status: Roger had a very quick prototype of everything except the charm
config option "restricted" flag working at some point.

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

------------------

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

Thanks,

Gary