<div dir="ltr">On Wed, May 29, 2013 at 11:51 PM, Gary Poster <span dir="ltr"><<a href="mailto:gary.poster@canonical.com" target="_blank">gary.poster@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all.  I've talked several times to many of you about four things that<br>

the GUI project needs from Juju core soon, and we have verbal approval<br>
from Roger, William, Mark Ramm, and others.  I'd like to list these<br>
tasks here and see if I can get written agreement, visibility on<br>
scheduling these, and possibly clarity on what else I need to provide to<br>
move things along.<br>
<br>
The GUI team can also provide devs for these goals if sufficient<br>
direction is provided and we all agree that it is a good use of resources.<br>
<br>
== (1) SetUnit API ==<br>
<br>
Goal: Provide an API that lets users set the desired number of units for<br>
a service, and have Juju increase or decrease the units to match.<br>
<br>
Rationale: Concurrency.  Using AddUnit, two people both trying to go<br>
from 5 to 10 units will quite possibly act concurrently and move from 5<br>
to 15 (add 5 and add 5).  Similarly, if two users want to decrease from<br>
15 units to 10, and they happen to choose different units in RemoveUnit,<br>
they may decrease to 5.<br>
<br>
Looked at another way, AddUnit is not idempotent, and, effectively,<br>
RemoveUnit isn't either if all you want to do is reduce unit count.<br>
<br>
Previously identified design challenge: how does Juju decide which units<br>
should be removed?  One solution bandied about: user can choose to<br>
remove from newest to oldest or from oldest to newest, defaulting to the<br>
latter.  Perhaps user can also optionally provide a list of specific<br>
unit ids to iterate through and remove first, before switching to policy.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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]).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
== (2) Restricted mode and (3) the "restricted" config data flag ==<br>
<br>
Goals:<br>
 - Implement a "restricted" (or "private") flag for charm config<br>
options.  It defaults to false.  The value of the flag is remembered and<br>
exposed within Juju.  It is used for identifying values that should not<br>
be shared within a restricted level of authorization.  Examples are<br>
database password fields within a config.<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - Implement a restricted level of authorization.  A user with this<br>
authorization cannot use API calls that mutate Juju, cannot access Juju<br>
debug log output, and cannot see the values of "restricted" service<br>
configuration options, as identified by the previously discussed flag.<br></blockquote><div><br></div><div style>(...and cannot see sensitive environment config values, like credentials, as identified using the existing SecretAttrs mechanism.)</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - Implement optional anonymous restricted API access.  This is<br>
initially turned off, and can be turned on by an administrator.<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Status: Roger had a very quick prototype of everything except the charm<br>
config option "restricted" flag working at some point.<br></blockquote><div><br></div><div style>Roger, I'd like to hear your thoughts here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

== (4) debug log over API ==<br>
<br>
Goal: When you implement the debug log over the API, you include<br>
additional features.<br>
- We can ask Juju to filter the debug log by unit.<br>
- A history of N lines will be sent initially.<br>
<br>
Rationale: One of the GUI's core stories this cycle is diagnostics.  We<br>
want to let GUI users who see a unit with a problem have a chance to<br>
look at some quick diagnostics before they decide what to do next--kill<br>
the unit and restart, ssh into the unit and investigate, and so on.<br>
This has been one of our key findings in user testing.  Access to the<br>
Juju debug log for a unit is our top priority for this goal.<br></blockquote><div><br></div><div style>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What can we do to get these scheduled and coming soon?</blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Cheers</div><div style>William</div><div><br></div><div style>[0] hmm, this approach might be possible without breaking compatibility, even today. Deserves further discussion.</div></div><br>
</div></div>