| davecheney | ./conn_test.go:117: undefined: juju.NewConnFromAttrs | 02:54 |
|---|---|---|
| davecheney | grrr, thanks rog | 02:54 |
| TheMue | Good morning | 06:23 |
| fwereade_ | TheMue, heyhey | 06:31 |
| davecheney | hello | 06:31 |
| fwereade_ | davecheney, heyhey | 06:32 |
| TheMue | fwereade_: Had a nice party yesterday? | 06:32 |
| fwereade_ | TheMue, ha, just a sleep :) | 06:32 |
| TheMue | fwereade_: Thought you would be too upset to fell asleep. (Do you say so?) | 06:33 |
| fwereade_ | TheMue, excited maybe more than upset | 06:33 |
| davecheney | what did I miss ? | 06:34 |
| fwereade_ | TheMue, upset usually carries unhappy connotations :) | 06:34 |
| fwereade_ | davecheney, I ran something on juju :) | 06:34 |
| davecheney | fwereade_: indeed you did | 06:34 |
| davecheney | a cause for celebration, not for sadness by my account | 06:34 |
| fwereade_ | davecheney, definitely, it's just that I celebrated by going to sleep | 06:34 |
| davecheney | sounds like a valid choice to me | 06:35 |
| TheMue | fwereade_: Ah, excited is the missing word. Thx. | 06:36 |
| TheMue | fwereade_: Already felt that upset is wrong. | 06:36 |
| davecheney | possibly elated | 06:36 |
| TheMue | Btw, my vacation starts today. But I'll be in later today again as I have two LGTMs. | 06:39 |
| davecheney | ok | 06:39 |
| TheMue | While I'm away you can reach me by mail, thx to those little portable computers which also can phone. ;) | 06:40 |
| davecheney | TheMue: i have a really bad camera that also has email on it | 06:46 |
| davecheney | btw, http://codereview.appspot.com/6497070/ | 06:46 |
| davecheney | this might be the solutoin to the strange EOF problems we have talking to LP and AWS | 06:46 |
| davecheney | *might* | 06:46 |
| davecheney | or it coudl just be the intertubes in australia | 06:46 |
| fwereade_ | TheMue, btw, if you's still around, why do you favour the switch over the if/else in loose-hook-info-members? | 06:55 |
| fwereade_ | TheMue, it's clearly a perfectly legitimate thing to do but I have a strong bias toward switching on just one thing... is this just because I'm used to "broken" switch statements? | 06:56 |
| rogpeppe | davecheney, fwereade_: morning | 07:09 |
| davecheney | morning | 07:10 |
| rogpeppe | davecheney: the change to NewConnFromAttrs was niemeyer's suggestion BTW | 07:10 |
| rogpeppe | davecheney: sorry about that | 07:10 |
| davecheney | rogpeppe: so'k | 07:10 |
| davecheney | wasn't hard to figure out | 07:10 |
| rogpeppe | davecheney: it made for better alignment with the entry points in environs | 07:10 |
| davecheney | yeah, 'tis and improvement | 07:10 |
| TheMue | fwereade_: Just optical reasons. I like the switch more than if-else-chains (even if they are short). But don't care, just personal preferences. :) | 07:12 |
| fwereade_ | TheMue, changed it, still somewhat ambivalent, we'll see | 07:14 |
| rogpeppe | fwereade_: does this look better to you than the version as test fixture? https://codereview.appspot.com/6495086/ | 07:14 |
| fwereade_ | rogpeppe, heyhey | 07:14 |
| * fwereade_ looks | 07:14 | |
| rogpeppe | fwereade_: i generally prefer a switch if there are more than two branches | 07:15 |
| TheMue | fwereade_: Thx. So, off for the moment. | 07:15 |
| fwereade_ | rogpeppe, there are only two here | 07:15 |
| rogpeppe | fwereade_: in which case i'm probably on the fence, although i haven't seen the code in question | 07:16 |
| fwereade_ | rogpeppe, it may just be that I had a couple of reviews requesting switch->if-else and have grown wary of them :) | 07:16 |
| fwereade_ | rogpeppe, that looks much nicer to me | 07:19 |
| rogpeppe | fwereade_: cool. i'm not entirely sure about the "series" helper methods (explicit better than implicit?) but i'm happier with it as a normal type not a fixture. | 07:19 |
| fwereade_ | rogpeppe, definitely | 07:19 |
| rogpeppe | davecheney: good work on tls fix - let's hope it helps | 07:20 |
| rogpeppe | fwereade_: the only other thing i considered was embedding LocalRepository or something like that. | 07:20 |
| rogpeppe | fwereade_: 'cos they're really quite similar | 07:21 |
| rogpeppe | fwereade_: but most uses don't care, and it's easy to make up a LocalRepository when needed | 07:21 |
| fwereade_ | rogpeppe, IIRC I wanted to do that when I was first writing it but couldn't get them quite similar enough :) | 07:21 |
| davecheney | rogpeppe: i'm not really sure it was the problem, but TSAN picked it up so it needed to be fixed | 07:22 |
| rogpeppe | fwereade_: i think it's ok - they both represent a repository, but do different things with it. and all the state is in the directory, so it doesn't matter. | 07:22 |
| rogpeppe | davecheney: ah. i'm looking forward to that being included as standard. i'm interested to see what it makes of our code... | 07:23 |
| davecheney | rogpeppe: there is a reason why I don't run GOMAXPROCS > 1 | 07:26 |
| davecheney | that will make gozk EXPLODE!! | 07:26 |
| rogpeppe | davecheney: have you tried it? | 07:26 |
| davecheney | once | 07:26 |
| davecheney | got a segfault in gozk | 07:26 |
| rogpeppe | davecheney: ha ha. i thought it *should* be safe. | 07:26 |
| davecheney | rogpeppe: did you log that issue to have the signal details logged | 07:26 |
| rogpeppe | davecheney: ah, no. i'll do that. | 07:26 |
| rogpeppe | davecheney: it would be quite a hassle to fix sadly | 07:33 |
| rogpeppe | davecheney: because in that context we can't call any functions | 07:34 |
| davecheney | isn't there a panicf | 07:35 |
| davecheney | or a printf that doesn't allocate ? | 07:35 |
| rogpeppe | davecheney: hmm, maybe. i'm not sure of what invariants we need at that level. | 07:36 |
| rogpeppe | davecheney: of course, the real fix is to allow callbacks from non-Go-created threads. | 07:38 |
| davecheney | rogpeppe: that fix might be saying 'the real fix is to relax the laws of reletivity to allow high paying packets to travel at their chosen speed' | 07:41 |
| rogpeppe | davecheney: yeah | 07:41 |
| davecheney | m and g are not available, but as long as the GC doesn't need to run, it should be safe to use runtime.print | 07:42 |
| rogpeppe | davecheney: do you know what linux signal behaviour is w.r.t. threads? is the signal delivered to one thread only? or all threads? | 07:45 |
| rogpeppe | davecheney: hmm, one random thread, it looks like. hurray. | 07:46 |
| davecheney | rogpeppe: yup, but all threads wouldn't help either | 07:47 |
| rogpeppe | davecheney: if it was all threads we could block the signals in all but the one we care about and ignore if we find no m, no? | 07:47 |
| davecheney | rogpeppe: good point, but i'm sure that was tried and found wanting | 07:48 |
| rogpeppe | davecheney: better would be if a thread had to explicitly enable signals rather than receiving them by default | 07:50 |
| davecheney | /home/dfc/src/launchpad.net/juju-core/testing/mgo.go:119: c.Fatal("Test left sockets in a dirty state") | 07:53 |
| davecheney | what does this mean ? | 07:53 |
| fwereade_ | davecheney, sorry, no idea... failed to delete them maybe? | 08:04 |
| davecheney | fwereade_: i was leaking a mgo.Session | 08:13 |
| davecheney | my fault | 08:13 |
| fwereade_ | np | 08:14 |
| rogpeppe | davecheney: do you know a way of reliably reproducing the signal problem. my naive attempt doesn't fail: http://paste.ubuntu.com/1188513/ | 08:14 |
| davecheney | rogpeppe: not really | 08:14 |
| davecheney | it is quite rare | 08:14 |
| davecheney | deinfitely run with high GOMAXPROCS | 08:14 |
| rogpeppe | davecheney: if the issue is what we think it is (the signal is randomly delivered to some thread), i can't see why the above code doesn't trigger the issue | 08:16 |
| davecheney | rogpeppe: try firing the signal from the C side | 08:17 |
| rogpeppe | davecheney: i tried firing the signal from the command line. no difference. | 08:21 |
| davecheney | rogpeppe: i'm not surprised, it's not supposed to happen | 08:22 |
| rogpeppe | davecheney: well... how can they be stopping it from happening? | 08:22 |
| davecheney | 'supposed to happen' == no panic | 08:22 |
| rogpeppe | davecheney: i've seen a couple more failures of the TestSSHConnect test BTW. (one just now and another one yesterday). | 08:30 |
| rogpeppe | davecheney: it concerns me | 08:31 |
| davecheney | rogpeppe: my suggestion to that would be to switch to the ssh crypto package | 08:31 |
| rogpeppe | davecheney: i'd love to. we started off trying that direction, but it wasn't mature enough. | 08:32 |
| davecheney | rogpeppe: all it needs to support for loading keys off disk (in the same order that ssh does it) | 08:33 |
| davecheney | and talking to the ssh agent (which we have now) | 08:33 |
| davecheney | i'll put it on my list for this weekend | 08:33 |
| davecheney | must fly | 08:33 |
| Aram | moin. | 08:42 |
| fwereade_ | Aram, heyhey | 08:58 |
| fwereade_ | rogpeppe, trivial: https://codereview.appspot.com/6490086 | 09:16 |
| rogpeppe | fwereade_: LGTM | 09:17 |
| fwereade_ | rogpeppe, cheers | 09:17 |
| rogpeppe | fwereade_: pity it had never been tested live before... | 09:17 |
| fwereade_ | rogpeppe, indeed | 09:17 |
| * Aram has troubles finding flights to lisbon. | 09:34 | |
| rogpeppe | fwereade_: need trivial LGTM please: https://codereview.appspot.com/6494090 | 10:12 |
| * fwereade_ looks | 10:12 | |
| fwereade_ | LGTM | 10:13 |
| fwereade_ | rogpeppe, ^ | 10:13 |
| rogpeppe | fwereade_: ta! | 10:13 |
| * rogpeppe is ashamed to have broken the build :-( | 10:13 | |
| rogpeppe | fwereade_: FWIW, i think a string argument to AgentToolsDir is still ok. each agent can decide on its own name, no? | 10:23 |
| rogpeppe | fwereade_: (i just saw your discussion with gustavo last night) | 10:24 |
| fwereade_ | rogpeppe, it happens ;p | 10:24 |
| fwereade_ | rogpeppe, kinda... but, atm, everybody has to prepend unit-, and deslash, whenever they want to specify a unit name | 10:25 |
| fwereade_ | rogpeppe, this feels kinda icky | 10:25 |
| fwereade_ | rogpeppe, although I am also not 100% sold on KeyPath | 10:26 |
| rogpeppe | fwereade_: i'm not sure what you mean. unit names aren't prepended with "unit-" AFAICS | 10:26 |
| rogpeppe | fwereade_: the *agent name* for a unit is though | 10:27 |
| fwereade_ | rogpeppe, isn't that what AgentToolsDir expects? | 10:27 |
| rogpeppe | fwereade_: yes, but how often do you need to call AgentToolsDir? | 10:27 |
| fwereade_ | rogpeppe, a few places that may eventually coalesce into one place | 10:28 |
| fwereade_ | rogpeppe, the hook env needs it, EnsureJujucSymlinks needs it | 10:28 |
| fwereade_ | rogpeppe, container needs it | 10:29 |
| rogpeppe | fwereade_: why does the hook env need it? | 10:29 |
| fwereade_ | rogpeppe, so we can put it on the PATH | 10:29 |
| rogpeppe | fwereade_: why not just do that in the uniter main? | 10:30 |
| fwereade_ | rogpeppe, and, later, add it as an explicit env var for use when setting up juju-run commands | 10:30 |
| fwereade_ | rogpeppe, because it's only needed by the hooks? | 10:30 |
| rogpeppe | fwereade_: fair enough. i'd probably do something like uniter.AgentName(unit *state.Unit) string | 10:31 |
| rogpeppe | fwereade_: or even uniter.ToolsDir(unit *state.Unit) string | 10:31 |
| fwereade_ | rogpeppe, not unreasonable for container to know about uniter, I guess... and environs doesn't need to know about uniters, because that's always done by machiner... yeah, probably good | 10:33 |
| rogpeppe | fwereade_: yeah, i hadn't thought about container needing to know about uniter, but as you say, sounds reasonable, as it's starting the worker (indirectly) | 10:34 |
| fwereade_ | rogpeppe, yeah, exactly | 10:34 |
| fwereade_ | rogpeppe, a further thought | 10:36 |
| fwereade_ | rogpeppe, if we do have a consistent "kind-name" badge for the various agents, which sounds sensible, we really should be using it in more places than just AgentToolsDir | 10:37 |
| fwereade_ | rogpeppe, it should be in logfile names, for example | 10:37 |
| rogpeppe | fwereade_: that seems like a good plan | 10:38 |
| rogpeppe | davecheney: did you have any further discussion with niemeyer about your CL https://codereview.appspot.com/6499071 | 11:12 |
| rogpeppe | ? | 11:12 |
| rogpeppe | davecheney: i'm not sure i understand his objections | 11:12 |
| rogpeppe | davecheney: but perhaps his objections are *only* to the CL description | 11:14 |
| davecheney | rogpeppe: no, i will try again tomorrow | 11:14 |
| rogpeppe | davecheney: and if it was changed to "most uses just want the *Machine" it would be ok | 11:14 |
| davecheney | rogpeppe: couldn't hurt | 11:14 |
| rogpeppe | davecheney: although he's right - there's actually *no* real code that wants the Machine rather than the id | 11:16 |
| davecheney | rogpeppe: it's probably not worth the discussion | 11:20 |
| davecheney | what I have works | 11:20 |
| davecheney | and there are so many more important things do to | 11:20 |
| rogpeppe | true 'nufff | 11:20 |
| * rogpeppe goes for some lunch | 12:47 | |
| rogpeppe | niemeyer: morning! | 12:58 |
| niemeyer | rogpeppe: Morning! | 13:35 |
| niemeyer | Hello all! | 13:35 |
| rogpeppe | niemeyer: thanks for the review! | 13:35 |
| niemeyer | rogpeppe: np, thanks for all the niceties | 13:35 |
| rogpeppe | niemeyer: no problem at all | 13:35 |
| rogpeppe | niemeyer: i don't think there are two round trips to get machine id and machine. in state i think that's true anyway. or are you thinking of mstate? | 13:36 |
| niemeyer | rogpeppe: Sorry, your logic escapes me.. you mean that state.Machine(id) doesn't have a roundtrip to the state server? | 13:37 |
| rogpeppe | niemeyer: no, i'm saying that MachindId needs the round trip anyway | 13:37 |
| rogpeppe | MachineId | 13:38 |
| rogpeppe | AssignedMachineId even | 13:38 |
| niemeyer | rogpeppe: The logic still escapes me.. the CL makes it call Machine, always | 13:38 |
| niemeyer | rogpeppe: Machine has a roundtrip to the state server, both in state and in mstate | 13:38 |
| rogpeppe | niemeyer: ah yes, you're right. that's wrong. but we can construct the machine from the topology without needing an extra round trip. | 13:40 |
| niemeyer | rogpeppe: No, we can't, because we use cached state in mstate | 13:41 |
| rogpeppe | niemeyer: ah, so Unit.AssignedMachineId doesn't go to the server? | 13:41 |
| niemeyer | rogpeppe: Yes, and Machine has to go to the server to get the machine state | 13:42 |
| rogpeppe | niemeyer: right, gotcha. presumably we *could* fetch the machine too when we fetch the unit. | 13:42 |
| niemeyer | rogpeppe: Dude.. | 13:42 |
| rogpeppe | lol | 13:43 |
| rogpeppe | ok ok | 13:43 |
| fwereade_ | huh, are we not actually using --juju-directory for anything? | 14:02 |
| mramm | Hi all. I was on swap yesterday, but am back now. | 14:40 |
| mramm | Just got off a call about doing a Juju marketing video | 14:40 |
| Aram | hi mramm | 14:40 |
| fwereade_ | mramm, heyhey | 14:40 |
| fwereade_ | mramm, I deployed something yesterday, would you believe? | 14:40 |
| mramm | I'm also working on the info for the website, a juju webinar slide deck, and talking to jorge about marketing juju to developers and using it as a DIY PaaS. | 14:41 |
| mramm | fwereade_: That is AWESOME! | 14:41 |
| mramm | fwereade_: Everybody's hard work is coming together! | 14:41 |
| fwereade_ | mramm, yep :D | 14:42 |
| mramm | I am excited! | 14:42 |
| fwereade_ | mramm, now ofc I have to hammer it into proposable shape | 14:42 |
| mramm | and using too many exclamation points!!!!!!!!!!!!! | 14:42 |
| fwereade_ | mramm, but that shouldn't be too far off | 14:42 |
| mramm | fwereade_: great! | 14:42 |
| mramm | I am excited about the juju video | 14:43 |
| mramm | the people we've got working on it seem competent | 14:43 |
| rogpeppe | fwereade: you'll be pleased to know that authorisation of internal traffic now works | 14:43 |
| fwereade | rogpeppe, sweet | 14:44 |
| fwereade | mramm, (that was the only manual step) | 14:44 |
| rogpeppe | fwereade: just waiting on a live test that checks that both machine agents upgrade | 14:44 |
| rogpeppe | YAY! | 14:44 |
| rogpeppe | it works | 14:44 |
| * fwereade cheers | 14:44 | |
| mramm | I also had a talk with Clint about packaging juju for Ubuntu on Tuesday night | 14:44 |
| mramm | rogpeppe: AWESOME! | 14:44 |
| mramm | so very much awesome going on right now! | 14:45 |
| rogpeppe | fwereade: 3.87s to upgrade both agents FYI | 14:45 |
| rogpeppe | fwereade: and that's using the proper deploy infrastructure, juju.AddService, AddUnits, etc | 14:46 |
| fwereade | rogpeppe, sweeet | 14:46 |
| rogpeppe | fwereade: yeah, it's nice to have some functional tests that are a bit higher level | 14:47 |
| rogpeppe | fwereade: it's just a pity that pushing the tools takes so long. sometimes as long as 5 minutes. | 14:49 |
| rogpeppe | fwereade: it would have been done earlier if amazon's docs weren't so crap :-) | 14:51 |
| fwereade | rogpeppe, ha, I know your pain | 14:52 |
| mramm | rogpeppe: haha | 14:53 |
| mramm | So, I have a product review meeting tomorrow | 14:53 |
| mramm | if you have things you think I should give management heads up on, let me know | 14:53 |
| mramm | I've got the unit agent, updater, mongo, and marketing update basics figured out | 14:54 |
| mramm | so if you have any additional detail you think is important on those things, or any other stuff that people need to know about, shoot it on over. | 14:55 |
| fwereade | rogpeppe, niemeyer: sanity check on http://paste.ubuntu.com/1189087/ if yu have a mo | 14:57 |
| fwereade | niemeyer, KeyPath on state entities was not so nice in the end -- we don't always have the state entities available | 14:58 |
| fwereade | niemeyer, but I *think* this ends up quite neat | 14:58 |
| fwereade | niemeyer, rogpeppe: I would almost certainly want to pair it with a PathSuite or something that swaps out LibDir, LogDir, InitDir | 15:00 |
| fwereade | niemeyer, (and possibly $HOME, why not, eh?) | 15:00 |
| niemeyer | juju/testing/conn.go:// It also sets up $HOME and environs.VarDir to | 15:01 |
| niemeyer | fwereade: ^ | 15:01 |
| fwereade | niemeyer, yeah; and a lot of other tests swap one or both of those out here or there | 15:01 |
| fwereade | niemeyer, it was moving environs.VarDir that made me think "ouch, too much duplication" | 15:02 |
| niemeyer | fwereade: My only concern is that right now we already have an Agent with an interface | 15:03 |
| fwereade | niemeyer, but if I could find a sensible name, it would probably be ok? | 15:03 |
| fwereade | niemeyer, and actually I'm not sure agent.Spec is all that much subject to confusion | 15:04 |
| fwereade | niemeyer, wait a mo, there is no Agent interface that I can find | 15:05 |
| fwereade | niemeyer, now I want to just call that an Agent :) | 15:05 |
| niemeyer | fwereade: cd cmd/jujud; grep Agent * | 15:06 |
| fwereade | niemeyer, I see AgentConf and AgentState | 15:08 |
| niemeyer | fwereade: Uh? | 15:08 |
| niemeyer | fwereade: UnitAgent, MachineAgent, ProvisioningAgent, AgentState, AgentConf, etc etc | 15:08 |
| fwereade | niemeyer, ok... you said we had an Agent with an interface, maybe I mistook what you meant | 15:09 |
| niemeyer | fwereade: AgentConf being JujuDir + StateInfo.. | 15:09 |
| fwereade | niemeyer, ah yeah, mean to mention that, JujuDir is not used | 15:09 |
| niemeyer | fwereade: I mean that the concepts you're playing with already exist | 15:10 |
| niemeyer | fwereade: We can't just add another package without sorting their situation out | 15:10 |
| fwereade | niemeyer, ok, I see now | 15:10 |
| fwereade | niemeyer, well, JujuDir doesn't actually do anything | 15:10 |
| niemeyer | fwereade: That won't change if we just add another package :) | 15:10 |
| fwereade | niemeyer, but I'm pretty sure what it *should* do is overwrite environs.VarDir (which would be agent.LibDir) | 15:11 |
| rogpeppe | niemeyer: https://codereview.appspot.com/6500089 | 15:20 |
| niemeyer | rogpeppe: Cheers.. I think I'll focus a bit on the watcher today, though, otherwise we'll never have it | 15:21 |
| rogpeppe | niemeyer: no problem | 15:21 |
| rogpeppe | niemeyer: you'll be glad to know that this enables the uniter stuff to work live though | 15:21 |
| niemeyer | rogpeppe: Wow, sweet! | 15:21 |
| rogpeppe | niemeyer: and that it tests two machine agents upgrading at the same time | 15:21 |
| rogpeppe | niemeyer: through the juju.Conn deploy machinery | 15:22 |
| niemeyer | rogpeppe: Oh man | 15:22 |
| niemeyer | rogpeppe: It's coming together | 15:22 |
| rogpeppe | niemeyer: if nothing else, just have a brief glance at https://codereview.appspot.com/6500089/diff/2001/environs/jujutest/livetests.go | 15:22 |
| rogpeppe | niemeyer: (i'm really happy that worked) | 15:23 |
| niemeyer | rogpeppe: Impressive indeed.. even more impressive to have that as a stock test | 15:25 |
| rogpeppe | niemeyer: yeah, i'm happy about that | 15:27 |
| niemeyer | fwereade: wb | 15:30 |
| rogpeppe | fwereade: https://codereview.appspot.com/6500089 | 15:30 |
| niemeyer | fwereade: I sent you and -dev a mail | 15:30 |
| niemeyer | fwereade: With the feedback, before I forget and so that I could move on | 15:30 |
| fwereade | niemeyer, cheers, I will take a look | 15:30 |
| fwereade | niemeyer, yeah, consider my mind already churning on these thoughts | 15:32 |
| niemeyer | fwereade: +1, cheers | 15:33 |
| rogpeppe | fwereade: shouldn't JujuDir set environs.VarDir? | 15:38 |
| fwereade | rogpeppe, I intimated as much above | 15:38 |
| rogpeppe | f.StringVar(&environs.VarDir, "juju-directory", environs.VarDir, "juju working directory") | 15:39 |
| rogpeppe | fwereade: oh yes, i didn't notice that | 15:39 |
| fwereade | rogpeppe, although I am starting to feel dissatisfied with its globalness, and am wondering if we really need it | 15:39 |
| rogpeppe | fwereade: yeah, i'd be happy for it to avoid globalness | 15:40 |
| rogpeppe | fwereade: i think most of environs/tools.go could happily fit in a new package | 15:41 |
| rogpeppe | fwereade: with no globals | 15:41 |
| rogpeppe | fwereade: maybe just a package called "tools" | 15:42 |
| rogpeppe | aw | 15:42 |
| rogpeppe | fwereade: last thing you saw? | 15:43 |
| rogpeppe | fwereade: last thing from you i saw was | 15:43 |
| rogpeppe | [16:39:26] <fwereade> rogpeppe, although I am starting to feel dissatisfied with its globalness, and am wondering if we really need it | 15:43 |
| fwereade | rog, I saw fwereade: i think most of environs/tools.go could happily fit in a new package | 15:48 |
| rogpeppe | 16:41:37] <rogpeppe> fwereade: with no globals | 15:49 |
| rogpeppe | [16:42:19] <rogpeppe> fwereade: maybe just a package called "tools" | 15:49 |
| fwereade | rogpeppe, I was just pondering exactly that while having a ciggie :) | 15:49 |
| rogpeppe | fwereade: because that's what this is all about, i *think* | 15:49 |
| fwereade | rogpeppe, yeah, there's a sideline in "bits of container look awfully like bits of cloudinit" -- which originally started me off on this jaunt -- but you are absolutely right | 15:50 |
| niemeyer | Lunch break | 15:52 |
| rogpeppe | fwereade: which bits were you thinking of? | 15:54 |
| fwereade | rogpeppe, just the bits that create Confs are awfully similar and mildly tediously inconsistent | 15:54 |
| fwereade | rogpeppe, not a big deal at all really, but it was nagging at me | 15:54 |
| rogpeppe | fwereade: Conf? | 15:55 |
| fwereade | rogpeppe, upstart.Conf | 15:55 |
| rogpeppe | fwereade: yeah, i think that code would fit quite happily in a tools package | 15:58 |
| * rogpeppe is quickly hacking together a sketch | 16:03 | |
| rogpeppe | fwereade: how about something like this? http://paste.ubuntu.com/1189197/ | 16:09 |
| rogpeppe | fwereade: a few bits tidied up: | 16:10 |
| rogpeppe | package tools | 16:10 |
| rogpeppe | // SearchFlags gives options when searching for tools. | 16:10 |
| rogpeppe | type SearchFlags int | 16:10 |
| rogpeppe | const ( | 16:10 |
| rogpeppe | // HighestVersion indicates that versions above the version being | 16:10 |
| rogpeppe | // searched for may be included in the search. The default behavior | 16:10 |
| rogpeppe | // is to search for versions <= the one provided. | 16:10 |
| rogpeppe | HighestVersion SearchFlags = 1 << iota | 16:10 |
| rogpeppe | // DevVersion includes development versions in the search, even | 16:10 |
| rogpeppe | // when the version to match against isn't a development version. | 16:10 |
| rogpeppe | DevVersion | 16:10 |
| rogpeppe | // CompatVersion specifies that the major version number | 16:10 |
| rogpeppe | // must be the same as specified. At the moment this flag is required. | 16:10 |
| rogpeppe | CompatVersion | 16:10 |
| rogpeppe | ) | 16:10 |
| rogpeppe | // List holds a list of available tools. Private tools take | 16:10 |
| rogpeppe | // precedence over public tools, even if they have a lower | 16:10 |
| rogpeppe | // version number. | 16:10 |
| rogpeppe | type List struct { | 16:10 |
| rogpeppe | Private []*state.Tools | 16:10 |
| rogpeppe | Public []*state.Tools | 16:10 |
| rogpeppe | } | 16:11 |
| rogpeppe | // ListAll returns a List holding all the tools | 16:11 |
| rogpeppe | // available in the given environment that have the | 16:11 |
| rogpeppe | // given major version. | 16:11 |
| rogpeppe | func ListAll(env Environ, majorVersion int) (*List, error) | 16:11 |
| rogpeppe | // Put builds the current version of the juju tools, uploads them | 16:11 |
| rogpeppe | // to the given storage, and returns a Tools instance describing them. | 16:11 |
| rogpeppe | // If vers is non-nil it will override the current version in the uploaded | 16:11 |
| rogpeppe | // tools. | 16:11 |
| rogpeppe | oops | 16:11 |
| rogpeppe | sorry everyone | 16:11 |
| rogpeppe | i meant this: http://paste.ubuntu.com/1189199/ | 16:11 |
| rogpeppe | fwereade: http://paste.ubuntu.com/1189199/ | 16:13 |
| rogpeppe | hmm, i wonder if i've been muted | 16:17 |
| fwereade | rogpeppe, sorry, I can hear you | 16:18 |
| rogpeppe | np | 16:18 |
| fwereade | rogpeppe, it looks sane, I think, I'm not sure exactly how it will square with the other wild ideas I am chasing | 16:18 |
| rogpeppe | fwereade: what kind of thing are you thinking of? | 16:19 |
| fwereade | rogpeppe, agent.Agent, and what exactly it should have attached to it, if it should even exist | 16:19 |
| rogpeppe | fwereade: i'm not convinced it should exist | 16:20 |
| rogpeppe | fwereade: an agent is its own beast | 16:20 |
| fwereade | rogpeppe, there are an *awful* lot of commonalities across agents, I think there is a useful common structure waiting to emerge | 16:21 |
| rogpeppe | fwereade: i go along with niemeyer's comments in this respect | 16:21 |
| rogpeppe | fwereade: when it emerges, we can factor it out | 16:21 |
| rogpeppe | fwereade: as particular chunks of functionality | 16:21 |
| fwereade | rogpeppe, I think it's worth an overnight ponder at least :) | 16:22 |
| rogpeppe | fwereade: saying "*this* is an agent" is a bit like the inheritance way of thinking, i think | 16:22 |
| fwereade | rogpeppe, I guess it is somewhat predicated on the assumption that an agent should correspond to a single state entity | 16:22 |
| rogpeppe | fwereade: indeed | 16:22 |
| rogpeppe | fwereade: which may very well not be the case in the future | 16:22 |
| rogpeppe | fwereade: well... i guess we will probably always have at least one item in the state for an agent | 16:23 |
| fwereade | rogpeppe, hmm -- so it's workers that should correspond to state entities? | 16:23 |
| rogpeppe | fwereade: no | 16:23 |
| rogpeppe | fwereade: it's running processes | 16:24 |
| rogpeppe | fwereade: i.e. things that can upgrade themselves | 16:24 |
| fwereade | rogpeppe, ok (is there now a Provisioner state entity that I haven't noticed?) | 16:24 |
| rogpeppe | fwereade: but i may very well be seeing through very upgrading-centric eyes currently :-) | 16:24 |
| rogpeppe | fwereade: no, but there will be | 16:24 |
| rogpeppe | fwereade: of some kind | 16:24 |
| rogpeppe | fwereade: otherwise we can't tell when a PA manages to upgrade itself | 16:25 |
| fwereade | rogpeppe, cool, thought so, and this just makes all the agents look even more similar to me, but indeed the stars might not yet be aligned | 16:26 |
| rogpeppe | fwereade: there are definitely similarities | 16:26 |
| rogpeppe | fwereade: but we can abstract those out when we need some common functionaliy | 16:26 |
| rogpeppe | ty | 16:26 |
| rogpeppe | fwereade: what kinds of operations do you envisage on agent.Agent? | 16:27 |
| rogpeppe | fwereade: would it be a concrete type or an interface? | 16:28 |
| SpamapS | Hello golangian friends. I am wondering, are there any examples of Go applications already packaged (via PPA, or even in the Ubuntu archive) ? | 16:48 |
| SpamapS | and on a related note, I am looking at writing a charm in Go as an exercise, and wondering how best to do it.. #!/usr/bin/gorun is great for prototyping, but at some point I think I'll want to just compile it | 16:49 |
| niemeyer | SpamapS: lbox and cobzr might be good examples to start with | 17:00 |
| niemeyer | SpamapS: They're both in PPAs | 17:00 |
| SpamapS | niemeyer: perfect | 17:00 |
| niemeyer | SpamapS: and auto-building | 17:00 |
| * SpamapS already has the PPA's for those.. apt-get source to the rescue | 17:00 | |
| SpamapS | niemeyer: any reason you had to be so explicit on binary-arch here: http://bazaar.launchpad.net/~niemeyer/lbox/package/view/head:/debian/rules | 17:02 |
| SpamapS | niemeyer: seems like an override_dh_install: might have handled that. | 17:03 |
| TheMue | hiho | 17:07 |
| TheMue | niemeyer: ping | 17:07 |
| rogpeppe | SpamapS: i had some ideas about writing charms in Go, but haven't had time to do anything about them yet | 17:07 |
| SpamapS | rogpeppe: it seems a bit heavy handed for most charm duties. | 17:07 |
| rogpeppe | SpamapS: yeah, a shell script is often a good fit | 17:08 |
| SpamapS | which boil down to "parse this file. put that file over there. run this command" .. | 17:08 |
| niemeyer | TheMue: Pong | 17:08 |
| niemeyer | SpamapS: Hmm | 17:08 |
| SpamapS | rogpeppe: I'm actually finding puppet's DSL quite good and succinct for charm duties. ;) | 17:08 |
| TheMue | niemeyer: just wanted to inform you that the CLs are in | 17:08 |
| niemeyer | TheMue: Beautiful, thanks | 17:09 |
| * rogpeppe hasn't actually looked at puppet yet | 17:09 | |
| TheMue | niemeyer: You had some notes on the first and not on the second and vice versa. I applied them on both. | 17:09 |
| SpamapS | rogpeppe: the biggest drawback is that you have to bust out to ruby to do anything interesting | 17:09 |
| niemeyer | TheMue: Well, actually you didn't, as I mentioned in the review, but that's fine | 17:10 |
| TheMue | niemeyer: Like the tabs, the panic message and the comment. | 17:10 |
| niemeyer | TheMue: We can sort out these details when you're back | 17:10 |
| niemeyer | TheMue: Ah, yeah, that was great,thanks | 17:10 |
| TheMue | niemeyer: What exactly you are referring? | 17:10 |
| rogpeppe | SpamapS: interesting. ruby's Yet Another Language I Have Never Used | 17:10 |
| rogpeppe | SpamapS: i always figured it was too close to python to be worth learning unless i needed to. | 17:10 |
| niemeyer | TheMue: The three points in the review | 17:10 |
| TheMue | niemeyer: WaitAgentAlive() on Unit? | 17:11 |
| niemeyer | TheMue: Where I suggested they might be done in a different CL | 17:11 |
| SpamapS | rogpeppe: more like perl meets javascript | 17:11 |
| niemeyer | TheMue: There's a bug opened as well with them now | 17:11 |
| TheMue | niemeyer: Yeah, the Dying and the Alive error, but not the removal of the loop. | 17:11 |
| niemeyer | TheMue: Don't worry, what's going in is a great start, and we can easily sort the points out in a follow up when you're back | 17:11 |
| TheMue | TheMue: You made the comment not on the last checkin. | 17:12 |
| niemeyer | SpamapS: I don't really know.. I bet there are better ways to handle it.. I'm just not a well versed packager | 17:12 |
| rogpeppe | SpamapS: anyway, Go might be good for charms that do a lot of orchestration dancing | 17:12 |
| SpamapS | niemeyer: its really only a future-proofing thing anyway.. the way its written now is 100% correct | 17:12 |
| SpamapS | rogpeppe: right, I was thinking of centralized things that have to handle all coming/going .. like monitoring or logging | 17:13 |
| rogpeppe | SpamapS: i reckon you could write it in good Go style, as a goroutine that receives "charm-hook-execute" events in a loop, then acts on the hook and replies. | 17:13 |
| TheMue | niemeyer: Please take a look at https://codereview.appspot.com/6494073/diff/2002/mstate/unit.go at line 230ff | 17:14 |
| rogpeppe | SpamapS: rather than our traditional "you get called when a hook happens" model | 17:14 |
| niemeyer | TheMue: Ok? | 17:14 |
| TheMue | niemeyer: It's now w/o the loop, like for Machine. | 17:15 |
| rogpeppe | SpamapS: but these thoughts are only fleeting and unformed... | 17:15 |
| niemeyer | TheMue: Ok, that's great | 17:15 |
| SpamapS | rogpeppe: thats actually what I was thinking too. But I think such things will only be necessary in the extreme cases where something has many thousands of related service units. | 17:17 |
| SpamapS | rogpeppe: for 99% of the cases.. python/ruby/bash will be up to the task of running a hook every few seconds. | 17:18 |
| rogpeppe | SpamapS: it's not necessarily about large scale - it could make it easier to make logic simpler | 17:18 |
| SpamapS | rogpeppe: I doubt that. :) | 17:18 |
| TheMue | Fine, now I can leave relaxed. I will look into mail via phone to stay informed during my vacation. It's an exciting time for juju. | 17:18 |
| rogpeppe | SpamapS: you may well be right :-) | 17:19 |
| SpamapS | rogpeppe: simpler to a go developer maybe.. but not to a charmer. :) | 17:19 |
| SpamapS | the most insanely complex charms are still pretty straight forward | 17:19 |
| rogpeppe | SpamapS: well, i certainly intend to write some more charms at some point :-) | 17:19 |
| rogpeppe | SpamapS: also, i have a feeling we'll get more golangers coming along in the python/ruby space, though i may be wrong in that | 17:20 |
| SpamapS | http://www.cloudifysource.org/ | 17:20 |
| SpamapS | another juju-like project | 17:20 |
| niemeyer | TheMue: Yeah, have a great time there | 17:30 |
| TheMue | niemeyer: Thx, the weather forecast looks good, so we'll have some fine days (and evenings with a bottle of wine) at the water. It's only already too cold for swimming. | 17:31 |
| rogpeppe | i'm off for too. have fun all. see you tomorrow! | 17:36 |
| rogpeppe | TheMue: enjoy your break! | 17:36 |
| TheMue | gn rogpeppe | 17:36 |
| TheMue | and thank you | 17:36 |
| fwereade | niemeyer, ping | 21:06 |
| niemeyer | fwereade: Pongus | 21:06 |
| fwereade | niemeyer, I think trunk is broken, I'm getting a panic from somewhere inside presence in the mstate tests... just verifying it *actually* happens on trunk, not just my merged version | 21:07 |
| fwereade | niemeyer, if it is, is it still ok to submit over the top? | 21:07 |
| niemeyer | fwereade: Can you please paste the panic? | 21:07 |
| fwereade | niemeyer, https://bugs.launchpad.net/juju-core/+bug/1047051 | 21:07 |
| niemeyer | fwereade: Yeah, if that's the only failure, it'd be fine | 21:07 |
| fwereade | niemeyer, cool, thanks | 21:07 |
| fwereade | niemeyer, yeah, trunk too | 21:07 |
| niemeyer | fwereade: Ah, ok.. I can tell what it is | 21:08 |
| niemeyer | fwereade: I've missed that when reviewing Frank's branch | 21:08 |
| fwereade | niemeyer, ++psychic debugging :) | 21:08 |
| niemeyer | fwereade: We're creating a watcher and not stopping | 21:08 |
| fwereade | niemeyer, jolly good, could be worse ;) | 21:08 |
| niemeyer | fwereade: Hehe :) | 21:08 |
| niemeyer | fwereade: I'll fix it as soon as I stop the current line of thinking here | 21:09 |
| fwereade | niemeyer, lovely, tyvm | 21:09 |
| niemeyer | fwereade: Sorry for the trouble | 21:09 |
| fwereade | niemeyer, no trouble :) | 21:09 |
| niemeyer | fwereade: ping | 22:11 |
| fwereade | niemeyer, pong | 22:11 |
| niemeyer | fwereade: Yo | 22:11 |
| fwereade | niemeyer, how's it going? | 22:11 |
| niemeyer | fwereade: Up for a quick review fixing that issue? | 22:11 |
| fwereade | niemeyer, absolutely | 22:11 |
| fwereade | niemeyer, then sleepytime ;) | 22:11 |
| niemeyer | fwereade: Cool, pushing | 22:11 |
| niemeyer | fwereade: I bet! 8) | 22:13 |
| niemeyer | fwereade: https://codereview.appspot.com/6510043 | 22:15 |
| niemeyer | I've screwed up the description.. fixing meanwhile | 22:15 |
| fwereade | niemeyer, LGTM | 22:16 |
| niemeyer | Done | 22:16 |
| niemeyer | fwereade: Cheers! | 22:16 |
| fwereade | niemeyer, btw, I think I have convinced myself that the reset --soft is pure superstition; and that in any cases which may exist in which deleting the lock file is insufficient, we really can't do anything about this | 22:30 |
| fwereade | niemeyer, *but* that I also shouldn't even try to recover on unit agent startup -- the user could very easily be logged in and messing with the dir while the uniter is in an error state, and we can't just charge in and start doing stuff | 22:31 |
| niemeyer | fwereade: Ah, cool, thanks for the note.. I really wasn't sure | 22:31 |
| fwereade | niemeyer, so I now want to just speculatively delete the lock file before every command that hits the index | 22:32 |
| niemeyer | fwereade: Sounds good.. your atomicity scheme kind of makes it unnecessary as long as the automated process is concerned, so sounds sane | 22:32 |
| niemeyer | fwereade: Uh oh | 22:32 |
| fwereade | niemeyer, hm, is that bad? | 22:33 |
| niemeyer | fwereade: Sounds like the two extremes.. | 22:33 |
| niemeyer | fwereade: We're not reseting because the user might be messing around, but we're happy to kill the lock all the time? | 22:33 |
| fwereade | niemeyer, the most authoritative-sounding source I could find was a git list thread from 2009, in which they discussed making the "just delete the lock file" message carry more of that intent | 22:33 |
| fwereade | niemeyer, the only times we have any reason to kill the lock are precisely when we're doing things with the index | 22:34 |
| fwereade | niemeyer, this implies that we are upgrading, or running hooks, and if the user is messing around in the charm dir while we are working that is on hi own head ;) | 22:34 |
| niemeyer | fwereade: I see, so hitting the index as in changing it | 22:35 |
| niemeyer | fwereade: Not just reading, right? | 22:35 |
| fwereade | niemeyer, I'm not sure it'll even read the index when something else has a lock | 22:35 |
| fwereade | niemeyer, but this was in fact done by a process of pure research | 22:36 |
| niemeyer | fwereade: I'd rather start more conservative, if feasible | 22:36 |
| niemeyer | fwereade: The lock is there precisely to avoid processes from stepping on each other | 22:36 |
| fwereade | niemeyer, of all the commands we use: add, commit, pull, reset all require that the lock file not exist | 22:37 |
| niemeyer | fwereade: Sure, because if it exists someone/something else may be acting on the directory | 22:37 |
| niemeyer | fwereade: But, as I understand all the changes are done in independent directories | 22:37 |
| niemeyer | fwereade: With your atomicity mechanisms | 22:37 |
| niemeyer | fwereade: Which means that if we ever see a lock, something awkward is happening | 22:37 |
| niemeyer | fwereade: Breaking when something awkward happens seems legit | 22:38 |
| fwereade | niemeyer, not actually true, but it could be made to be so | 22:38 |
| niemeyer | fwereade: Ah, indeed, the final pull I guess | 22:38 |
| fwereade | niemeyer, yeah, the charm dir itself is not a swappable symlink | 22:38 |
| fwereade | niemeyer, although maybe it should be | 22:38 |
| niemeyer | fwereade: COol, we can leave that | 22:38 |
| niemeyer | fwereade: Even then, I'd be fine with asking the user to go there and fix it for the moment, before we're sure that stuff works fine | 22:39 |
| niemeyer | fwereade: Seems useful to learn about how frequently we'll observe lock files left around and whatnot | 22:39 |
| fwereade | niemeyer, hm, ok, let me think a sec | 22:39 |
| niemeyer | fwereade: We can always change our mind and be less conservative | 22:40 |
| fwereade | niemeyer, in that case I suspect I favour just explicitly blowing up when we see a lock file that wold impede the impending operation | 22:41 |
| fwereade | niemeyer, sane granularity? | 22:41 |
| niemeyer | fwereade: Yeah, that's what I mean | 22:41 |
| niemeyer | fwereade: Ah, explicitly | 22:41 |
| niemeyer | fwereade: You mean checking it's there? | 22:41 |
| fwereade | niemeyer, we shouldn't be operating on the charm dir except at times when the user really shouldn't be operating on the charm dir | 22:41 |
| fwereade | niemeyer, hmm, just let it fail even :) | 22:42 |
| niemeyer | fwereade: Right.. there's no point in checking, since that's exactly the race that the lock file is meant to protect against | 22:42 |
| fwereade | niemeyer, true :) | 22:42 |
| fwereade | niemeyer, I'm just thinking it through... this is a potential new error state | 22:43 |
| niemeyer | fwereade: Really? How is this any different from any other error related to the charm deployment? | 22:44 |
| niemeyer | fwereade: Can't create dir, can't download, etc | 22:44 |
| fwereade | niemeyer, ah, ok, it's a totally-screwed-agent-down-uniter-log-filled-with-errors situation, not a polite-error-message-log-in-nicely-and-resolve-it one? | 22:45 |
| fwereade | niemeyer, I guess all of those are | 22:45 |
| niemeyer | fwereade: Right | 22:45 |
| fwereade | niemeyer, yep, ok, I'm just more scared of git because I'm more aware of my ignorance | 22:46 |
| niemeyer | fwereade: Well.. some of those errors surely are resolvable too, right? | 22:46 |
| niemeyer | fwereade: I'm not sure if you're saying these are conditions we can't recover from or not? | 22:46 |
| fwereade | niemeyer, I'm just saying that currently we don't | 22:47 |
| niemeyer | fwereade: Okay, I'm happy to move on and polish later, but in principle those conditions should also be recoverable | 22:47 |
| niemeyer | fwereade: E.g. a download error is a pretty unexceptional error | 22:48 |
| niemeyer | fwereade: As Amazon would gladly tell you | 22:48 |
| fwereade | niemeyer, so *that* will work just fine assuming the resource is actuallythere... eventually it'll succeed | 22:48 |
| niemeyer | fwereade: Perhaps not gladly, no :-) | 22:48 |
| fwereade | niemeyer, and therefore shouldn't be reported, at least not immediately, because we expect it to be transient | 22:49 |
| niemeyer | fwereade: Right, ok.. so that's what I mean.. I see all of those cases as "wedged, needs action" | 22:49 |
| niemeyer | fwereade: but "juju resolved" in general should mean "Alrightly, will try again and see if that works now" | 22:49 |
| fwereade | niemeyer, I'm not sure I agree that a dropped connection during a download is reason enough to stop doing things until the user comes to help us | 22:51 |
| niemeyer | fwereade: Sorry, yes, you're right.. that's not a good example | 22:52 |
| fwereade | niemeyer, that's the trouble | 22:52 |
| niemeyer | fwereade: I mean a case like "can't create directory" | 22:52 |
| fwereade | niemeyer, some uniter errors are resolvable by time, and others justify a stop-the-world | 22:52 |
| fwereade | niemeyer, we do not as yet have a way of classifying them | 22:53 |
| niemeyer | fwereade: I see, ok | 22:53 |
| fwereade | niemeyer, it would be a nice thing to be able to do so but it also feels like it might get hairy | 22:53 |
| niemeyer | fwereade: I think we might do with some heuristics | 22:54 |
| niemeyer | fwereade: without having to put them in separate buckets | 22:54 |
| fwereade | niemeyer, so, given that, I would like to just drop the concept of recovery entirely and let the process fail as it pleases | 22:55 |
| niemeyer | fwereade: E.g. if it's something we want to retry automatically, don't yet tell it's an error | 22:55 |
| niemeyer | fwereade: But if we retry so many times, or for so long, and it's not working, stop trying and get into an error state | 22:55 |
| fwereade | niemeyer, yeah, reasonable -- feels like a different change to just dont-ever-recover though | 22:55 |
| niemeyer | fwereade: This is even a conservative approach to prevent a large system from self-destructing | 22:55 |
| niemeyer | fwereade: Agreed | 22:56 |
| fwereade | niemeyer, but, yeah, absolutely, sounds like what we should be doing to me | 22:56 |
| niemeyer | fwereade: To make things simpler for us to move forward, it's probably fine to start with don't-ever-recover, and move towards auto-retry | 22:56 |
| fwereade | niemeyer, well, auto-retry will happen on everything for free via upstart | 22:57 |
| niemeyer | fwereade: That's not very nice | 22:58 |
| niemeyer | fwereade: We're managing retrying internally in other cases already | 22:58 |
| niemeyer | fwereade: E.g. connections to state | 22:58 |
| niemeyer | fwereade: Well, all errors really | 22:59 |
| niemeyer | fwereade: In other agents we manage retry-after-error internally | 22:59 |
| fwereade | niemeyer, oh, er, yeah, sorry, I *did* copy that bit in from the machine agent | 23:00 |
| fwereade | niemeyer, ok, I see where you're coming from now | 23:00 |
| fwereade | niemeyer, so managing the heuristics becomes a little easier, and it's still a good idea to add some sort of heuristics | 23:01 |
| fwereade | niemeyer, er, sorry nonsense | 23:01 |
| fwereade | niemeyer, it feels to me like "try again" should always be reasonable behaviour if we've written the workers right | 23:02 |
| fwereade | niemeyer, the spinning and logspam are unsightly, it is true | 23:03 |
| niemeyer | fwereade: It is always true, but in some cases we may need authorization to do so, due to the non-idempotency of some operation | 23:04 |
| fwereade | niemeyer, and that should be handled internally by the uniter, surely? | 23:05 |
| fwereade | niemeyer, the uniter knows about these things; the unit agent just needs to keep a uniter running at all times, except when it's upgrading | 23:05 |
| fwereade | niemeyer, ah ok I think I see a source of confusion | 23:06 |
| niemeyer | fwereade: That, what? | 23:06 |
| fwereade | niemeyer, when I say always-retry is the default I am specifically referring to errors that cause the uniter to fail | 23:06 |
| fwereade | niemeyer, hook errors do not cause the uniter to fail -- when state indicates a hook error, the uniter runs just fine, in a mode in which it waits for resolution | 23:07 |
| fwereade | niemeyer, the uniter will not retry an upgrade or a hook unless requested | 23:07 |
| fwereade | niemeyer, and so it should always be safe for the unit agent to launch a new one after the first has failed | 23:08 |
| niemeyer | fwereade: If a conflict happens on a merge.. how is that handled? | 23:08 |
| fwereade | niemeyer, the GitDir returns ErrConflict, magic happens, the uniter runs ModeConflicted | 23:09 |
| niemeyer | fwereade: and then? | 23:10 |
| fwereade | niemeyer, eventually the user resolves the error, and we pull again, commit, and continue in ModeStarted | 23:10 |
| niemeyer | fwereade: Okay, it is an error that doesn | 23:11 |
| niemeyer | 't cause the uniter to bail out, then? | 23:11 |
| fwereade | niemeyer, exactly | 23:11 |
| niemeyer | fwereade: How's a Conflicted error different from a "directory has a lock" one, from our perspective? | 23:11 |
| fwereade | niemeyer, no different, essentially; this is a point of trouble :/ | 23:12 |
| niemeyer | fwereade: How's it trouble? It seems like a solution.. if it's the same, let's unify the handling | 23:12 |
| fwereade | niemeyer, ha, yes indeed | 23:13 |
| fwereade | niemeyer, there's no good reason for any of the git operations to fail, none of them touch the network | 23:13 |
| fwereade | niemeyer, if they *ever* do we can go straight to help-fix-git-please mode | 23:13 |
| niemeyer | fwereade: Right | 23:14 |
| niemeyer | fwereade: help-fix-deployment even | 23:14 |
| niemeyer | fwereade: heck-were-is-my-data alternatively | 23:14 |
| niemeyer | :-D | 23:14 |
| niemeyer | where | 23:15 |
| fwereade | niemeyer, indeed, it's currently called ModeConflicted and assumes that it's because of an upgrade, but I don;t think that's fundamental, just conincidental | 23:15 |
| fwereade | haha | 23:15 |
| niemeyer | fwereade: Yeah, ModeDeploymentError or something | 23:16 |
| niemeyer | fwereade: status-info ftw | 23:16 |
| fwereade | niemeyer, yep, ok, I think it's all percolating nicely through my brain; time to sleep for now, I hope I'll have time to sort out smarter error handling before too long | 23:22 |
| fwereade | gn | 23:22 |
| niemeyer | fwereade: Have a good night | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!