Better support for debugging install/start hooks

Bug #741890 reported by Kapil Thangavelu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pyjuju
Fix Released
Low
Unassigned

Bug Description

Currently the debug-hooks command validates the unit name before setting up debug hooks, which requires the unit exists, leaving potentially a small window for setting a debug on the install and start hooks. Switching the debug-hooks to wait for the unit existence with an appropriate timeout would be a better approach, we'll some additional api in the service state manager to support watching for service_units.

Revision history for this message
Kapil Thangavelu (hazmat) wrote :

After some discussion on irc, it seems like getting debug hooks working for install/start would be better arranged by adding the functionality as a cli flag to the deploy command, which can drop a user directly into a debug shell when the machine is ready.

<niemeyer> kapil: But then, even if we were able to predict the unit name, it feels like a bad approach in general
<niemeyer> kapil: Like winning a typing race :)
<kapil> niemeyer, we can predict with fair certainty the next name of the unit internal to the api.
<kapil> so perhaps mysql/next
<niemeyer> kapil: It feels like a much better approach would be to do that at deploy time
<niemeyer> kapil: ensemble deploy --debug-hooks ...
<kapil> as a unit name denoting debug the next unit of this service
<niemeyer> and then hook up
<niemeyer> "hook up" is an ideal term in that case, I guess ;-)
<kapil> niemeyer, hmm so deploy would drop into a debug shell after waiting for the machine startup?
<kapil> that sounds pretty nice
<niemeyer> kapil: No, it would only set a flag there
<niemeyer> kapil: We don't want to be copying everything over from debug-hooks I think
<kapil> niemeyer, i was just thinking calling out to some refactor in debug-hooks
<niemeyer> kapil: It'd put the unit in debug mode, and then we can run ensemble debug-hooks after the fact at our leisure
<kapil> well currently debug-hooks is ephemeral..
<niemeyer> kapil: Hmmm.. can we still an ephemeral node? :-)
<niemeyer> steal
<kapil> sort of
<kapil> we can steal the session id if we save it...
<niemeyer> Hmm.. that's full of edge cases IIRC
<kapil> and the time between the commands is less than session timeout
<kapil> niemeyer, yeah.. can of worms
<niemeyer> (from my gozk playing)
<kapil> much easier to call into a refactored debug-hooks from deploy
<kapil> hmmm
<kapil> although its gets a little messy when deploy could mean a whole suite of services and units... we should only debug the top level one.. but then we start getting formula that specify min units >1 and get ambigious.
<niemeyer> Yeah

Changed in ensemble:
milestone: none → budapest
Changed in ensemble:
milestone: budapest → dublin
Changed in ensemble:
milestone: dublin → none
Changed in juju:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Kapil Thangavelu (hazmat) wrote :

this is an old bug, but its hugely mitigated in practice. There was a fix applied to process debug hooks/debug logs settings several months ago. Given the time for machine provisioning, its fairly straight forward to debug install/start hooks doing the logical thing.. ie.

juju bootstrap
juju deploy wordpress
juju debug-hooks wordpress/0

should work without issue.

The local provider being a bit faster to deploy (a few seconds), does require the debug-hooks command fairly soon after deploy, but that seems fairly minor.

Changed in juju:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.