On 17/11/14 15:47, Stuart Bishop wrote: > On 17 November 2014 07:13, Ian Booth <ian.bo...@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. > >> 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. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
