<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 11:23 PM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 17/11/14 15:47, Stuart Bishop wrote:<br>
> On 17 November 2014 07:13, Ian Booth <<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a>> wrote:<br>
><br>
>> The new Juju Status work planned for this cycle will hopefully address the main<br>
>> concern about knowing when a deployed charm is fully ready to do the work for<br>
>> which it was installed. ie the current situation whereby a unit is marked as<br>
>> Started but it not ready. Charms are able to mark themselves as Busy and also<br>
>> set a status message to indicate they are churning and not ready to run. Charms<br>
>> can also indicate that they are Blocked and require manual intervention (eg a<br>
>> service needs a database and no relation has been established yet to provide the<br>
>> database), or Waiting (the database on which the service relies is busy but will<br>
>> resolve automatically when the database is available again).<br>
><br>
> As long as the 'ready' state is managed by juju and not the unit, I'll<br>
> stand happily corrected :-) The focus I'd seen had been on the unit<br>
> declaring its own status, and there is no way for a unit to know that<br>
> is ready because it has no way of knowing that, for example, there are<br>
> another 10 peer units being provisioned that will need to be related.<br>
><br>
<br>
</span>You are correct that the initial scope of work is more about the unit, and less<br>
about the deployment as a whole. There are plans though to address the issue.<br>
We're throwing around the concept of a "goal state", which is conceptually akin<br>
to looking forward in time to be able to inform units what relations they will<br>
expect to participate in and what units will be deployed. They'd likely be<br>
something like a relation-goals hook tool (to compliment relation-list and<br>
relation-ids), as well as hook(s) for when the goal state changes. There's<br>
ongoing work in the uniter by William to get the architecture right so this work<br>
can be considered. There's still a lot of value in the current Juju Status work,<br>
but as you point out, it's not the full story. <br>
<span class=""><br></span></blockquote><div><br></div><div>for clusters... its not a question of futures but being informed of known unit count to establish quorum. ie 1 to 3 or n+1. leader election helps, but actually knowing the unit count is critical to being able to establish a clear state without throwing away data (aka race on peer knowing quorum and leader) as adhoc leader election has to throw away data from non leaders who may already be serving clients due to lack of quorum knowledge.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>> So although there are not currently plans to show the number of running hooks in<br>
>> the first phase of this work, mechanisms are being provided to allow charm<br>
>> authors to better communicate the state of their charms to give much clearer and<br>
>> more accurate feedback as to 1) when a charm is fully ready to do work, 2) if a<br>
>> charm is not ready to do work, why not.<br>
><br>
> A charm declaring itself ready is part of the picture. What is more<br>
> important is when the system is ready. You don't want to start pumping<br>
> requests through your 'ready' webserver, only to have it torn away as<br>
> a new block device is mounted on your database when its storage-joined<br>
> hook is invoked and returned to 'ready' state again once the<br>
> storage-changed hook has completed successfully.<br>
></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also being thrown around is the concept of a new agent-state called "Idle",<br>
which would be used when there are no pending hooks to run. There are plans as<br>
well for the next phase of the Juju status work to allow collaborating services<br>
to notify when they are busy, and mark relationships as down. So if the database<br>
had it's storage-attached hook invoked, it would mark itself as Busy, mark its<br>
relation to the webserver as Down, thus allowing the webserver to put itself<br>
into Waiting. Or, if we are talking about the initial install phase, the<br>
database would not initially mark itself as Running until its declared storage<br>
requirements were met, so the webserver would go from Installing to Waiting and<br>
then to Running one the database became Running.</blockquote><div><br></div><div><br></div><div>status per future impl helps, as does explicitly marking units.. but pending cluster count is a missing and important property to properly establish quorum in a peer rel from one to n that is only resolved by knowing recorded units count for a svc.</div><div><br></div><div>cheers,</div><div><br></div><div>Kapil</div></div></div></div>