Feature Request: show running relations in 'juju status'

[Kapil Thangavelu]

On Mon, Nov 17, 2014 at 11:23 PM, Ian Booth <ian.booth at canonical.com> wrote:

>
>
> On 17/11/14 15:47, Stuart Bishop wrote:
> > On 17 November 2014 07:13, Ian Booth <ian.booth at canonical.com> wrote:
> >
> >> The new Juju Status work planned for this cycle will hopefully address
> the main
> >> concern about knowing when a deployed charm is fully ready to do the
> work for
> >> which it was installed. ie the current situation whereby a unit is
> marked as
> >> Started but it not ready. Charms are able to mark themselves as Busy
> and also
> >> set a status message to indicate they are churning and not ready to
> run. Charms
> >> can also indicate that they are Blocked and require manual intervention
> (eg a
> >> service needs a database and no relation has been established yet to
> provide the
> >> database), or Waiting (the database on which the service relies is busy
> but will
> >> resolve automatically when the database is available again).
> >
> > As long as the 'ready' state is managed by juju and not the unit, I'll
> > stand happily corrected :-) The focus I'd seen had been on the unit
> > declaring its own status, and there is no way for a unit to know that
> > is ready because it has no way of knowing that, for example, there are
> > another 10 peer units being provisioned that will need to be related.
> >
>
> You are correct that the initial scope of work is more about the unit, and
> less
> about the deployment as a whole. There are plans though to address the
> issue.
> We're throwing around the concept of a "goal state", which is conceptually
> akin
> to looking forward in time to be able to inform units what relations they
> will
> expect to participate in and what units will be deployed. They'd likely be
> something like a relation-goals hook tool (to compliment relation-list and
> relation-ids), as well as hook(s) for when the goal state changes. There's
> ongoing work in the uniter by William to get the architecture right so
> this work
> can be considered. There's still a lot of value in the current Juju Status
> work,
> but as you point out, it's not the full story.
>
>
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.


> >
> >> So although there are not currently plans to show the number of running
> hooks in
> >> the first phase of this work, mechanisms are being provided to allow
> charm
> >> authors to better communicate the state of their charms to give much
> clearer and
> >> more accurate feedback as to 1) when a charm is fully ready to do work,
> 2) if a
> >> charm is not ready to do work, why not.
> >
> > A charm declaring itself ready is part of the picture. What is more
> > important is when the system is ready. You don't want to start pumping
> > requests through your 'ready' webserver, only to have it torn away as
> > a new block device is mounted on your database when its storage-joined
> > hook is invoked and returned to 'ready' state again once the
> > storage-changed hook has completed successfully.
> >

Also being thrown around is the concept of a new agent-state called "Idle",
> which would be used when there are no pending hooks to run. There are
> plans as
> well for the next phase of the Juju status work to allow collaborating
> services
> to notify when they are busy, and mark relationships as down. So if the
> database
> had it's storage-attached hook invoked, it would mark itself as Busy, mark
> its
> relation to the webserver as Down, thus allowing the webserver to put
> itself
> into Waiting. Or, if we are talking about the initial install phase, the
> database would not initially mark itself as Running until its declared
> storage
> requirements were met, so the webserver would go from Installing to
> Waiting and
> then to Running one the database became Running.



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.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141118/9aa0f2dd/attachment.html>