| * keesj created two fresh bug reports this morning | 10:23 | |
| keesj | me would like some feedback on https://bugs.launchpad.net/upstart/+bug/337665 | 13:27 |
|---|---|---|
| keesj | is is a bug or just and anoying feature | 13:28 |
| Keybuk | keesj: it sounds like you're inferring ordering where none exists? | 15:29 |
| keesj | Well not in the direct rules but clearly I think I defined that the services should be exclusive | 16:00 |
| Keybuk | there's no such thing as an exclusive service though | 16:01 |
| keesj | clearly :p | 16:01 |
| Keybuk | you just defined two services that used each other's events to change their own state | 16:01 |
| Keybuk | both can be running simultaneously | 16:01 |
| Keybuk | if the event queue is paused, for example | 16:01 |
| keesj | My understanding is that whenever service_b is started the service_b starting event is launched and therefore service_c will be stopped | 16:03 |
| keesj | but there is clearly a difference of interpretation between us | 16:04 |
| Keybuk | that will happen, yes | 16:06 |
| keesj | and why isn't service_b waiting for service_a to be stopped (or actlaly why doesn't service_a block the starting of service_b) ? | 16:08 |
| Keybuk | whuh? | 16:08 |
| Keybuk | let's break this down | 16:08 |
| Keybuk | you have: | 16:08 |
| Keybuk | A stop on starting service_b or starting service_c | 16:08 |
| Keybuk | this means that A will be stopped should B be starting | 16:09 |
| Keybuk | OR should C be starting | 16:09 |
| Keybuk | -- | 16:09 |
| Keybuk | B start on starting service_c | 16:09 |
| Keybuk | B stop on starting service_a | 16:09 |
| Keybuk | this means that B will be started should C be starting | 16:09 |
| Keybuk | and B will be stopped should A be starting | 16:09 |
| Keybuk | -- | 16:09 |
| Keybuk | C nil | 16:09 |
| Keybuk | this means that C is under full manual control | 16:09 |
| sadmac2 | Keybuk: where'd you get libnih's string hashing algo? | 16:15 |
| Keybuk | keesj: so you do | 16:16 |
| Keybuk | start A | 16:16 |
| Keybuk | A is thus started | 16:16 |
| Keybuk | B will be stopped, but is already at stop, so won't go anywhere | 16:16 |
| Keybuk | start B | 16:16 |
| Keybuk | B is thus started | 16:16 |
| Keybuk | A will be stopped, as a result of the "starting B" event | 16:17 |
| Keybuk | you now have | 16:17 |
| Keybuk | A - stopping | 16:17 |
| Keybuk | B - starting | 16:17 |
| Keybuk | you then did | 16:17 |
| Keybuk | start C | 16:17 |
| Keybuk | there's two possible outcomes here | 16:17 |
| Keybuk | actually, I think there's just one | 16:17 |
| Keybuk | B will be started | 16:17 |
| Keybuk | A will be started | 16:17 |
| Keybuk | B is already running, so that's ok | 16:17 |
| Keybuk | gnargh | 16:18 |
| Keybuk | rewind | 16:18 |
| Keybuk | sorry | 16:18 |
| Keybuk | As and Bs confused | 16:18 |
| Keybuk | you then did | 16:18 |
| Keybuk | start C | 16:18 |
| Keybuk | B will be stopped | 16:18 |
| Keybuk | A will be started | 16:18 |
| Keybuk | (result of starting C) | 16:18 |
| Keybuk | B stopping will stop A | 16:18 |
| Keybuk | so A will be stopped again | 16:18 |
| Keybuk | I'd expect the result | 16:18 |
| Keybuk | A stopped | 16:18 |
| Keybuk | B stopped | 16:18 |
| Keybuk | C running | 16:19 |
| Keybuk | keesj: what do you see? | 16:19 |
| Keybuk | ah | 16:19 |
| Keybuk | sorry | 16:19 |
| Keybuk | no ing | 16:19 |
| Keybuk | start C | 16:19 |
| Keybuk | A will be started | 16:20 |
| * Keybuk gets all confused | 16:20 | |
| keesj | I see that B is started before A is stopped | 16:20 |
| Keybuk | this is hard when you just use A and B and C as names | 16:20 |
| Keybuk | keesj: don't use words like "before" or "after" | 16:20 |
| Keybuk | Upstart has no concept | 16:20 |
| Keybuk | what is the final result | 16:20 |
| Keybuk | ie. if you sit down and leave it for five minutes | 16:20 |
| Keybuk | what is the resultant system state | 16:20 |
| * Keybuk retraces again | 16:21 | |
| Keybuk | start C | 16:21 |
| Keybuk | starting C will start B, and stop A | 16:21 |
| Keybuk | B is already running anyway | 16:22 |
| Keybuk | A is already stopped anyway | 16:22 |
| Keybuk | no? | 16:22 |
| Keybuk | keesj: I'm sorry, but I'm completely confused as to what you're trying to demonstrate here | 16:22 |
| sadmac2 | Keybuk: will 0.10 still need to generate events for started/starting/stopping/stopped? | 16:23 |
| Keybuk | sadmac2: eys | 16:23 |
| Keybuk | sadmac2: the libnih string hash btw is FnV | 16:23 |
| sadmac2 | Keybuk: when do we need those events now? | 16:23 |
| sadmac2 | ah. | 16:23 |
| Keybuk | keesj: just going back through this once more | 16:24 |
| Keybuk | # start A | 16:24 |
| keesj | now start B | 16:24 |
| Keybuk | starting A -> stop B, but B is not running | 16:24 |
| Keybuk | A is running | 16:24 |
| Keybuk | # start B | 16:24 |
| Keybuk | starting B -> stop A, so A will be stopped | 16:25 |
| keesj | you will see that first A is stoppe and only after that b is started right? | 16:25 |
| Keybuk | B is running | 16:25 |
| Keybuk | A is stopped | 16:25 |
| keesj | the after here is imporant | 16:25 |
| Keybuk | right | 16:25 |
| Keybuk | right, B starting is blocked on A stopping | 16:25 |
| keesj | if you start a again you see the reverse happen first b is stopped and then only a is started right? | 16:26 |
| Keybuk | right | 16:26 |
| Keybuk | A starting is blocked on B stopping | 16:26 |
| Keybuk | so we're in a state where B is running, A is stopped | 16:26 |
| Keybuk | you start C | 16:27 |
| Keybuk | starting C -> start B, but B is already running | 16:27 |
| Keybuk | starting C -> stop A, but A is already stopped | 16:27 |
| Keybuk | no? | 16:27 |
| keesj | yes that is alright | 16:28 |
| Keybuk | maybe you mean to do it the other way | 16:28 |
| keesj | now start a | 16:28 |
| Keybuk | we're in a state where A is running, B is stopped | 16:28 |
| Keybuk | you start C | 16:28 |
| Keybuk | starting C -> stop A | 16:28 |
| Keybuk | starting C -> start B | 16:28 |
| Keybuk | C will not start until A is stopped and B is started | 16:28 |
| keesj | right | 16:29 |
| keesj | but why doesn B also wait for a to be stopped, just like earlyer? | 16:29 |
| Keybuk | why wouldn't it? | 16:29 |
| Keybuk | B has nothing to do with A | 16:29 |
| Keybuk | B was told to stop by C | 16:29 |
| Keybuk | err told to start by C | 16:29 |
| Keybuk | C will wait for B to start | 16:29 |
| Keybuk | look at the chain | 16:30 |
| keesj | and A was tols to stop by B right? | 16:30 |
| keesj | told | 16:30 |
| Keybuk | no | 16:30 |
| Keybuk | A was told to stop by C | 16:30 |
| Keybuk | starting C -> stop A | 16:30 |
| Keybuk | starting C -> start B | 16:30 |
| Keybuk | stopping A -> ... | 16:30 |
| Keybuk | starting B -> stop A, but A is already being stopped | 16:31 |
| * sadmac2 contemplates inventing Event Algebra | 16:31 | |
| Keybuk | it actually depends a bit which order it processes the events I think ;) | 16:31 |
| Keybuk | oh, no it doesn't | 16:32 |
| Keybuk | starting C -> start B | 16:32 |
| Keybuk | starting C -> stop A | 16:32 |
| Keybuk | starting B -> stop A, but A is already being stopped | 16:32 |
| keesj | Indeed , there is already some code to first stop and after that start a job if it is stop and started | 16:32 |
| Keybuk | stopping A -> ... | 16:32 |
| keesj | right: starting B -> stop A, but A is already being stopped.... | 16:32 |
| keesj | this is where I would expect B to wait | 16:33 |
| Keybuk | you want B to wait for A? | 16:33 |
| Keybuk | but B wasn't told to stop by A | 16:33 |
| Keybuk | start I mean | 16:33 |
| Keybuk | B has no relationship with A in this scenario | 16:33 |
| Keybuk | to do that | 16:33 |
| Keybuk | stop on (starting service_b and starting service_c) or starting service_b or starting service_c | 16:34 |
| Keybuk | (in A) | 16:34 |
| Keybuk | hm | 16:34 |
| Keybuk | no that won't work either | 16:34 |
| Keybuk | stop on starting service_b and starting service_c | 16:34 |
| Keybuk | is all that will do it | 16:34 |
| Keybuk | but that won't give you your A/B flip-flop unless C is involved | 16:34 |
| keesj | A was told to stop on starting B | 16:35 |
| Keybuk | no | 16:35 |
| Keybuk | it wasn't | 16:35 |
| Keybuk | starting C -> stop A | 16:35 |
| Keybuk | starting C -> start B | 16:35 |
| Keybuk | stopping A -> ... | 16:35 |
| Keybuk | starting B -> stop A, but A is already being stopped | 16:35 |
| Keybuk | A was told to stop on starting C | 16:35 |
| Keybuk | so stop it did | 16:35 |
| Keybuk | by the time B starting told it to stop, it was _already_ stopping | 16:35 |
| Keybuk | you used "or" | 16:35 |
| keesj | "stopping" is not enought | 16:36 |
| keesj | but what do you mean by senario? | 16:37 |
| Keybuk | ? | 16:37 |
| Keybuk | what do you mean by what do I mean? :p | 16:38 |
| keesj | I don't understand . | 16:46 |
| keesj | you say < Keybuk> B has no relationship with A in this scenario | 16:46 |
| keesj | but I am not aware of such a concept. In my understanding is that there is a state tree with events. B and A always have a relationship | 16:48 |
| Keybuk | I think you're assuming a much more complicated system than exists ;) | 16:50 |
| keesj | the bug IMHO is that A is already stopping b should wait . | 16:50 |
| Keybuk | A just says it will be stopped if C starts *OR* B starts | 16:50 |
| keesj | so I need to write a loop in service_b and wait until service_a is really stopped | 16:51 |
| Keybuk | I agree that such a feature would be desirable | 16:51 |
| Keybuk | but it's impossible to implement given the way 0.5 works | 16:51 |
| Keybuk | the problem is that stopping B just generates an event | 16:52 |
| Keybuk | A is already stopping, so is no longer listening for stop events | 16:52 |
| Keybuk | we shall have to make sure that "while not (B or C)" works | 16:52 |
| keesj | hmm | 16:58 |
| keesj | Well I will try to find shorter term solution then :p | 16:59 |
| sadmac2 | Keybuk: fun problem for your 0.10 model: | 17:30 |
| sadmac2 | Keybuk: service A has "when not B; on q", service B has "when not A; on q". both services exist. q happens | 17:31 |
| sadmac2 | by exist I mean their dependencies have been found and a job struct has been created | 17:31 |
| Keybuk | no problem there ;) | 17:32 |
| sadmac2 | Keybuk: which one starts would depend on the order of processing. | 17:32 |
| sadmac2 | if you start A, it precludes B. if you start B it precludes A | 17:32 |
| sadmac2 | Keybuk: care to elaborate? | 17:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!