pyjuju

Bug #741890
Comment #1

Comment 1 for bug 741890

Revision history for this message

Kapil Thangavelu (hazmat) wrote on 2011-03-24:

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

<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