[00:08] thumper -- sorry about that! oops.... sigh [00:09] I'd cherry-picked the PR content it's waiting on in order to put the work through. let's see here... [00:11] apologies for wasting your time with that [00:15] there we go [00:15] https://github.com/juju/juju/pull/163 [00:36] wallyworld, the job failed even after I cleaned up the environment. Here are the logs http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/1434/ [00:36] sinzui: sec, talking to alexisb , will contact you soon [00:37] wallyworld: do you know where I can get the instance type information I need for the client API? [00:45] wwitzel3: yeah, sorry, i read your email and haven't had a chance to respond yet - been in meetings all morning. there is an api there, i just have to lookit and and let you know. will do so soon [00:47] wallyworld: np, thanks. [00:51] sinzui: i can see the state server workers all start up, and also mongo. there appears to be no reason why the api client cannot connect to port 17070 - is it possible to do a netstat to see if the state server is indeed listening on the correct port? [00:55] wallyworld, This is what I saw during the upgrade http://pastebin.ubuntu.com/7703456/ [00:56] wallyworld, WTF, this just happened on the next test [00:56] http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/1435/console [00:56] sinzui: is that done after these lines [00:56] 2014-06-26 00:13:38 INFO juju.mongo open.go:90 dialled mongo successfully [00:56] 2014-06-26 00:13:38 DEBUG juju.state open.go:58 connection established [00:56] * wallyworld looks at new console [00:57] seriously? it is mocing us [00:57] mocing [00:57] wallyworld, it is a pass with a panic...that is a first [00:57] mocking [00:58] sinzui: i think that's due to the agent shutting down for upgrade, just caught it at a bad time [00:58] wallyworld, status may have panicked, it is called several times. the last call gave a result showing all machines upgrades [00:59] wallyworld, could be...but the code i wrote tries to capture that...that is why status will be called several times [01:00] sinzui: i can see why status is behaving that way and there was a recent change there - it think it's missing a sanity check [01:01] we can get back an error from the call to get status and still have partial status to display [01:01] but we should check that we do indeed have some status and not nil [01:01] so it will be a simple fix if i am correct [01:02] sinzui: but i wonder why the CI ob failed the first time, there's no obvious reason [01:03] wallyworld, I am unsure what to do now. If I wasn't watching that happen, I would declare the test good and just focus on the ill azure [01:03] sinzui: 2 out of 3? :-D [01:03] wallyworld, exactly [01:03] let's run it again [01:04] azure and joyent are messed up. I am in the consoles killing machines [01:04] menn0: hi ya, i think there's an issue with the recent changes to status. i think we are missing a nil check. see http://pastebin.ubuntu.com/7703483/ [01:05] do you agree? [01:06] yep. davecheney has already fixed it [01:06] https://github.com/juju/juju/pull/127 [01:06] wallyworld: it looks like the landing bot didn't pick up the merge request though. [01:07] wallyworld: how do we make it notice the PR? [01:07] um [01:07] $$merge$$ should have been enough [01:07] i'll look into it [01:07] It could be because this was a PR where the merge started and then was aborted because the initial proposal wasn't quite right [01:07] wallyworld: ^^ [01:08] ah [01:08] wallyworld: I think you were the one who killed it in Jenkins (at dave and my request) [01:08] menn0: yes. but after that it needs $$merge$$ again to re-trigger [01:09] i'll do that [01:09] well it's had that [01:09] but try again I guess [01:09] wallyworld, (Sorry for this awkward question from my daughter), Are all 40-50 year-old Aussies obsessed with ABBA. [01:09] I said no, but she doesn't believe me [01:09] rotfl [01:09] only some of us :-) [01:09] abba were very, very popular here [01:10] who isn't obsessed with ABBA? am I right? [01:10] I know. I told her about how many weeks Fernando and Dancing Queen spent at number one and she then decided there is a cohort who can't let the band go [01:14] she is right [01:14] but i am not one of them :-) [01:15] wwitzel3: i sent you an email - there's a little refactoring required, sorry [01:16] wallyworld: ok, yeah, I saw that .. I think I can just add that to the interface in common provider? But I am still not sure how to actually get the provider to call the method on. [01:17] wwitzel3: you have it in your method [01:17] func (api *EnvironmentAPI) getInstanceTypes(env environs.Environ) [01:17] env is the provider [01:17] so you add the method to Environ [01:18] wallyworld: lol [01:18] wallyworld: of course it is [01:18] the ConstrainstValidator() method is already there [01:18] :-) [01:18] I was sooo close [01:18] yep :-) [01:18] wallyworld: thanks :) [01:18] np [01:19] menn0: i have no idea what's wrong, i'm just going to merge it directly [01:19] wallyworld: ok thanks [01:20] sinzui: i just merged in a fix for that status panic [01:21] :) [01:21] sinzui: it was proposed a few days ago it seems but the bot just didn't want to pick it up [01:46] review requested: https://github.com/juju/juju/pull/164 ; this just updates for the newly updated names package and makes the internal structure of the Action consistent with other state structures. [02:01] wallyworld: with you shortly [02:01] ok [02:28] thumper: I'm thinking of picking up this bug: https://github.com/juju/juju/issues/138 [02:29] thumper: I see there are two ssh clients: openssh and gocrypto embedded. Does the gocrypto save known_hosts? [02:29] waigani: first thing, can you move that bug to launchpad? [02:29] thumper: sure [02:32] thumper: https://bugs.launchpad.net/juju-core/+bug/1334481 [02:32] <_mup_> Bug #1334481: juju should not record ssh certificates of ephemeral hosts [02:32] waigani: can you also link that on github too? for the issue [02:33] thumper: done [02:33] added comment [02:34] thumper: shall I do the same for this one: https://github.com/juju/juju/issues/133 [02:34] waigani: check to see if it has been done already, but yes [02:34] though there has already been some discussion on github [02:34] ok [02:37] thumper: done, and linked on github [02:37] waigani: yes, working on that issue would be good [02:38] thumper: cool. I'll start with a failing test. So we will just not store the known hosts at all on ssh right? [02:40] waigani: yeah... but just for juju ssh [02:41] thumper: cmd/juju/ssh ? [02:41] yup [02:49] axw: got time for a quick hangout? [02:50] wallyworld: can you give me 5 mins please? [02:50] sure [02:54] wallyworld: I'm in the tanzanite-daily hangout [02:55] thumper: fwiw, on PR 163, a lot of the tag/id stuff has been clarified with that last names package update I submitted [02:55] heh... [02:55] I'm just commenting on what I see [02:55] :) [02:56] thumper: bodie_ told me this morning that he expected to have to do some refactoring once my change was in [02:56] thumper: :) [02:56] * jcw4 is just nervous about when thumper's beady eye gets on my PR next [02:57] jcw4: which PR is it you want me to look at? [02:57] 164 [02:57] or not... y'know [02:57] if you need a nap or something... [02:57] thumper, cleaned up 163, btw -- it looks like you're commenting on the content I removed :( [02:57] all jokes aside, I'm *loving* the code review process on this project [02:58] it's still useful -- the code you're commenting on is for PR 140 and 141, so I can still make use of it [02:59] bodie_: hmm... ok, what should I be looking at? [02:59] https://github.com/binary132/juju/commit/1de2d29aba97a422da32fcfde1a15c94e150e1ad [03:00] bodie_: is that because your PR 163 was rebased on top of your pending 140 and 141 ? [03:00] bodie_, jcw4: something to be aware of, with the upcoming work on multi-environment state servers, all the document _id fields will change to include the env uuid [03:00] yes, I removed the condensed commit and pushed --force so I thought it would be clear it was gone from the PR [03:01] but, the rebased commit was just the same content from 140 and 141, so I could run tests [03:02] thumper: so if we hide that _id behind the public api of the state types we should be fine right? [03:02] generally... [03:02] wallyworld: :P how many bundles have you created by hand? [03:03] rick_h_: none [03:03] but it sure would be nice to have a cli for it [03:03] wallyworld: sure, from an existing environment as a dump/backup. [03:04] eg juju start bundle followed by a series of deploy, relate commands, then juju end bundle [03:04] wallyworld: but anyway, replied. rubbing some ointment over the gui comment sting :P [03:04] wallyworld: it's called a shell script, you can do that today [03:05] rick_h_: sorry if it came out bad, wasn't intended [03:05] wallyworld: I'm joking with you [03:05] i just wanted to make the point that most of our target audience don't use guis [03:05] wallyworld: except I don't think bundle creation is a cli/scriptable thing [03:05] wallyworld: do we have a target audience now? [03:05] devop people? [03:06] i guess windows folks want a gui [03:06] because if we're going to talk small devs I'll argue with you [03:06] i'm a small dev [03:06] i don't use guis [03:06] but yes, at scale people want scriptable > * (*cough* thumper *cough*) [03:06] yup [03:06] wallyworld: never confuse you vs a target audience. [03:07] I use vim and a terminal all day and the only gui app I run is a browser [03:07] rick_h_: I'm going to make you happy and make it all script happy [03:07] rick_h_: leave it with me :) [03:07] thumper: :) hey wallyworld is preaching it too [03:07] rick_h_: I've already cleared the approach with fwereade [03:07] woot [03:07] * rick_h_ does happy dance [03:07] thumper: you have a doc to share on that? [03:08] waigani: nope, it is inside my head, but not complex [03:08] wallyworld: thumper and I were having this conversation yesterday so glad to see your chime in as well. [03:08] thumper: must be simple to be in your head [03:08] wallyworld: it is [03:08] ouch [03:08] maybe there's a GUI in it [03:09] lol [03:09] har har! [03:09] you funny [03:09] I try, it's past my bedtime [03:09] careful, you'll turn into a pumpin [03:09] k [03:09] half way there, let me get an orange shirt [03:11] ll [03:11] o [03:11] and a green hat [03:12] and a camera [03:24] * thumper takes a deep breath and moves to the next PR [03:27] * bodie_ hands thumper a bottle of water and cheers him on [03:37] thumper, wallyworld. A recent rev broke the win installer. We cannot compile it https://bugs.launchpad.net/juju-core/+bug/1334493 [03:37] <_mup_> Bug #1334493: Cannot compile win client

