| twobottux` | aujuju: How can I manage multiple administrators with juju? <http://askubuntu.com/questions/179230/how-can-i-manage-multiple-administrators-with-juju> | 03:02 |
|---|---|---|
| rogpeppe | fwereade_: mornin' | 07:18 |
| fwereade_ | rogpeppe, heyhey | 07:18 |
| rogpeppe | fwereade_: how's the uniter trauma going? | 07:18 |
| fwereade_ | rogpeppe, I *think* it's starting to feel sane again :) | 07:19 |
| fwereade_ | rogpeppe, I'll see what I can pull together this morning :) | 07:20 |
| rogpeppe | fwereade_: cool. i haven't got what the suggested change is. is it to do with using bzr for the upgrading? | 07:20 |
| fwereade_ | rogpeppe, that's actually quite a small part of it -- the stuff I've been having difficulty with is the relatively innocuous suggestion that there shouldn't be any distinction between forced and unforced upgrade operations, and uh, something else I forget | 07:21 |
| rogpeppe | interesting | 07:21 |
| rogpeppe | fwereade_: BTW i just discovered a piece of cmd/juju testing which is fairly crackful - all the DeploySuite tests are executed 4 times each! | 07:23 |
| fwereade_ | rogpeppe, golly | 07:23 |
| fwereade_ | rogpeppe, how did that happen? | 07:23 |
| rogpeppe | fwereade_: it's 'cos other command test suites are embedding DeploySuite | 07:24 |
| rogpeppe | fwereade_: not quite sure how that got past my radar | 07:24 |
| fwereade_ | rogpeppe, gaaaaah | 07:24 |
| fwereade_ | rogpeppe, well, hey, faster tests :) | 07:24 |
| fwereade_ | rogpeppe, nice catch | 07:24 |
| rogpeppe | fwereade_: now i just have to work out how much of DeploySuite can be replaced by JujuConnSuite | 07:24 |
| * fwereade_ hopes lots | 07:25 | |
| rogpeppe | fwereade_: lots but... maybe not all; i think perhaps the JUJU_REPOSITORY setting needs to remain | 07:25 |
| fwereade_ | rogpeppe, still :) | 07:25 |
| rogpeppe | yeah | 07:25 |
| TheMue | morning | 08:41 |
| fwereade_ | TheMue, heyhey | 08:44 |
| TheMue | fwereade_: heya | 08:44 |
| * niemeyer waves | 08:54 | |
| fwereade_ | niemeyer, heyhey | 08:59 |
| fwereade_ | niemeyer, nice response :) | 09:00 |
| fwereade_ | niemeyer, (on the list) | 09:00 |
| niemeyer | fwereade_: Morning! | 09:02 |
| niemeyer | fwereade_: Cheers.. tricky too | 09:02 |
| fwereade_ | getting coffee + sunlight, bbs | 09:07 |
| niemeyer | Nice plan | 09:07 |
| niemeyer | No sun here yet, but I could get some coffee | 09:08 |
| TheMue | niemeyer, Aram: you should get a link to a document via mail. so far e don't use very much watchers in trunk. | 10:58 |
| Aram | cheers. | 10:58 |
| niemeyer | TheMue: Sure, but the question is which watchers are needed/used | 10:59 |
| niemeyer | TheMue: You can talk to William to see details of the unit agent, and the Python code base for evaluation | 10:59 |
| Aram | niemeyer: I tried yesterday an experiment. I saw that you defined a local M type in txn and used that instead of the cluncky bson.M. I tried the same with bson.D in mstate. I did a local type D []bson.DocElem and then s/bson\.D/D/g but it won't work, any idea why. | 11:00 |
| TheMue | niemeyer: yes, i think especially in fwereade_s queue are several usages | 11:01 |
| niemeyer | Aram: Yeah, bson.D is handled specially internally | 11:01 |
| Aram | interesting. | 11:01 |
| niemeyer | Aram: I guess we could make it check for the element type instead | 11:01 |
| niemeyer | Aram: Will have a look as I'm preparing an update | 11:01 |
| niemeyer | (mainly to get a few details of txn polished) | 11:02 |
| fwereade_ | TheMue, offhand, the watchers I do/will need for the UA are: Service.WatchRelations; Service.WatchCharm; Unit.WatchResolved; Unit.WatchLife; RelationUnit.Watch | 11:18 |
| fwereade_ | Aram, ^^ | 11:18 |
| TheMue | fwereade_: hehe, thx, just scanning your proposals | 11:18 |
| fwereade_ | TheMue, Aram: of those, only the last one should be tricky | 11:19 |
| Aram | fwereade_: thank you kind sir | 11:19 |
| Aram | yep | 11:19 |
| fwereade_ | TheMue, Aram: if I find I've forgotten one I'll let you know ;) | 11:19 |
| TheMue | fwereade_: great, thx again | 11:19 |
| TheMue | Aram: I'll add it to the file | 11:20 |
| * fwereade_ sighs with relief -- the Uniter has been massaged into a new shape, which passes (near-enough-exactly) the original tests :) | 11:31 | |
| fwereade_ | (excluding actual upgrades, not everything in place there yet, but I feel vindicated all the same :)) | 11:32 |
| * niemeyer sighs with fwereade_ | 11:32 | |
| fwereade_ | niemeyer, ok, I has a plan | 11:32 |
| fwereade_ | niemeyer, I want a damn uniter, so I intend to crudely hack out everything charm-related that I don't need, just to do a single dumb install without sufficiently smart recovery | 11:33 |
| fwereade_ | niemeyer, happily your suggestions made it a hell of a lot easier to do that, much easier to decouple charmy modes from hooky modes | 11:34 |
| niemeyer | fwereade_: +1! | 11:34 |
| niemeyer | fwereade_: Glad to hear the refactoring went well | 11:35 |
| fwereade_ | niemeyer, rough order, then: basic-uniter; charm-smart-upgrades; uniter-upgrade-charm; uniter-with-relations | 11:35 |
| fwereade_ | niemeyer, in which uuc depends on csu depends on bu; and uwr hopefully just depends on bu | 11:36 |
| TheMue | fwereade_: Found a NeedsUpgradeWatcher in uniter/modes.go, but not yet in trunk. is it in one of your proposals too? | 11:36 |
| fwereade_ | TheMue, I killed that the other day | 11:36 |
| fwereade_ | TheMue, replaced by Service.WatchCharm | 11:36 |
| TheMue | fwereade_: ah, fine, will kill it too ;) | 11:36 |
| fwereade_ | TheMue, cheers :) | 11:37 |
| niemeyer | fwereade_: Neat | 11:37 |
| fwereade_ | niemeyer, yeah, it did -- it took a depressingly long time to find something that didn't acively hurt to look at | 11:37 |
| fwereade_ | niemeyer, in fact, I'd better try to document the proposed charm.Manager (sorry :( ) API so you can point out all the ways it's crackful before I go too far ;) | 11:38 |
| niemeyer | fwereade_: I'd be happy to have a look | 11:40 |
| fwereade_ | niemeyer, actually, huh, it should obviously be charm.Directory :/ | 11:42 |
| niemeyer | fwereade_: I'm not sure.. we have charm.Dir already :) | 11:42 |
| fwereade_ | niemeyer, hmm :) | 11:42 |
| fwereade_ | niemeyer, I'll stick with manager for now, then, Directory isn't actually quite right because it needs to keep other stuff in a separate state dir | 11:43 |
| fwereade_ | niemeyer, http://paste.ubuntu.com/1162551/ | 12:18 |
| * fwereade_ tries not to look anxious | 12:18 | |
| niemeyer | fwereade_: Looks quite nice :-) | 12:19 |
| fwereade_ | niemeyer, cool :) | 12:20 |
| niemeyer | fwereade_: Slightly surprised to see state.Charm there, for some reason | 12:20 |
| fwereade_ | niemeyer, I *think* it's the right type to use in general; maybe crackfulness will become apparent when you see it used :) | 12:20 |
| niemeyer | fwereade_: func (*Manager) ReadStatus() (Status, *state.Charm, error) | 12:21 |
| niemeyer | fwereade_: How can the manager know the *state.Charm* in use? | 12:21 |
| fwereade_ | niemeyer, (man, it did take forever to figure out the right bits -- for a while I had a separate Operation type which really seemed like a good idea) | 12:21 |
| niemeyer | fwereade_: I'd expect it to know the URL instead | 12:21 |
| fwereade_ | niemeyer, it's passed a *state.State on create (whoops, forgot that bit) | 12:22 |
| fwereade_ | niemeyer, entirely so that it can give back a *state.Charm when asked | 12:22 |
| niemeyer | fwereade_: Yeah, I'm arguing that this is a bit awkward | 12:22 |
| niemeyer | fwereade_: It should really give back the URL, IMO | 12:22 |
| fwereade_ | niemeyer, I *think* it works out better like this than messing around creating them in the Uniter | 12:22 |
| niemeyer | fwereade_: I think it breaks down a level of encapsulation for little benefit | 12:23 |
| niemeyer | fwereade_: state.Charm(url) | 12:23 |
| fwereade_ | niemeyer, but, well, feedback like this is why I showed you -- thanks :) | 12:23 |
| niemeyer | fwereade_: That's all it takes | 12:23 |
| niemeyer | fwereade_: Thanks :) | 12:24 |
| fwereade_ | niemeyer, I was on the fence, and I think it saved a couple of lines of code, but you're right -- cleaner API > cleaner client code | 12:25 |
| fwereade_ | brb | 12:29 |
| TheMue | lunchtime | 12:55 |
| niemeyer | Aram: Curious | 12:58 |
| niemeyer | Aram: Turns out I was wrong | 12:58 |
| Aram | yes | 12:58 |
| niemeyer | Aram: bson.D isn't special | 12:59 |
| niemeyer | Aram: It's already looking at the element type it seems | 12:59 |
| Aram | so what's the issue? | 12:59 |
| Aram | hmm | 12:59 |
| niemeyer | Aram: Ah, hmm | 13:01 |
| niemeyer | Aram: No, I'm wrong again | 13:01 |
| niemeyer | Aram: It's used explicitly through different logic.. | 13:02 |
| Aram | ok. | 13:02 |
| Aram | niemeyer: this should work as an Assert in txn, right? | 13:04 |
| Aram | bson.D{{"$or", []bson.D{ | 13:04 |
| Aram | bson.D{{"needsupgrade", nil}}, | 13:04 |
| Aram | bson.D{{"needsupgrade", NeedsUpgrade{Upgrade: true, Force: force}}}, | 13:04 |
| Aram | }}, | 13:04 |
| Aram | } | 13:04 |
| Aram | just an $or query... | 13:05 |
| Aram | I have a mysterious issue here. | 13:05 |
| niemeyer | Aram: You're probably getting caught into the difference of non-existence vs. nil | 13:05 |
| niemeyer | Aram: That said, this stuff has changed in state in the past couple of days | 13:06 |
| niemeyer | Aram: It's a lot more friendly to mstate now | 13:06 |
| niemeyer | Aram: It's probably easier to migrate it | 13:06 |
| Aram | ok, I'll do that, but I'm still interested in the issue. | 13:06 |
| Aram | it fails if needsupgrade was already set to that value. | 13:07 |
| Aram | but why would it, the assertion should hold true in that case, right? | 13:07 |
| Aram | I have another $or assert like that, also one of the options is nil, and that works fine. | 13:08 |
| niemeyer | Aram: Yeah, it's worth understanding why that is happening before moving on | 13:15 |
| niemeyer | Aram: Ah | 13:15 |
| niemeyer | Aram: []bson.D isn't right | 13:15 |
| niemeyer | Aram: Is that even working? | 13:16 |
| niemeyer | Aram: I mean., compiling | 13:16 |
| Aram | sure. | 13:16 |
| Aram | all my $or queries are []bson.D | 13:16 |
| niemeyer | Aram: Hmm, sorry, I'm on crack.. it's right | 13:17 |
| niemeyer | Aram: What is the value like in the database?" | 13:17 |
| niemeyer | Aram: At the moment the assertion fails | 13:17 |
| Aram | NeedsUpgrade{Upgrade: true, Force: force} | 13:17 |
| Aram | exactly what the assertion says | 13:17 |
| Aram | I add it once in the begining, it matches nil and it puts it in the db, then I try to add it again which should also work | 13:18 |
| Aram | but I get txn.ErrAborted | 13:18 |
| niemeyer | Aram: Ah, hmm | 13:20 |
| niemeyer | Aram: I know what's wrong | 13:20 |
| niemeyer | Aram: Let me confirm it | 13:20 |
| niemeyer | Aram: Yeah | 13:21 |
| Aram | so what is? | 13:21 |
| niemeyer | Aram: txn is using "$or" too | 13:21 |
| niemeyer | Aram: I'll add a test and fix it | 13:21 |
| niemeyer | Aram: Thanks for persisting on it | 13:22 |
| Aram | so it's a txn bug? | 13:22 |
| Aram | heh. | 13:22 |
| Aram | great. | 13:22 |
| niemeyer | Aram: Yeah.. I was (ab)using $or internally to make it cheaper to build the query | 13:23 |
| niemeyer | Aram: I have to mix the queries instead | 13:24 |
| niemeyer | Aram: So it ended up like {"$or": [{"$or": ...}]} | 13:25 |
| hazmat | will juju-core use mongodb to distribute charm files instead of provider storage? | 13:30 |
| Aram | no. | 13:30 |
| Aram | (or at least not yet?) | 13:31 |
| niemeyer | Aram: Curious.. i can't reproduce it in a test | 13:34 |
| niemeyer | hazmat, Aram: It will, it doesn't yet | 13:34 |
| niemeyer | Aram: Ah, got it | 13:36 |
| niemeyer | Aram: I can't reproduce it | 13:45 |
| niemeyer | Aram: Can you please paste the snippet of code that is failing? | 13:45 |
| hazmat | niemeyer, with the move to that, the only use of provider storage will be the client map to api/db servers? or is the plan to ditch provider object storage entirely? | 13:46 |
| niemeyer | hazmat: We may be able to ditch it entirely, but that's a bit off still | 13:47 |
| niemeyer | Aram: It looks like the nesting actually works | 13:48 |
| Aram | niemeyer: I will try to produce a self contained example | 13:48 |
| niemeyer | Aram: Can you please just paste the snippet first? | 13:49 |
| Aram | sure | 13:49 |
| hazmat | niemeyer, cool, thats fine, i'm just talking future speak to an interested provider. | 13:49 |
| niemeyer | hazmat: I see, I do hope we're able to handle without the provider storage | 13:49 |
| niemeyer | Aram: I've addressed the custom []DocElem, btw | 13:50 |
| niemeyer | Aram: Will be out, probably as soon as we nail down why you're having trouble | 13:50 |
| Aram | niemeyer: http://paste.ubuntu.com/1162690/ | 13:53 |
| Aram | I've marked the failed assert | 13:53 |
| Aram | with THIS FAILS | 13:53 |
| niemeyer | Aram: Thanks | 13:56 |
| niemeyer | Aram: This test passes, btw: http://paste.ubuntu.com/1162673/ | 13:56 |
| Aram | niemeyer: wrote a self reproducing test | 13:57 |
| niemeyer | Aram: Oh, brilliant! | 13:57 |
| Aram | niemeyer: works with go run | 13:57 |
| Aram | http://paste.ubuntu.com/1162701/ | 13:57 |
| niemeyer | Aram: I'll try moving that onto a test case | 13:57 |
| niemeyer | Aram: Uh oh | 13:58 |
| niemeyer | Aram: This is bogus | 13:58 |
| Aram | niemeyer: wait, something is worng | 13:58 |
| niemeyer | Aram: Yeah | 13:58 |
| niemeyer | Aram: It's this bit: {{"a", nil}, {"a", "a"}} | 13:58 |
| niemeyer | Aram: This isn't a list of documents | 13:58 |
| niemeyer | Aram: It's a single document with two repeated fields | 13:59 |
| niemeyer | Aram: But that's not what you have in the real code | 13:59 |
| Aram | it isn't? | 13:59 |
| Aram | sel := bson.D{{"$or", []bson.D{ | 13:59 |
| Aram | bson.D{{"needsupgrade", nil}}, | 13:59 |
| Aram | bson.D{{"needsupgrade", nu}}, | 13:59 |
| Aram | }}, | 13:59 |
| Aram | } | 13:59 |
| Aram | that's the real code | 13:59 |
| niemeyer | Aram: Right.. that's not what the self-contained example has | 14:00 |
| niemeyer | Aram: The example is wrong, the real code is right | 14:00 |
| Aram | right | 14:01 |
| Aram | well, let me fix that | 14:01 |
| niemeyer | Aram: Btw, the THIS FAILS seems misplaced | 14:01 |
| niemeyer | Aram: It's pointing to a get rather than a set | 14:01 |
| niemeyer | Aram: Is the the set right above it the proper place? | 14:02 |
| Aram | niemeyer: yeah, sorry. | 14:02 |
| Aram | the set above | 14:02 |
| Aram | niemeyer: fixed my self contained example: http://paste.ubuntu.com/1162716/ | 14:06 |
| Aram | but I can't reproduce it either | 14:06 |
| Aram | it works there | 14:06 |
| Aram | and it's a good test, if I change "a" to b "b" in the assert, it fails the second change, which is correct. | 14:07 |
| Aram | so nothing wrong on the txn side. | 14:07 |
| niemeyer | Aram: and the only way to get ErrAborted is really for the assertion to fail | 14:10 |
| niemeyer | Aram: Nothing else returns it.. so it's a bit puzzling | 14:10 |
| Aram | yeah, what's difference between the self contained example and the real code... the assertion is the same. | 14:10 |
| Aram | the only difference is that one is a *string and one is a *T | 14:11 |
| niemeyer | Aram: Can you please enable mgo.SetDebug(true) right before executing the failing statement, so we can see what's running? | 14:11 |
| niemeyer | Aram: Ah, and mgo.SetLogger(c) | 14:11 |
| niemeyer | Aram: Hmmmmmm | 14:12 |
| niemeyer | Aram: Let me check something | 14:12 |
| Aram | niemeyer: debug log: http://paste.ubuntu.com/1162725/ | 14:13 |
| niemeyer | Aram: I bet it's the reordering of the fields | 14:13 |
| niemeyer | Aram: Yeaahhhh | 14:15 |
| Aram | interesting. | 14:16 |
| niemeyer | Aram: http://pastebin.ubuntu.com/1162730/ | 14:16 |
| Aram | hmm... | 14:17 |
| niemeyer | Aram: txn is using a map to inject some data in the inserted document (such as its id, revno, etc) | 14:17 |
| niemeyer | Aram: Will have to change it to a bson.D to avoid his | 14:17 |
| niemeyer | this | 14:17 |
| Aram | so it was a real bug, after all | 14:18 |
| niemeyer | Aram: Yep, can't reorder fields since people can trust on it | 14:22 |
| niemeyer | Aram: Thanks for the care on this, btw | 14:31 |
| Aram | welcme | 14:34 |
| fwereade_ | niemeyer, also, 3rd time's the charm... maybe... https://codereview.appspot.com/6482053 | 15:23 |
| fwereade_ | niemeyer, and on that bombshell, I am *exhausted*, and am going to knock off a little early today -- I'll almost certainly be back on later with my heart in my mouth ;) | 15:23 |
| fwereade_ | later all | 15:24 |
| Aram | cheers | 15:24 |
| fwereade_ | (and if anyone else is kinda lounging around, not sure what to do with themselves, please do take a look...) | 15:25 |
| fwereade_ | ;p | 15:25 |
| niemeyer | fwereade_: Get some good rest! | 15:29 |
| niemeyer | * installation (not really resumable, except by luck) | 15:42 |
| niemeyer | LOL | 15:42 |
| TheMue | Aram: you got the list of the test comparison, now i'll focus on adding the missing ones | 16:11 |
| niemeyer | Lunch | 16:13 |
| TheMue | niemeyer: enjoy | 16:15 |
| * niemeyer waves | 17:37 | |
| rogpeppe | i'm off now. struggling with test stuff all day, hopefully make more progress tomorrow. | 17:43 |
| rogpeppe | see yous tomorrow | 17:44 |
| niemeyer | rogpeppe: Have a good time | 17:55 |
| niemeyer | fwereade_: I hope the review on the first branch makes sense | 18:18 |
| niemeyer | Doc appointment.. back in 30-60mins | 19:11 |
| === fss_ is now known as fss | ||
| niemeyer | fwereade_: Uniter <3 | 21:24 |
| fwereade_ | niemeyer, w00t! | 21:53 |
| niemeyer | fwereade_: I was actually looking at the modes rather than the Uniter itself.. that stuff is superb | 21:54 |
| niemeyer | fwereade_: Can almost read it to a child :) | 21:55 |
| fwereade_ | niemeyer, I was hoping you'd like it :D | 21:55 |
| fwereade_ | niemeyer, it will get a touch heavier when we add the various other watches, but actually much less so than one might fear | 21:56 |
| niemeyer | fwereade_: Of course, but the mechanism itself is straightforward | 21:56 |
| niemeyer | fwereade_: Easy to navigate mentally between the states | 21:56 |
| fwereade_ | niemeyer, yep -- you remember I originally wanted to make them types? I though the setup would be significant enough to hurt, but actually it really isn't | 21:57 |
| fwereade_ | niemeyer, and yeah, just 2 more modes, upgrading and conflicted | 21:58 |
| fwereade_ | niemeyer, I have a sketch with a mildly interesting helper type for ModeStarted, but it doesn't become relevant until upgrades *and* relations are in play... and even then it's a touch marginal, will be interesting to see if it's worthwhile when I'm watching lifecycles as well | 22:00 |
| niemeyer | fwereade_: Yeah | 22:01 |
| fwereade_ | niemeyer, good comments on the preceding review, btw, I think I will refrain from addressing them until I'm a bit soberer ;) | 22:02 |
| niemeyer | fwereade_: LOL | 22:04 |
| niemeyer | fwereade_: Sounds like a plan :) | 22:04 |
| niemeyer | davechen1y: Heya | 23:17 |
| davechen1y | niemeyer: hey | 23:18 |
| niemeyer | davecheney: Regarding the env config | 23:43 |
| davecheney | yes | 23:43 |
| niemeyer | davecheney: I think what you did is sane, and I was thinking of something that is not an issue.. | 23:43 |
| davecheney | ok, phew | 23:43 |
| niemeyer | davecheney: My main concern is that we shouldn't have in state something that is an invalid environ.Config | 23:43 |
| niemeyer | erm | 23:43 |
| niemeyer | environs/config.Config | 23:44 |
| davecheney | niemeyer: right, i don't think that is a problem with this proposal | 23:44 |
| niemeyer | davecheney: Otherwise the whole thing will break down when we try to make state.EnvironConfig() return a first class type | 23:44 |
| niemeyer | davecheney: yeah.. the fields being removed are fine | 23:44 |
| niemeyer | davecheney: They're specific to the environ | 23:44 |
| davecheney | yup | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!