| jimbaker | SpamapS, i'm putting bug 963640 back into progress since i didn't intend for it to get committed to trunk | 01:40 |
|---|---|---|
| jimbaker | in terms of the corresponding branch | 01:40 |
| jimbaker | (see my lbox mishap earlier) | 01:40 |
| fwereade_ | well, I just deployed wordpress/mysql on an i386 c1.medium, and a cc1.4xlarge in another zone, and apparently it all works despite the violence of the last few days | 02:47 |
| * fwereade_ sleeps | 02:47 | |
| hazmat | fwereade_, next step world domination | 02:57 |
| hazmat | ;-) | 02:57 |
| hazmat | niemeyer, wtf seems hung | 02:59 |
| andrewsmedina | exit | 04:34 |
| SpamapS | jimbaker: ACK, understood | 05:20 |
| wrtp | TheMue: yo! | 07:32 |
| TheMue | wrtp: moin from a sunny oldenburg | 07:32 |
| wrtp | TheMue: sunny here too. | 07:32 |
| === TheMue_ is now known as TheMue | ||
| fwereade_ | bigjools, ping | 09:32 |
| fwereade_ | bigjools, there's a review on https://code.launchpad.net/~julian-edwards/juju/name-constraints/+merge/99673 which I've tried to make helpful but I'm not 100% sure I've managed | 09:34 |
| fwereade_ | bigjools, please let me know your thoughts when you get a change to read it | 09:35 |
| TheMue | wrtp: when i let update() return an error instead of the bool, what shall i return in case of the internal tomb.Dying during a change sending? | 09:36 |
| TheMue | fwereade_: moin | 09:36 |
| fwereade_ | heya TheMue, wrtp | 09:36 |
| wrtp | fwereade_: yo! | 09:36 |
| wrtp | TheMue: nil, nil | 09:36 |
| TheMue | wrtp: when err is nil the loop continues work. the dying event has been fetched by update() | 09:37 |
| wrtp | TheMue: you could check the returned channel instead of the returned error | 09:38 |
| wrtp | TheMue: if the returned channel is nil, there are obviously no more events to wait for | 09:38 |
| TheMue | wrtp: but i check the error to to do a Kill(err). so i would have to do a double-if | 09:46 |
| wrtp | TheMue: you can call Kill(err) regardless | 09:46 |
| wrtp | TheMue: it doesn't matter if it's already dying | 09:47 |
| wrtp | TheMue: or if err is nil | 09:47 |
| TheMue | wrtp: to be more clear: i'm decorating it with Killf("watcher: can't update: %v", err) | 09:48 |
| TheMue | wrtp: here a nil isn't looking very good | 09:48 |
| wrtp | TheMue: a nil is what you need i think | 09:48 |
| wrtp | TheMue: you don't want the watcher to return an error just because the user has called Stop on it | 09:48 |
| TheMue | wrtp: or does tomb ignore this last misleading information? | 09:49 |
| wrtp | TheMue: if you do Kill(nil), it uses the previous non-nil error | 09:49 |
| wrtp | TheMue: i don't think there's a need to use Killf - update() can return the correct error itself. | 09:49 |
| TheMue | wrtp: but how about decorated errors like netioned above? | 09:50 |
| wrtp | TheMue: as i said, i don't think there's a need to decorate the error here. | 09:50 |
| TheMue | wrtp: ok | 09:51 |
| === asavu_ is now known as asavu | ||
| wrtp | TheMue: cunning - was it intentional that you read from Dying twice, and leverage the fact that a nil channel always blocks? | 11:54 |
| wrtp | TheMue: i still think it would probably be better just to check the channel returned from update rather than the error though | 11:54 |
| TheMue | wrtp: can't follow, what exactly you mean? | 11:59 |
| wrtp | TheMue: i'll comment in line - it's easier for context :-) | 11:59 |
| TheMue | wrtp: it's almost exactly like http://paste.ubuntu.com/903511/ | 12:01 |
| wrtp | TheMue: review delivered. it's nearly there, i think! | 12:11 |
| TheMue | wrtp: thx, did you red gustavos comments? he said the constructor func doesn't need a comment. https://codereview.appspot.com/5905064/diff/13001/state/watcher/watcher.go#newcode89 | 12:15 |
| wrtp | TheMue: i can see why he said that comment could be dropped - it had no information content. i think it's worth documenting the path arguments. but i don't mind too much if the comment isn't there either. | 12:16 |
| TheMue | wrtp: most of the comments are ok, will change it, but not all. | 12:21 |
| TheMue | wrtp: and i will comment the constructor again, yes. i'm used to document every public artefact. you're right. | 12:25 |
| wrtp | TheMue: i think the general rule is: if a comment is adding no information, it's not worth having. | 12:25 |
| TheMue | wrtp: hmm, in case of your review, where is the additional information? | 12:26 |
| wrtp | TheMue: it says that path represents the path of the node to be watched. | 12:27 |
| wrtp | TheMue: ok, it's fairly obvious, but it's nice to say that explicitly. | 12:27 |
| TheMue | wrtp: so a renaming it to watchedPath would do the same? | 12:27 |
| wrtp | TheMue: perhaps. nicer to have it in the comment though, IMHO | 12:28 |
| TheMue | wrtp: i'm torn. so the next review of niemeyer will say to remove it again. | 12:29 |
| wrtp | TheMue: yeah, well, as i said, i don't mind too much if you remove it. | 12:29 |
| wrtp | TheMue: though i don't think gustavo will object to the comment as i've written it. | 12:30 |
| TheMue | wrtp: he will, zookeeper isn't written ZooKeeper. *lol* | 12:31 |
| wrtp | TheMue: lol | 12:31 |
| wrtp | TheMue: i really don't think it's worth doing those sorts. | 12:45 |
| wrtp | TheMue: i don't see the point. | 12:45 |
| TheMue | wrtp: they are ok for me and niemeyer | 12:46 |
| wrtp | TheMue: but why bother? | 12:46 |
| TheMue | wrtp: if you convince him i can remove them | 12:46 |
| wrtp | TheMue: i'm sure that he wouldn't mind if you removed them... | 12:46 |
| wrtp | TheMue: when would we actually care about the order of the names in Added and Deleted? | 12:47 |
| TheMue | wrtp: what problem do you exactly have with it? | 12:47 |
| wrtp | TheMue: it's unnecessary | 12:47 |
| wrtp | TheMue: it's also undocumented BTW | 12:49 |
| wrtp | TheMue: but i don't think it's worth documenting - i'd just remove the sorts. | 12:49 |
| TheMue | wrtp: you can do so if it gets into the branch | 12:50 |
| wrtp | TheMue: i wouldn't gratuitously change your code :-) | 12:50 |
| TheMue | wrtp: in topology and ConfigNode we also sort several slice results (after a discussion about it) | 12:50 |
| TheMue | wrtp: it's not my code, it's open source ;) | 12:51 |
| wrtp | TheMue: deltas are different. | 12:51 |
| TheMue | wrtp: and also you try to change it now (as i should change it) | 12:51 |
| wrtp | TheMue: there's no advantage in having the delta sorted. if it was the entire set of children, that would be different. | 12:51 |
| wrtp | TheMue: i try to convince you that it's for the best :-) | 12:51 |
| TheMue | wrtp: so i deliver all children in future and the client shall decide it needs as deltas or sorted. for the children watcher deltas aren't interesting, only the fact that it's changes. | 12:52 |
| TheMue | wrtp: same argumentation | 12:52 |
| wrtp | TheMue: if you change it to deliver all children in the future, they should be sorted (so it's easy to compare for equality etc). | 12:54 |
| wrtp | TheMue: "for the children watcher deltas aren't interesting, only the fact that it's changes." - i don't understand this | 12:54 |
| wrtp | TheMue: (or the sentence before it, actually) | 12:54 |
| TheMue | wrtp: it is about where the border between the watchers tasks and a clients tasks is. you say, a sorting can be done by the client, building a delta is task of the watcher | 12:56 |
| wrtp | TheMue: i don't we'll have any client that will want to sort it. | 12:56 |
| TheMue | wrtp: so i could also say "the watcher don't even builds deltas" | 12:56 |
| wrtp | s/don't/don't think/ | 12:56 |
| wrtp | TheMue: why would a client *want* to sort it? | 12:56 |
| wrtp | TheMue: why might it matter what order the child names in the delta are in? | 12:57 |
| wrtp | TheMue: i don't think it does - just like it doesn't matter what order you iterate through items in a map. | 12:58 |
| TheMue | wrtp: easier comparison when iterating over them. you can break loops an expected dir isnt in the delta | 12:58 |
| TheMue | if actDir > expectedDir { break } | 12:59 |
| wrtp | TheMue: are you talking about using binary search? | 12:59 |
| TheMue | wrtp: inside a range | 12:59 |
| wrtp | TheMue: so the advantage is it might be able to do a break earlier rather than iterating through all items? | 13:00 |
| TheMue | wrtp: the the quickest one that came in my mind | 13:00 |
| wrtp | TheMue: i don't buy that. unless that's being done many many times, it's going to be cheaper to do a linear search than to sort the items. | 13:00 |
| wrtp | TheMue: and it's easier to understand (you don't need to know that the items are sorted) | 13:01 |
| TheMue | wrtp: how much directories do you expect in a change event? | 13:01 |
| wrtp | TheMue: probably almost always 1. | 13:01 |
| TheMue | wrtp: how much does it cost to sort 1 item? | 13:01 |
| wrtp | TheMue: why bother to import sort and call it? | 13:02 |
| wrtp | TheMue: it's premature optimisation | 13:02 |
| TheMue | wrtp: please, not that argument | 13:02 |
| wrtp | TheMue: the only argument you've given for sorting them is that it's more efficient to search, AFAICS | 13:03 |
| TheMue | wrtp: had it often enough during the last weeks and every time it tended to be optimized even if we don't yet know to to optimize | 13:03 |
| wrtp | TheMue: not that it makes any code easier to write. | 13:03 |
| TheMue | wrtp: search and comparison | 13:03 |
| wrtp | TheMue: it doesn't make it easier to search, just quicker. | 13:03 |
| wrtp | TheMue: and you're never going to be comparing deltas directly. | 13:04 |
| TheMue | wrtp: it seems we don't have anything to do. this discussion lasts longer as any future thinking about it or the added sorting time of deltas for all instances till 2015 | 13:05 |
| TheMue | wrtp: so i'll change it to see you happy and to stop this discussion | 13:06 |
| wrtp | TheMue: ach, just delete the code. deleting code is good, right? | 13:06 |
| wrtp | TheMue: thanks :-) | 13:06 |
| wrtp | TheMue: sorry for the hassle. | 13:06 |
| TheMue | wrtp: not if it has to added anywhere else (e.g. at least in tests, so same amount, but w/o reusage) | 13:07 |
| wrtp | TheMue: it's a strict gain inside the watcher package AFAICS. we'll see if it has to be added anywhere else. i'm pretty sure it won't. | 13:08 |
| wrtp | TheMue: you don't need to sort in the tests BTW. | 13:08 |
| wrtp | TheMue: because you've always got a single item. | 13:08 |
| TheMue | wrtp: sadly not yet, yes. we need to find a way to simulate the addition of multiple children at once | 13:09 |
| andrewsmedina | morning | 13:09 |
| wrtp | andrewsmedina: hiya | 13:09 |
| TheMue | andrewsmedina: moin | 13:11 |
| fwereade_ | allenap, ping | 13:24 |
| allenap | fwereade_: Hi. | 13:24 |
| fwereade_ | allenap, do you know whether maas currently allows for machine selection by arch? | 13:25 |
| allenap | fwereade_: It doesn't. We record the arch in maas, and push it through to Cobbler, but it's only to select the arch to install; we don't capture the arch of the actual machine yet. | 13:26 |
| fwereade_ | allenap, cool, then I don't have to worry about that :) | 13:26 |
| allenap | fwereade_: :) | 13:26 |
| fwereade_ | allenap, how about requesting a machine with a particular series of ubuntu? | 13:26 |
| allenap | fwereade_: MAAS manages the install, so any machine can - in theory - come with any series. However, for 12.04, you can have any series as long as it's Precise. | 13:27 |
| fwereade_ | allenap, ok, cool, I should probably enforce that in the code somewhere, we don't want confusion over "juju deploy cs:oneiric/foo" | 13:28 |
| allenap | fwereade_: Sounds good. At some point MAAS will support other series (by 12.10 at least...) so perhaps there ought to be a way to ask MAAS what the options are. | 13:30 |
| fwereade_ | allenap, there just might be indeed, I'm working on something related but that definitely won't hit by 12.04 | 13:32 |
| wrtp | lunch | 13:40 |
| niemeyer | Heya | 13:59 |
| niemeyer | Sorry guys, running a bit late here.. night lasted longer than usual | 13:59 |
| andrewsmedina | niemeyer: morning :) | 14:07 |
| niemeyer | andrewsmedina: Morning :) | 14:14 |
| wrtp | niemeyer: hiya | 14:14 |
| TheMue | niemeyer: moin ;) | 14:17 |
| hazmat | 28 people wait listed already for the go-lang meetup, good sign | 14:35 |
| niemeyer | hazmat: Nice, where's that? | 14:39 |
| hazmat | niemeyer, nyc | 14:39 |
| hazmat | http://www.meetup.com/golangny/ | 14:40 |
| niemeyer | Ah, is that the one at Tumblr? | 14:41 |
| mthaddon | niemeyer: one question pending for the charmstore RT (about nagios checks) and then also wanted to check if I should be setting up charmload to run every minute on both appservers | 14:45 |
| niemeyer | mthaddon: Yeah, that sounds fine.. it should return within a second or two if there's nothing to do | 14:48 |
| niemeyer | mthaddon: I've seen your inquiry as well.. will investigate | 14:48 |
| hazmat | fwereade_, what's the visible flag on constraints for? | 14:48 |
| mthaddon | niemeyer: great, thx | 14:48 |
| hazmat | fwereade_, in use-constraints-sets | 14:48 |
| fwereade_ | hazmat, computed constraints -- ubuntu-series comes from the charm, provider-type from the provider | 14:48 |
| fwereade_ | hazmat, provider-type *may* in fact be unnecessary now | 14:49 |
| fwereade_ | hazmat, but that's not a change I'm comfortable getting into at this stage | 14:49 |
| hazmat | fwereade_, yeah.. its not really a constraint just a selector on vocab | 14:49 |
| hazmat | fwereade_, fair enough | 14:49 |
| fwereade_ | hazmat, it's not even that now, which is why I think we can drop it | 14:49 |
| hazmat | the keys from the provider would need to be recorded against that provider though to drop it | 14:50 |
| fwereade_ | hazmat, but again, not now :p | 14:50 |
| hazmat | i guess we ignore unknown | 14:50 |
| robbiew | mthaddon: thanks for your help...looking forward to having the charm store up and running :) | 14:50 |
| fwereade_ | hazmat, *all* constraints objects need to be constructed with a provider now | 14:50 |
| hazmat | fwereade_, indeed, but we don't distinguish the provider constraints keys, given a bag of constraints outside of provider-type there is no way of knowing origin definitively. | 14:51 |
| mthaddon | robbiew: sure, np - seems like it's pretty much there at this point - just a case of crossing t's and dotting i's | 14:51 |
| fwereade_ | hazmat, yeah, it's certainly still a valid sanity check | 14:51 |
| robbiew | mthaddon: heh...famous last words ;) | 14:52 |
| mthaddon | indeed... :) | 14:52 |
| fwereade_ | bigjools, allenap: https://codereview.appspot.com/5938050 (or https://code.launchpad.net/~fwereade/juju/maas-name-constraint/+merge/99746 if you prefer) | 14:53 |
| fwereade_ | bigjools, allenap: I would appreciate a sanity review from one of you | 14:53 |
| allenap | fwereade_: I'll look. bigjools is probably snoring in bed right now. | 14:54 |
| fwereade_ | bigjools, allenap: it's based on: https://code.launchpad.net/~julian-edwards/juju/name-constraints/+merge/99673 | 14:54 |
| fwereade_ | allenap, tyvm | 14:54 |
| niemeyer | wrtp: You've got a LGTM | 15:12 |
| wrtp | niemeyer: brilliant, thanks | 15:12 |
| niemeyer | wrtp: Thanks for the work. Looks great | 15:13 |
| niemeyer | I'm stepping out for lunch, biab | 15:13 |
| fwereade_ | going for a quick walk, bbs | 15:51 |
| SpamapS | hazmat: https://codereview.appspot.com/5934054/ SSL hostname verification | 16:08 |
| SpamapS | jimbaker: ^^ would appreciate your review as well :) | 16:08 |
| niemeyer | Go is 1! | 16:23 |
| fwereade_ | niemeyer, cool! | 16:26 |
| robbiew | niemeyer: windows support added...juju on windows! :P | 16:26 |
| hazmat | SpamapS, reviewed, lgtm, i'm curious why not default to cert verify on? | 16:27 |
| hazmat | SpamapS, have you tried it in practice? | 16:27 |
| SpamapS | hazmat: that would be a breaking change.. I'm worried about breaking peoples systems who are using it w/ OpenStack+SSL but invalid certs. | 16:28 |
| SpamapS | hazmat: we should default it to on in honolulu :) | 16:29 |
| hazmat | that's unfortunate, SpamapS okay one suggestion then is turn it on for the default generated config | 16:29 |
| hazmat | so at leasts its explicitly configured onfor new users | 16:29 |
| SpamapS | Oo good idea | 16:30 |
| SpamapS | will add that | 16:30 |
| SpamapS | I was thinking of adding a WARN too | 16:30 |
| niemeyer | robbiew: Easy one :-) | 16:31 |
| niemeyer | robbiew: https://plus.google.com/u/0/107994348420168435683/posts/jdGyHD7NQgU | 16:31 |
| SpamapS | hazmat: seems worthy of warning users whenever it isn't on | 16:31 |
| robbiew | niemeyer: ah...sweet | 16:32 |
| hazmat | SpamapS, indeed | 16:33 |
| SpamapS | hazmat: one thing I've struggled with is writing tests for get_current_ami .. mostly just my not understanding mocker I think. :-P | 16:33 |
| niemeyer | TheMue: how do the changes feel to the watcher branhc? | 16:34 |
| SpamapS | hazmat: http://paste.ubuntu.com/904165/ | 16:34 |
| SpamapS | hazmat: I think that shows what I want.. | 16:34 |
| SpamapS | hazmat: but I don't actually know how to make that work. ;) | 16:35 |
| hazmat | SpamapS, from juju.lib.mocker import MATCH | 16:35 |
| SpamapS | Oh right | 16:35 |
| SpamapS | I've been through this before :) | 16:36 |
| hazmat | def match_context(value): if context is None: return True elif isinstance(context, VerifySSLContext): return True | 16:36 |
| hazmat | cool | 16:36 |
| SpamapS | hazmat: thanks, you just resurrected a lonely neuron that was tumbling through the wasteland.. ;) | 16:36 |
| hazmat | fwereade_, where's this push_default_config coming from? | 16:41 |
| * hazmat is doing a base class deep dive | 16:41 | |
| fwereade_ | hazmat, juju.environment.tests.test_config | 16:42 |
| * fwereade_ did one of those last night | 16:42 | |
| * SpamapS imagines its a hell of a rush | 16:42 | |
| * fwereade_ has never experienced anything like it | 16:42 | |
| fwereade_ | hazmat, in case it's not clear, the basic problem is that almost *everything* needs environment state available once we need a provider to build constraints | 16:43 |
| hazmat | fwereade_, sounds good, just wanted to look over the def since its ref'd lots of places | 16:45 |
| fwereade_ | hazmat, the nice thing is how much redundant code goes away once you inject a few of those in strategic places :) | 16:45 |
| niemeyer | mthaddon: Is the ip address publicly accessible? | 16:55 |
| mthaddon | niemeyer: only on http/https, not to access the appserver directly | 16:57 |
| mthaddon | niemeyer: if you'd like to do a shared screen session I can set that up for you (although I'd prefer if we waited til tomorrow for that as I'm almost EOD) | 16:57 |
| niemeyer | mthaddon: Cool, trying to reproduce your problem locally right now.. should have a reviewable fix in a few minutes | 16:57 |
| mthaddon | ah great | 16:57 |
| niemeyer | mthaddon: I think it's a silly overlook, but just want to see the bug before fixing it | 16:57 |
| * mthaddon nods | 16:58 | |
| niemeyer | mthaddon: So what's the error you see again? | 17:03 |
| mthaddon | niemeyer: no error as such, it's just that it times out - basically if you do a telnet session it doesn't exit cleanly, so nagios (I assume) sits there waiting for it to complete, and it never does | 17:03 |
| niemeyer | mthaddon: What does it mean to exit cleanly? | 17:04 |
| mthaddon | niemeyer: return you to a prompt | 17:04 |
| niemeyer | mthaddon: I mean.. if I wget the URL I provided you, it downloads and quits | 17:04 |
| mthaddon | niemeyer: sure, wget works fine | 17:04 |
| niemeyer | mthaddon: Btw, I may provide you with a different URL, but would like to fix whatever problem exists first | 17:05 |
| niemeyer | mthaddon: Ok, so what's the issue? | 17:05 |
| mthaddon | niemeyer: but try doing a telnet session and then a get request from there | 17:05 |
| niemeyer | mthaddon: Doing it | 17:05 |
| niemeyer | mthaddon: I get a lot of trash on my screen | 17:05 |
| mthaddon | niemeyer: right, and then you don't get a prompt returned, right, you have to manually quit? | 17:06 |
| niemeyer | mthaddon: I get a prompt returned, except it's garbled due to the trash that corrupted the terminal | 17:06 |
| niemeyer | mthaddon: If I do a reset, I get back a normal prompt from there | 17:06 |
| mthaddon | hmm, I don't get a prompt returned :( are you doing HTTP/1.0 or HTTP/1.1 ? | 17:07 |
| niemeyer | mthaddon: I can try either.. with 1.1 it may keep the connection alive | 17:07 |
| niemeyer | mthaddon: By design | 17:07 |
| mthaddon | niemeyer: interesting - I get a prompt returned with HTTP/1.0, not with HTTP/1.1 | 17:08 |
| niemeyer | mthaddon: Ok, let me check in more detail | 17:08 |
| mthaddon | k | 17:09 |
| wrtp | i'm off for the evening. have fun. | 17:19 |
| wrtp | niemeyer: https://codereview.appspot.com/5901058/ is ready for review again. i had to substantially revamp the testing, but i think it's better for that. | 17:21 |
| TheMue | niemeyer: newest watcher is in, now with two seperated watcher types. so if it's LGTY the service config watcher could be changed to use it after the watcher package moved into the trunk. | 17:23 |
| niemeyer | <niemeyer> TheMue: how do the changes feel to the watcher branhc? | 17:23 |
| SpamapS | hazmat: so, logging warnings in juju.providers.ec2.MachineProvider.__init__ seems kind of .. deep for logging... but it also seems like the right level of "YOU ARE DOING SOMETHING STUPID FIX IT" to shriek about this constantly... | 17:23 |
| niemeyer | wrtp: Cheers.. I'll look after I sort out that CS issue | 17:23 |
| hazmat | SpamapS, considering its specific to that provider, its appropriate | 17:24 |
| SpamapS | hazmat: also its not clear to me how to test logging.. mock log or add a logging handler ? | 17:25 |
| hazmat | SpamapS, output = self.capture_logging("log.channel", level=logging.DEBUG) | 17:25 |
| hazmat | SpamapS, after output.. self.assertIn(some_string, output.getvalue()) | 17:26 |
| SpamapS | man | 17:26 |
| SpamapS | you guys thought of everything :) | 17:26 |
| TheMue | niemeyer: did you already took a llok into the current watcher? | 17:26 |
| niemeyer | TheMue: How do your changes feel to you in your new watcher branch!? :-) | 17:26 |
| hazmat | SpamapS, except the spanish inquisition | 17:26 |
| SpamapS | hazmat: well.. I mean... | 17:27 |
| hazmat | we really do need some better state testing base classes, we've got helpers all over the place.. but that one at least is properly in lib/testing.py | 17:27 |
| SpamapS | *NOBODY* expects the spanish inquisition! | 17:27 |
| TheMue | niemeyer: is it a problem to formulate your question in other words? | 17:28 |
| niemeyer | TheMue: I just did it.. | 17:28 |
| niemeyer | TheMue: Do you not understand the sentence? | 17:28 |
| hazmat | Is the branch with the synthetic client event for watches? | 17:28 |
| niemeyer | TheMue: I'm asking what's your feeling about your changes..!? | 17:28 |
| TheMue | niemeyer: oh, now i see the "to you" | 17:28 |
| TheMue | niemeyer: now i got it, i read over the inserted "to you". | 17:29 |
| robbiew | lol | 17:29 |
| hazmat | fwereade_, i believe that's the whole set of initial branches, i'm about to go to the maas branch, re the logging invalid constraint, is that in the current branch set? | 17:31 |
| TheMue | niemeyer: it's ok. but i liked the approach before (but indeed with better namings) too. it has been an elegant interface usage. but updater should better had be named wrapper and wrapper better wrapperCore, wrapperBackend or sth like that. | 17:32 |
| fwereade_ | hazmat, there's constraints-get as well which should be pretty trivial, maas-name is stacked on that one | 17:33 |
| hazmat | fwereade_, cool | 17:33 |
| fwereade_ | hazmat, the logging is not in the current branch set, I think it deserves its own (will hit all of constraints-set, deploy, add-unit) | 17:33 |
| hazmat | fwereade_, sounds good | 17:33 |
| TheMue | niemeyer: it has been a nice approach to add more watchers in future. | 17:34 |
| TheMue | niemeyer: i think now it's a fine small solution, the reduction to pass the event type to update feels good. | 17:35 |
| robbiew | ~$ juju deploy wordpress | 17:36 |
| robbiew | 2012-03-28 12:33:59,108 INFO Searching for charm cs:oneiric/wordpress in remote charm repository: https://store.charms.ubuntu.com | 17:36 |
| robbiew | hazmat: ^ ;) | 17:37 |
| robbiew | store.charms....store.juju ;) | 17:37 |
| niemeyer | TheMue: Ok, the new one looks a lot better, FWIW | 17:37 |
| niemeyer | hazmat: - repo = RemoteCharmRepository("https://store.juju.ubuntu.com") | 17:38 |
| niemeyer | hazmat: +CS_STORE_URL = "https://store.charms.ubuntu.com" | 17:38 |
| robbiew | hazmat: this is from the ppa on precise...also have default-series set "precise", but still seems to pull oneiric | 17:38 |
| TheMue | niemeyer: fine, good news ;) | 17:38 |
| hazmat | niemeyer, which provider? | 17:39 |
| robbiew | ec2 | 17:39 |
| niemeyer | hazmat: ? | 17:39 |
| hazmat | checking | 17:39 |
| niemeyer | hazmat: This is provider independent.. | 17:39 |
| niemeyer | hazmat: The code refactoring done over the URL change landed the store in a different URL | 17:40 |
| hazmat | odd it works on trunk | 17:42 |
| hazmat | re precise as series | 17:42 |
| hazmat | ./bin/juju deploy mysql | 17:43 |
| hazmat | 2012-03-28 13:42:08,422 INFO Searching for charm cs:precise/mysql in remote charm repository: https://store.juju.ubuntu.com | 17:43 |
| hazmat | not the url of course.. i just changed that | 17:43 |
| robbiew | lol | 17:43 |
| robbiew | cool | 17:43 |
| * robbiew isn't using trunk..using ppa | 17:43 | |
| hazmat | i don't believe anything relevant landed in the last day that would have changed that | 17:43 |
| niemeyer | robbiew: I suspect hazmat just changed that as well :-) | 17:43 |
| niemeyer | hazmat: default-series? | 17:43 |
| hazmat | niemeyer, default-series behavior has been the same for a little while | 17:44 |
| * hazmat installs the ppa version | 17:44 | |
| niemeyer | hazmat: If robbiew has an environments.yaml file with default-series set to oneiric, which was the default until a couple of days ago, what would happen? | 17:45 |
| hazmat | niemeyer, it would use oneiric | 17:45 |
| TheMue | The new golang.org looks pretty good (even if we allready knew it from the weeklies). Yay! | 17:45 |
| hazmat | niemeyer, but he's stated its precise | 17:45 |
| * robbiew has default set to precise...correct | 17:45 | |
| hazmat | niemeyer, in the absence of the charm url itself specifying a series | 17:45 |
| niemeyer | Ok, sorry, no idea then | 17:45 |
| hazmat | niemeyer, url fixed on trunk | 17:46 |
| robbiew | ah...I figured it out | 17:46 |
| hazmat | robbiew, what was it? | 17:47 |
| robbiew | I'm an idiot | 17:47 |
| robbiew | default was set to my local provider environment | 17:47 |
| robbiew | which was set to oneiric as default | 17:48 |
| niemeyer | robbiew: Welcome to the club | 17:48 |
| robbiew | juju deploy wordpress -e AWS | 17:48 |
| robbiew | 2012-03-28 12:48:18,678 INFO Searching for charm cs:precise/wordpress in remote charm repository: https://store.charms.ubuntu.com | 17:48 |
| robbiew | so just hazmat's store.charms f*ck up | 17:48 |
| robbiew | lol | 17:48 |
| hazmat | cool | 17:48 |
| niemeyer | mthaddon: Btw, still looking at the issue.. it's definitely related to keep alives, just introspecting to confirm the exact location where the decision to keep it alive is made | 17:51 |
| hazmat | bcsaller, where you able to resolve that trunk-merge missing revs issues? | 17:52 |
| hazmat | mthaddon, can't the nagios check just use http 1.0? | 17:52 |
| bcsaller | hazmat: I was still focused on some of the refactoring in the status , its enough of a reordering that I'm redoing the merge | 17:53 |
| niemeyer | hazmat: It could, but I want to confirm that there's nothing wrong in that regard in the server anyway | 17:54 |
| hazmat | bcsaller, rel-types is ahead in the pipeline, and exhibits the merge problem.. doing it in status still means reverting commits | 17:54 |
| niemeyer | hazmat: Nagios must be testing HTTP 1.1 stuff for quite a while | 17:54 |
| bcsaller | hazmat: I'll go back and check it again | 17:55 |
| niemeyer | mthaddon: Out of curiosity, do you have a dump of the request Nagios send by any chance? | 18:00 |
| hazmat | fwereade_, that should be the full stack, if i'm missing any pls let me know | 18:11 |
| fwereade_ | hazmat, you're awesome, thank you | 18:12 |
| hazmat | niemeyer, /usr/lib/nagios/http_check should have it if you want to install nagios yourself | 18:12 |
| hazmat | its basically just a binary that gets forked for the http check | 18:12 |
| fwereade_ | hazmat, there's a comment on https://codereview.appspot.com/5939046/ -- let me know if I appear to be insane | 18:12 |
| hazmat | fwereade_, i replied on that already.. its not really a problem atm | 18:13 |
| hazmat | fwereade_, but if we have env constraints, not tracking the any values at a given level, makes it appear unset in the composition | 18:13 |
| hazmat | so given the original examples of instance-type at env level constraint, and service level constraint with instance-type=any | 18:14 |
| fwereade_ | hazmat, that loop is only concerned with masking | 18:14 |
| fwereade_ | hazmat, the None still gets stored | 18:14 |
| fwereade_ | hazmat, it just doesn't crew up any others | 18:14 |
| niemeyer | hazmat: Cheers | 18:14 |
| hazmat | fwereade_, doh.. ic | 18:14 |
| niemeyer | hazmat: Mainly curious if it sets the Connection: close header | 18:14 |
| hazmat | fwereade_, carry on the awesome ;-) | 18:14 |
| * fwereade_ blushes | 18:15 | |
| niemeyer | Jeshh.. it's installing half of Ubuntu on my laptop | 18:17 |
| robbiew | lol | 18:18 |
| niemeyer | check_http: Could not parse arguments | 18:18 |
| niemeyer | Usage: | 18:18 |
| niemeyer | (...) [-P string] | 18:18 |
| niemeyer | Note to self.. don't do this.. | 18:18 |
| hazmat | niemeyer, it does have built in help.. also /etc/nagios/checks?/http.conf has some calling syntax examples | 18:21 |
| niemeyer | hazmat: built in where? | 18:21 |
| niemeyer | hazmat: Cool, I'm Googling for examples as well | 18:21 |
| hazmat | niemeyer, -h | 18:21 |
| hazmat | or --help.. i was just looking at a few minutes ago | 18:21 |
| niemeyer | hazmat: Duh.. I thought the help message was the same usage message shown | 18:22 |
| niemeyer | hazmat: Cheers | 18:22 |
| * SpamapS notes that running the unit tests with 'eatmydata ./test' is about 5x faster because ZK no longer must fsync | 18:25 | |
| niemeyer | mthaddon: Do you have the check_http line at hand? | 18:26 |
| niemeyer | mthaddon: It works here as well, and seems to use HTTP/1.0 | 18:27 |
| niemeyer | % /usr/lib/nagios/plugins/check_http -I 127.0.0.1 -p 8080 -u http://localhost:8080/charm/oneiric/jenkins | 18:27 |
| niemeyer | HTTP OK: HTTP/1.0 200 OK - 8697 bytes in 0.003 second response time |time=0.002608s;;;0.000000 size=8697B;;;0 | 18:27 |
| SpamapS | mmmmmmm | 18:27 |
| SpamapS | ops | 18:27 |
| fwereade_ | hazmat, check my logic: when running against a legacy ec2 env, there is absolutely no point warning about the presence of default-image-id or default-instance-type, because (1) they'll still be synced to and used by the PA which is still running old code and (2) even if the user retired them and tried to use constraints... she couldn't, because the PA is running old code | 18:32 |
| fwereade_ | hazmat, (this assumes no change to env settings lands between now and release) | 18:33 |
| SpamapS | hazmat: I kicked off a PPA rebuild to pick up your hostname trivial | 18:33 |
| hazmat | fwereade_, agreed | 18:33 |
| hazmat | SpamapS, thanks | 18:34 |
| fwereade_ | hazmat, cool, I'll sort that out as well | 18:34 |
| hazmat | SpamapS, added some review points to your branch | 18:34 |
| SpamapS | hazmat: gracias | 18:36 |
| * SpamapS is determined to land this by tomorrow :) | 18:36 | |
| fwereade_ | hazmat, judgment call: it suddenly seems that we should skip the instance-type constraint on private clouds and leave them to use the default-* settings exclusively, rather than impose an instance-type set that will be, at best, coincidentally somewhat accurate | 18:38 |
| hazmat | fwereade_, notionally instance-type is a noop atm on a non ec2 provider lacking the mapping information, more troublesome is its undefined against openstack w/ ec2 provider... you lose me on the coincendentally accurate | 18:41 |
| hazmat | at this point the only meaningful context for constraints supported are aws ec2 generics + region+instance-type, and maas+name | 18:42 |
| fwereade_ | hazmat, the trouble is that it's actually not a no-op, but it should be | 18:42 |
| SpamapS | hazmat: AFAICT, the values do not arrive in the schema library as strings, they are loaded directly from yaml and then passed in. | 18:42 |
| fwereade_ | hazmat, and orchestra-classes :) | 18:42 |
| hazmat | fwereade_, given that its in the providers now, i'd go ahead and yank outside of ec2, we definitely the need resource to instance mapping for 12.0.4.1 to make it more universal | 18:43 |
| hazmat | SpamapS, oh right cool | 18:43 |
| hazmat | SpamapS, a test would be nice though | 18:43 |
| fwereade_ | hazmat, yeah, that's in progress but there's no hope of getting it all done today | 18:44 |
| SpamapS | hazmat: adding a few actually, I agree | 18:44 |
| hazmat | SpamapS, effectively all those tests are hitting the optional nature.. and the ec2 provider tests bypass the schema parse | 18:45 |
| hazmat | coo | 18:45 |
| hazmat | l | 18:45 |
| SpamapS | This late in the game.. moar tests == moar sleep. :) | 18:45 |
| hazmat | bcsaller, ping.. how's it going? | 18:45 |
| bcsaller | hazmat: going through the diff again | 18:46 |
| * SpamapS sends bcsaller a vegan pizzagram | 18:47 | |
| bcsaller | heh | 18:48 |
| hazmat | bcsaller, cool want any help with that?, i was trying to figure out how ellided the trunk commits, but it wasn't really clear | 18:51 |
| hazmat | ^it | 18:51 |
| bcsaller | hazmat: yeah, its pretty messy, its avoiding all the status changes you merged, including even the new charm you added to the test repo | 18:52 |
| bcsaller | hazmat: but I'll figure it out | 18:52 |
| hazmat | bcsaller, the only though i had was it didn't get pumped through the pipeline | 18:52 |
| hazmat | i typically have a merge segment at the top of the pipeline for that. | 18:52 |
| hazmat | but frankly its been a while since i resorted to a pipeline | 18:53 |
| niemeyer | Okay, let's see the source code of nagios.. :-( | 19:04 |
| samkottler | niemeyer: I wouldn't do that :P | 19:04 |
| niemeyer | samkottler: Ugh.. I'll close one eye at least :) | 19:04 |
| niemeyer | (just so I have the other one in case it goes really bad..) | 19:05 |
| samkottler | niemeyer: you will have gauged the open one out once you see it | 19:05 |
| samkottler | niemeyer: hahaha jinx | 19:05 |
| hazmat | niemeyer, traffic sniff didn't do it? | 19:07 |
| niemeyer | hazmat: It just works, but it sends HTTP/1.0 | 19:07 |
| niemeyer | hazmat: There's no obvious way to force it into 1.1 | 19:08 |
| hazmat | mthaddon, do you have the config/param for the nagios check handy? | 19:08 |
| hazmat | niemeyer, where does the 1.1 requirement come in? | 19:08 |
| niemeyer | samkottler: Gosh.. you weren't kidding.. | 19:08 |
| niemeyer | hazmat: The requirement is for it to fail, so that I can confirm why :) | 19:09 |
| niemeyer | hazmat: HTTP/1.0 doesn't keep connections alive by default | 19:09 |
| niemeyer | hazmat: and it just works | 19:09 |
| niemeyer | hazmat: I'm betting Connection: close is being mishandled, and that's all, but I wouldn't like to close the door on the problem without confirming | 19:10 |
| niemeyer | For general appreciation: http://paste.ubuntu.com/904396/ | 19:11 |
| hazmat | niemeyer, my eyes! | 19:12 |
| niemeyer | :-) | 19:13 |
| bcsaller | I like how they broke that code up into manageable chunks | 19:15 |
| bcsaller | not so much.. | 19:15 |
| niemeyer | :-) | 19:16 |
| niemeyer | /* Nagios monitors the world and we monitor Nagios taking over the world. :-) */ | 19:16 |
| niemeyer | char *api_server="api.nagios.org"; | 19:16 |
| niemeyer | char *api_path="/versioncheck/"; | 19:16 |
| niemeyer | How come no one is going to Slashdot to point out how evil the developers are? | 19:17 |
| hazmat | niemeyer, there's a reason ichinga exists.. | 19:17 |
| hazmat | er.. icinga | 19:17 |
| hazmat | https://www.icinga.org/faq/why-a-fork/ | 19:18 |
| niemeyer | hazmat: Oh my :-) | 19:19 |
| niemeyer | """ | 19:19 |
| niemeyer | In recent years, Nagios’ popularity as an open source monitoring solution saw it evolve into a quasi open source industry standard. | 19:19 |
| niemeyer | """ | 19:19 |
| niemeyer | I swear for a flash moment I expected the sentence to end with "..., and we can't stand a standard." | 19:19 |
| SpamapS | its just oozing irony | 19:20 |
| niemeyer | I guess I'll just give up, fix what I think is broken, and wait for mthaddon tomorrow | 19:27 |
| SpamapS | hazmat: more tests.. better logs.. I think we're close. :) | 19:32 |
| hazmat | SpamapS, cool, checking it now | 19:47 |
| fwereade_ | hazmat, almost a trivial: https://codereview.appspot.com/5933058 | 19:54 |
| hazmat | fwereade_, looks good. one question do we warn about newer clients trying to set constraints against legacy envs? | 19:58 |
| hazmat | SpamapS, is txaws in precise going to have the ssl cert checking? | 19:59 |
| fwereade_ | hazmat, hmm, no non-hackish way AFAICT... if machine/0 has incomplete constraints, that's a clue | 19:59 |
| hazmat | fwereade_, well we know its a legacy env.. so effectively with that and attempt to use constraints is basically a warn worthy noop | 20:01 |
| hazmat | s/and/an | 20:01 |
| fwereade_ | hazmat, we don't know it's a legacy env without checking something hackish like that | 20:01 |
| fwereade_ | hazmat, unless the legacy env happened to have legacy keys set | 20:01 |
| hazmat | fwereade_, ic | 20:02 |
| fwereade_ | hazmat, I agree it's good to warn in that situation, and I think it can be encapsulated reasonably pleasantly | 20:02 |
| niemeyer | TheMue: Still around by any chance? | 20:08 |
| TheMue | niemeyer: yip | 20:11 |
| niemeyer | TheMue: Just wanted to say thanks.. the branch is great | 20:11 |
| TheMue | niemeyer: currently preparing a go talk i'm giving on monday at a gtug | 20:11 |
| niemeyer | TheMue: I mentioned a minor detail related to "err != nil" that should be addressed, but please feel free to submit it after replacing the check | 20:12 |
| TheMue | niemeyer: will check it tomorrow after gym. but that are good news. | 20:13 |
| niemeyer | TheMue: Yeah, didn't expect it to be done now.. just wanted to give you the +1 | 20:13 |
| TheMue | niemeyer: thx | 20:14 |
| TheMue | niemeyer: rog and i chose to test for nil channel instead for err because i otherwise would have to return an extra error when in update() i receive a tomb.Dying. | 20:16 |
| TheMue | niemeyer: and in loop() i would have to test it extra to not do a tomb.Kill() with that error then | 20:17 |
| niemeyer | TheMue: Hmm | 20:41 |
| SpamapS | hazmat: txaws in precise already has the ssl cert checking cherry picked in. :) | 20:44 |
| SpamapS | hazmat: and the PPA has it as well | 20:44 |
| niemeyer | TheMue: I don't think any extra tests are necessary. | 20:47 |
| niemeyer | TheMue: Returning nil, nil is error prone | 20:47 |
| TheMue | niemeyer: it's a bit different, yes | 20:48 |
| samkottler | niemeyer: are you hacking on Nagios internals? | 20:48 |
| TheMue | niemeyer: but if i recieve a tomb.Dying during the send in update(), what kind of error shall i return? it will be passed to tomb.Kill() afterwards. | 20:50 |
| niemeyer | TheMue: Well, even if it returns no error, though.. it shall work, shall it not? | 20:51 |
| niemeyer | TheMue: A bit of an icky design, though | 20:51 |
| niemeyer | TheMue: That's exactly why there was a Stop variable in tomb, actually | 20:52 |
| niemeyer | TheMue: Unfortunately I forgot about it when debating with wrtp | 20:52 |
| niemeyer | TheMue: Maybe we should bring it back | 20:52 |
| TheMue | niemeyer: currently it returns no error, and i use a nil channel to end loop() work. if i check for an error to stop the loop i need an error | 20:52 |
| niemeyer | TheMue: Yeah, that was tomb.Stop | 20:53 |
| TheMue | niemeyer: ah, the missing link | 20:53 |
| TheMue | niemeyer: as long as we don't got it i could continue as it is or i can change to a dummy error | 20:54 |
| niemeyer | TheMue: Please just commit it as is then.. I'll sort something out later, as this work shouldn't be held back by that minor | 20:54 |
| TheMue | niemeyer: fine, will do so | 20:55 |
| niemeyer | TheMue: I may introduce a tomb.Dying error | 20:55 |
| niemeyer | TheMue: Something like | 20:55 |
| TheMue | niemeyer: sounds good | 20:55 |
| niemeyer | var Dying = errors.New("tomb: dying") | 20:55 |
| niemeyer | TheMue: Which if provided to Kill doesn't change the error state of the tomb | 20:56 |
| niemeyer | TheMue: No matter what it is | 20:56 |
| TheMue | niemeyer: did you already tagged your packages for go1? | 20:56 |
| niemeyer | TheMue: No, but should just work | 20:56 |
| niemeyer | TheMue: Oh! | 20:56 |
| niemeyer | TheMue: Maybe not :) | 20:56 |
| niemeyer | Crap | 20:56 |
| hazmat | SpamapS, great | 22:08 |
| SpamapS | 2012-03-28 15:01:43,785 WARNING Charm '.mrconfig' has an error: CharmError() Error processing '/home/clint/charms/oneiric/.mrconfig': unable to process /home/clint/charms/oneiric/.mrconfig into a charm | 22:10 |
| SpamapS | http://paste.ubuntu.com/904647/ | 22:10 |
| SpamapS | trivial, or should we test that behavior? | 22:10 |
| hazmat | SpamapS, i'm fine with that as a trivial.. tests are always nice, its a trivial test as well | 22:12 |
| SpamapS | hazmat: I think there may be some missing test coverage in there.. I added some missing files to the test repo and no tests failed.. which I would have expected due to the FileNotFound errors that should have been raised. | 22:15 |
| hazmat | SpamapS, it only processes directories | 22:24 |
| hazmat | or bundles | 22:24 |
| hazmat | the bundles/zip archives have a known extension.. you can turn on the loggin in the test to see the skips | 22:24 |
| SpamapS | -rw------- 1 clint clint 3041 Jan 30 11:15 .mrconfig | 22:25 |
| hazmat | SpamapS, if that's in a charm, it will be ignored.. charms dir -> archive drops hidden files afaicr | 22:26 |
| hazmat | if its a directory by itself from the logic you added you won't even see it | 22:26 |
| SpamapS | hazmat: no its in the series dir | 22:26 |
| hazmat | ic | 22:27 |
| SpamapS | hazmat: still investigating. Its low priority.. so I'm inclined to just merge the trivial to suppress the not-useful warning and move on (despite my earlier suggestion that moar tests are moar gooder ;) | 22:27 |
| hazmat | it shouldn't be poking in series directory.. it already knows the series path its going to inspect.. the charm dir repo is the series path (with the series value) | 22:27 |
| SpamapS | hazmat: juju.charm.repository.LocalCharmRepository._collection ... just uses os.listdir | 22:28 |
| SpamapS | hazmat: oh I see what you mean though | 22:30 |
| SpamapS | hazmat: its raising CharmError, not ignoring | 22:30 |
| SpamapS | (it being juju.charm.provider.get_charm_from_path) | 22:30 |
| SpamapS | hazmat: I kind of like moving the ignore to there now that I think about it | 22:31 |
| SpamapS | err | 22:31 |
| SpamapS | no | 22:31 |
| SpamapS | ignore me.. need caffeine I think | 22:31 |
| * hazmat tries to process | 22:32 | |
| hazmat | SessionExpire | 22:32 |
| * SpamapS kill(pidof('hazmat'),SIGSTOP) | 22:33 | |
| SpamapS | hazmat: I'll SIGCONT you in 3 hours.. ;) | 22:33 |
| * hazmat registers an ignore mask | 22:33 | |
| bigjools | hi folks | 22:34 |
| hazmat | bigjools, greetings | 22:35 |
| Daviey | $ killall -SIGSTOP hazmat | 22:36 |
| Daviey | hazmat(3459): Operation not permitted | 22:37 |
| Daviey | :( | 22:37 |
| hazmat | only a SIGKILL can stop me now :-) | 22:37 |
| hazmat | niemeyer, seems like there is some uptick the doozerp from other folks | 22:44 |
| hazmat | in the interest | 22:44 |
| SpamapS | doozerp? | 22:48 |
| hazmat | SpamapS, doozerd with persistence.. golang's version of zk | 23:06 |
| hazmat | er.. impl | 23:06 |
| SpamapS | Ahh | 23:07 |
| SpamapS | I've been thinking more and more about why we even have a central place for all this state lately. | 23:08 |
| SpamapS | like, why not decentralize it, and go for more of a 0mq like model where the agents just talk to one another when they need to.. and the client simply pushes out an intent map somewhere and triggers events on the agents it knows needs them. | 23:10 |
| SpamapS | perhaps thats a lot harder than it sounds, but I am worried about the implications of ZK's lack of partition tolerance. :P | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!