[03:42] * sinzui forces build a a revision before the win and os revisions [03:45] bodie_, jcw4: some comments on PR 164 [03:45] thumper: right behind you [03:45] particularly the last one, as that is the biggest question I have [03:46] I'll comment on the pr thumper, but this goes back to that watcher point [03:47] if we have a watcher on the actions collection [03:47] and that watcher gets _id's for *free* [03:47] we can filter on those _id's without another db hit [03:48] sure, but that doesn't answer the question [03:48] thumper: because there could be multiple actions with the same name [03:48] jcw4: a key question is: "Is the combination of unit and action name unique?" [03:48] thumper: no [03:48] why? [03:48] what is the differentiating point that makes actions here special? [03:49] how does a user differentiate? [03:49] if I say "run the backup action" it may mean multple things? [03:49] if so, why? [03:49] or is this "an instance of someone running the backup action" ? [03:50] thumper: every time a user types 'juju do ' an Action get's queued on the actions collection using the assigned unit and name [03:50] thumper: I may say the same command twice [03:50] thumper: intending it to run twice [03:50] ok... [03:50] how come an action doesn't have a user? [03:51] or a date requested? [03:51] I think an action should have a timestamp that it was created [03:51] and who requested it [03:51] thumper: my very first PR for this document had unitName, timestamp, (no user), etc. [03:51] heh [03:52] in discussion w/fwereade we eliminated the unitName because it would be encoded in the _id [03:52] sinzui: looking [03:52] the timestamp was deemed unnecessary for now [03:52] thumper: the intent is for us to basically have a super lightweight 'tracer' implementation [03:52] * thumper coughs [03:53] thumper: and then fill in the details later [03:53] * thumper looks shiftily at fwereade's shadow [03:53] * jcw4 feels guilty for throwing fwereade under the bus [03:53] jcw4: what is the lifetime of an action? [03:53] fwiw, I think fwereade's case was sound [03:53] when do we remove it? [03:53] thumper: as long as it takes for the unit to execute it. [03:54] probably minutes or seconds [03:54] usually [03:54] so we end up with an action result? [03:54] how long do they live? [03:54] forever [03:54] and ever [03:54] ouch... [03:54] * thumper forsees an issue [03:55] we obviously have different definitions of lightweight [03:55] to me remembering who asked and when is part of very lightweight [03:55] to be fair, we haven't discussed any archiving of the results yet [03:55] when you record the result, you then have a timestamp for finish and can then deduce a duration [03:55] jcw4: but results could be big right? [03:55] thumper: indeed [03:55] jcw4: or do they point to locations on file? [03:56] not in the current implementation [03:56] well... they could... [03:56] thumper: yep... tbh we hadn't thought that far ahead yet [03:56] (we being me) [03:56] given that we want to back up the db periodically [03:56] and I don't want all my postgresql database backups stored in mongo [03:57] * davecheney shreeks [03:57] sorry davecheney, bad moment to listen [03:57] i've been listening for a wihle [03:57] i just couldn't stand it any longer :) [03:57] haha [03:57] http://paste.ubuntu.com/7703965/ [03:57] still one more race in the state/apiserver package [03:57] i'm on it [03:58] ta [03:58] thumper, davecheney to be fair we don't have *any* actions actually runnable yet, so the danger isn't there until we do :) [03:59] jcw4: anything that ends with 'my backups are stored in mongodb' is horrifying [03:59] jcw4: so you are just going to hand us a hand grenade and say "here you go, juggle" [03:59] * thumper chuckles [03:59] * jcw4 wonders how to respond to that [03:59] heh [03:59] well.... [03:59] :) [03:59] jcw4: we'll need a way for a user to say "please discard the results for this action now" [03:59] when the only tool you have is mongodb, everything looks like /dev/null [04:00] davecheney: mongo is web scale [04:00] thumper: so's /dev/null [04:00] :) [04:00] exactly [04:00] axw: wallyworld is there a race build in jenkins ? [04:00] um [04:00] thumper: so... we're trying to build/define actions here as we go [04:00] no [04:00] jcw4: that's going to end in tears [04:01] haha [04:01] we are considering it [04:01] hmm... [04:01] possible race from sabdfl, possible sadness from your team [04:01] wallyworld: i'll add it to the weekly meeting notes as a discussion point [04:01] sure [04:01] wallyworld: do you know the status of the release / upgrade ? [04:01] i was watching a bunch of reverts overnight [04:01] that then got reverted [04:01] jcw4: so... one question [04:02] davecheney: reverts were red herring, i think a few conclusions were jumped to [04:02] * thumper tries to formulate... [04:02] davecheney: someone broke the windows build, i'm fixing that now [04:02] wallyworld, the build of the older revision, the one that only reverts daves rev [04:02] wallyworld: i think it was a good hunch [04:03] thumper, davecheney we've purposefully not exposed cli usage yet so that there's minimal exposure until we're done. [04:03] jcw4: ack [04:03] wallyworld, This the the first time I have specifically tested a rev to get a pass [04:03] jcw4: IMO, and fwereade may disagree, the id for any document should be composable from attributes in that document [04:03] sinzui: you talking about the local upgrade? [04:04] jcw4: so we don't need to parse the id to get attributes [04:04] jcw4: expecially if parts of said id are used in other places [04:04] such as the tag [04:04] wallyworld, yes, but since dave's rev was immediately restored, CI never tested just the revision we wanted [04:04] going from a set of attributes to an ID is easier than trying to do the reverse [04:04] wallyworld, the rev could be restore until CI had built juju without it [04:04] thumper: that makes sense; it feels a little redundant, but makes sense to me [04:04] and the amount of data we are storing is minimal [04:04] thumper: +100 [04:05] seriously, minimal [04:05] sinzui: oh, so that one *may* have broken upgrades? i thought we just got a passing CI test? [04:05] https://bugs.launchpad.net/juju-core/+bug/1334500 [04:05] <_mup_> Bug #1334500: state/apiserver: more data races

