Juju core tasks for GUI project

[Gary Poster]

Bump.

Thanks,

Gary

On 05/29/2013 05:51 PM, Gary Poster 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.
> 
> == (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
>