[04:05] thumper: https://github.com/juju/juju/pull/165 fixes a release blocker sinzui found [04:05] thumper, davecheney what we need is some way to incrementally build / design what we're doing, and get active feedback (like this), without a fully specified feature doc [04:05] i'll throw this back in the pool if I can't fix this by EOD [04:05] wallyworld, I think we got lucky. the test passed, yet there is a panic in it [04:05] davecheney: ack [04:05] wallyworld: looking [04:05] jcw4: yes, if you don't have that, success will be hard [04:06] sinzui: the panic was just in a juju cmd [04:06] If this rev I am testing passes I will release it. that is all I want a rev that passes that developers don't also say has a hidden bug [04:06] wallyworld: lgtm [04:06] it's fixed now but would have had little impact [04:06] thumper: thanks [04:06] thumper: i'm just going to hit merge directly so sinzui can rerun the windows build [04:07] davecheney, thumper I know you're in the middle of a couple other issues here; but we're also in somewhat of a tight spot because sabdfl is anxious for a version of actions that works end to end (even if it's very minimal) [04:07] wallyworld, I cannot [04:07] I am testing a previous rev [04:07] jcw4: ok... please can we start by updating the state doc so the id is composed from other attributes? [04:07] ah ok [04:07] thumper: +1 [04:07] CI gets nasty if I try to make it do change what is being test [04:07] jcw4: and if you don't decide to add a timestamp and user, add a note that says thumper wants it there [04:08] thumper: absolutely, and I'll add jcw4 too [04:08] \o/ [04:08] thumper: I'll also add a note to ActionResults about the long term risk of not managing old results [04:09] jcw4: I think that removing old action results must be part of the initial release [04:09] otherwise crazy ensues [04:09] thumper: agreed [04:10] probably something as easy as "juju action rm " [04:10] jcw4: so... actions are defined in the charm metadata, yes? [04:11] thumper: yes [04:11] jcw4: do we do validation somewhere on action names being requested [04:11] jcw4: is there a command to list action results? [04:11] thumper: yes, and will be [04:11] jcw4: we are going to have to have user there... ASAP [04:11] jcw4: because I will most of the time only be interested in seeing the actions I asked for [04:11] jcw4: but I should be able to see all [04:11] thumper: interesting [04:12] (assuming I have permissions) [04:12] thumper: makes sense [04:12] jcw4: as an aside, we will probably have permissions fine graned enough to say who can do what actions on which service [04:12] thumper: were you involved in the draft spec of Actions ? [04:12] * thumper handwaves [04:12] jcw4: not really, I think that was mostly sabdfl [04:13] jcw4: although I have spend most of the last two weeks just writing specs [04:13] * thumper sighs [04:13] :( [04:13] https://docs.google.com/document/d/14W1-QqB1pXZxyZW5QzFFoDwxxeQXBUzgj8IUkLId6cc/edit#heading=h.q6wtcjv2r9h [04:13] thumper: I think I want to capture a lot of your suggestions there [04:14] heh [04:14] jcw4: looks like the doc suggests a uuid for an action [04:14] yep [04:15] I don't recall if we explicitly discarded that idea or if it just slipped by us when we started worrying about filtering the events on the watcher [04:16] jcw4: also notice that the spec shows that the action records when it was invoked [04:16] that looks like a timestamp to me [04:17] * jcw4 blushes [04:17] not for the first time tonight [04:17] hmm... [04:17] I do think that the design has gotten a little overcomplicated, in that we only need one action doc, not two [04:17] two? [04:17] we should have the action results stored with the action [04:18] I see [04:18] I don't think we need an ActionResult doc [04:18] the result belongs to an action [04:18] this way you don't need to copy fields across [04:18] consider this: [04:18] $ juju status action:UUID [04:18] in the spec, there are two options: [04:19] running, or failed [04:19] this indicates to me that we are looking in one place to see the information [04:19] which means a simple database query [04:19] to get the action whether it is running or done [04:19] * thumper takes a deep breath [04:20] I feel a real design review coming along [04:20] how much time do you have? [04:20] thumper: yes that makes sense... believe it or not, we started there and currents and eddies along the way pushed us to the two docs we have now [04:20] I *want* to go for hours [04:20] * thumper smiles [04:20] I *should* have been off hours ago [04:20] :) [04:21] * thumper looks in trunk [04:21] hmm... [04:22] * thumper goes back to the spec [04:24] jcw4: ok where should I dump my thoughts? [04:25] jcw4: I don't want to put them in the spec [04:25] How about an email to the list? [04:25] jcw4: do you have a design spec? [04:25] um... yeah... ok [04:25] more potential for bikeshedding [04:25] I almost emailed the list a couple days ago, but didn't [04:25] but ok [04:25] thumper: that's true [04:25] lets try it :) [04:25] we started a couple spec docs, but nothing worth sharing [04:26] Maybe you might craft a new doc and link to it from an email? [04:26] one may fall out of the conversation [04:26] thumper: ack [04:26] <--- did you notice that? [04:26] ;) [04:27] learning new catch phrases as I go [04:31] jcw4: nice [04:38] davecheney: i'm not sure the data races are critical blockers for the 1.19.4 release - so long as CI is happy, we can fix them post release [04:39] wallyworld: sure thing [04:39] you're the judge [04:39] but if you can fix quickly.... [04:39] i'm fixing it anyway [04:39] but please lets not block this release any futher [04:39] great, may be able to sneak it in :-) [04:39] yup [04:39] that was the thinking [04:39] i'll take off the 1.19.4 milestone [04:42] sinzui: so what's the verdict with the release at the moment? [04:43] If I must release, I can use a8f48d14 which is before the 1.18.x upgrade fix [04:44] The revision under test has that fix, is before the win build broke, and might be without the local precise upgrade problem [04:46]