=== TheMue_ is now known as TheMue [08:25] TheMue: morning! [08:26] wrtp: moin [08:26] TheMue: amazingly gorgeous weather here. yesterday we had sunshine all day and 19 degrees. [08:26] TheMue: same again today, but my computer display doesn't work well in the sun :-( [08:27] wrtp: we had a nice weekend too, but right now it's fog and not yet really warm [08:28] wrtp: i've got two places to sit outide, one works pretty well with notebook. the other one needs higher temperatures, but i'll test it then. [08:52] wrtp: btw, i've combined our discussion results into a watcher package parallel to the presence one and it's pretty simple. i'm now adding first test cases for content and children to demonstrate how it works. but it's neat small. [08:52] TheMue: small is nice :-) [08:52] TheMue: looking forward to seeing it [08:53] wrtp: your ideas have been helpful [08:54] TheMue: i'm glad, thanks. i try to be :-) === asavu_ is now known as asavu [09:51] wrtp, TheMue: kinda long shot, but do you know why we *insist* on running ebs-backed instances? [09:51] wrtp, TheMue: sensible default, but... [09:52] fwereade_: i've wondered that in the past [09:52] fwereade_: but i've no idea, sorry [09:52] fwereade_: sorry, don't kknow [09:52] cheers guys [09:56] wrtp, TheMue: another: do you know whether the HVM image requirement is necessarily intrinsic to an instance-type? instinct says no, but I don't really know much about this stuff [09:57] fwereade_: no idea again, sorry. [09:57] fwereade_: i don't know any of the rationale for any of the image choice stuff - i just copied by rote. [09:57] wrtp, sorry to say it's all being rewritten anyway :p [09:57] fwereade_: that's fine, it's not much code in go [09:59] fwereade_: i'm still to young in the project and too focussed on state to know many of the rationales [09:59] TheMue, no worries, but that won;t stop me asking questions just in case :;) [10:00] fwereade_: yep ;) [10:25] lunchtime [10:50] fwereade_: http://paste.ubuntu.com/900253/ [10:50] :-) [10:51] fwereade_: first actual usage of go juju from the command line [10:51] wrtp, awesome!! [11:09] TheMue: ping [11:10] wrtp: pong [11:10] TheMue: i've got a little problem with state/internal_test.go [11:10] TheMue: which is that it depends on the testing package... and i want to make the testing package depend on state [11:11] TheMue: do you think it's possible to define the tests in internal_test.go outside state? [11:11] wrtp: why that? i thought "testing" is an internal utility package? i'm now using it for the watcher test too. [11:12] TheMue: its fine for external tests to depend on testing. but internal tests are different [11:13] TheMue: actually the only dependency is testing.ZkRemoveTree [11:13] TheMue: it could use the internal version, if that was beefed up a little. [11:14] wrtp: i had an own zkRemoveTree() before the one in testing had been available [11:15] wrtp: if that's the only point it should be changeable easily [11:15] TheMue: you've still got a zkRemoveTree, in util.go [11:15] wrtp: have to look where that is used [11:16] TheMue: which could work fine for internal_test to use [11:16] TheMue: it's used internally, e.g. when removing a unit [11:16] wrtp: so it shouldn't be a problem for internal test, yep [11:18] TheMue: cool. i'll copy the testing version (appropriately changed) to state/util.go, so it can cope with removing "/" [11:18] wrtp: great [11:52] fwereade_, TheMue: something to review, if you fancy it: https://codereview.appspot.com/5901058 [11:53] fwereade_: i hope you don't think i've mangled cmd/juju *too* much :-) [11:53] fwereade_: i did remove some comments which i thought were redundant. [12:03] wrtp: two small comments back [12:04] TheMue: thanks [12:05] "The purpose sounds a bit strange related to "destroy"." [12:05] lol [12:05] indeed! [12:06] TheMue: BTW it's conventional for usage messages to be printed to stderr - they're usually printed in response to a usafe error. [12:06] usage error [12:08] wrtp: there's no "juju help destroy|grep foo"? [12:08] TheMue: there's no juju help [12:08] wrtp: maybe there should be a difference if it is requested or by error [12:08] TheMue: you've got juju -help which is different [12:09] TheMue: it's standard that -help goes to stderr [12:09] TheMue: juju destroy -help |[2] grep foo :-) [12:10] TheMue: or in bash: juju destroy -help 2>&1 | grep foo [12:12] wrtp: hmm, "diff --help|grep text" works fine here [12:14] TheMue: hmm, yeah. godoc --help | grep test doesn't [12:15] TheMue: perhaps the flag package should distinguish [12:15] TheMue: unfortunately that means that API would have to change, i think [12:17] wrtp: some way to use the same Info for help as for error display would be nice [12:17] TheMue: it does use the same info currently, i think. [12:17] TheMue: --help is handled by the flag package [12:18] wrtp: ok [12:18] wrtp, only looked at that casually but I'm totally happy with what you've done; I'm not sure whether "no comments" is better or worse than "repetitive comments", but meh [12:20] fwereade_: if i *was* going to have comments there, i think i'd have them of the form: // Info implements cmd.Command.Info. [12:20] fwereade_: so that we avoid having the redundancy, but there's still some useful info. [12:21] fwereade_: but i've tried that before and gustavo's not keen. [12:21] wrtp, fair enough :) [12:34] g'morning [12:34] * hazmat is thankful for unity2d this am [12:34] the default busted on me after an upgrade [12:36] heya hazmat [12:36] hazmat, it seems to me that, for now, there is only one kind of legacy we can predict? [12:36] hazmat, am I missing something really obvious? [12:37] hazmat, (or have I just been infected with a gotastic but unpythonic tendency towards shortest-possible-names?) [12:38] fwereade_, only that inevitably legacy will come to me more than one thing in the future [12:38] s/me/mean [12:38] i'm hopeful that with an upgrade system in place this can be minimalized via a state upgrade manager [12:38] in the future [12:39] hazmat, my reading is that that's merely a "probably" and therefore not quite enough justification to imply multiples until they exist [12:39] fwereade_, i guess the skinny is i'd rather call it what it is, then give it an overly generic name [12:39] hazmat, fair enough all the same [12:45] hazmat, btw, I just thought: if we're going to be providing provisioning info for EC2, I should be setting that up ASAP... but I'm not quite sure that uec-images is quite the right place for it [12:46] hazmat, do you have other suggestions and/or know who I should be speaking to to arrange this? [12:51] fwereade_, smoser [12:52] or ben howard [12:52] i'm stepping out for a few, bbiab [13:02] niemeyer: morning! [13:03] just off for lunch in the sunshine. [13:03] Good morning! [13:15] niemeyer, heyhey [13:17] fwereade_: Heya [13:19] niemeyer: moin [13:20] TheMue: Moin moin! :) [13:20] :D [13:25] fwereade_, btw. i put my branches you reviewed into the approve queue.. we're only one requiring one review, unless the reviewer notes that they think a second review is nesc. if you think any of the ones you reviewed would benefit from a second review, please mark them ready for review [13:25] hazmat, cool, will do [13:26] hazmat, incidentally, trivial: http://paste.ubuntu.com/900437/ [13:26] fwereade_, lgtm [13:26] hazmat, cheers [13:37] wrtp, niemeyer: https://codereview.appspot.com/5905064 [13:57] back [13:59] TheMue: i'm still not sure why we need to do the child watcher and the contents watcher with the same code [14:00] wrtp: to reduce code [14:00] TheMue: it's not much code, and i think each one would be clearer if it wasn't trying to be generic. [14:01] TheMue: having a channel []string where the first element might contain the name of a child or the contents of a node seems odd to me. [14:01] wrtp: each one would have the same amount of code with one (!) method less [14:02] TheMue: i'm thinking about the API it presents, the foundation that other things are building on. [14:02] niemeyer, fwereade_ where discussing x-name support for maas/orchestra providers, afaicr while their have been requests to support it, we haven't agreed to do it on the basis that it violates juju's principle of not associating services to machine identity [14:02] TheMue: i think that would be clearer if it was different for each kind of watch (even if you use the same code underneath) [14:03] wrtp: so in this case you prefer code duplication? [14:03] hazmat: That's right [14:04] TheMue: i think so. or at least two similar APIs on the outside, with two channel types. [14:04] niemeyer, hazmat: ok, that's cool; I'll implement orchestra-classes only then [14:04] hazmat, there's no underlying mechanism by which we can support maas-classes anyway, right? [14:04] fwereade_, nope [14:04] wrtp: your problem is the channel type? [14:04] fwereade_, this cycle they only support name afaik [14:05] TheMue: mostly, yes. [14:05] hazmat, niemeyer: ok, so we're happy releasing maas support without *any* applicable constraints? [14:05] wrtp: so a reduction to one returned type, e.g. Change, with better methods, would be ok? [14:05] fwereade_, hazmat: That's something we develop.. it's easy to sync up on it [14:06] fwereade_: I'd suggest recommending the adoption of classes on the other side [14:06] fwereade_, well we can only support at minimum what maas supports [14:06] TheMue: i think there should be a different type for each kind of watcher (child vs contents) [14:06] hazmat, indeed, that's the argument for maas-name (weak as it may be) and consequently the argument for orchestra-name [14:07] TheMue: in the same way that Children returns a different type to Get. [14:07] fwereade_, i'll rendevous with the maas folks, just to make sure we're on the same page, but as niemeyer notes, its easy to update both as needed. [14:07] fwereade_, except name violates juju's design principles.. so its a non starter in that regard [14:07] hazmat, yep, fair enough [14:08] TheMue: so i think having two different types (ChildWatcher and ContentsWatcher) makes sense, even if they share some code under the hood [14:09] wrtp: ok, e.g. watcher as private type and ChildrenWatcher and ContentWatcher as wrapping public types? [14:10] TheMue: yeah, i think that could work well. [14:10] wrtp: still don't think it's needed but it's ok, yes [14:12] wrtp: i'll change and re-propose it immediately [14:13] fwereade_ incidentally if you need to reach those guys.. their all hanging out on can irc #cloud-dev .. looks like their still trying to get juju basics with maas working though [14:13] TheMue: i think i'd just duplicate the code for each type. we were thinking about duplicating the code n times (once for each kind of watcher); this is just twice overall. [14:13] fwereade_, no constraints for maas is confirmed [14:14] TheMue: i *think* that trying to avoid the code duplication will make for more complex code with not a great deal of benefit. [14:14] wrtp: i don't even think two type would give great benefit. *lol* [14:14] hazmat, ok, cool [14:15] TheMue: we've got two types going on under the hood anyway (hence the switches on changeType) [14:16] fwereade_, at least for 12.04 [14:17] hazmat, indeed, I imagine we'll get a bit more done for 12.04.1 [14:20] wrtp: imho it is only one type, like a wrench with two sizes [14:21] TheMue: why doesn't Get return the same type as Children? [14:22] wrtp: wy doesn't an 18mm side of a wrench can turn 17mm screws? [14:23] hazmat: I've had some issues trying to get juju-trunk to work in practice [14:23] TheMue: why can't you use int16 as int32? :-) [14:23] hazmat: How have you guys been exercising the py code from trunk? [14:23] wrtp: *lol* [14:25] niemeyer, i use local provider on a regular basis [14:25] TheMue: I haven't been paying much attention to that discussion, but ChildrenWatcher and ContentsWatcher are both not entirely clear to me as being good approaches [14:25] wrtp: as a compromise i would implement watcher as private type and provide two public types using it [14:25] TheMue: Watches have custom events, right? [14:25] niemeyer: what kind of approach are you thinking of? [14:25] TheMue: If so, ContentWatch is too low level [14:26] niemeyer: i'm thinking that ChildWatcher and ContentsWatcher make a good basis for layering onto [14:26] niemeyer: so far wrtp and me discussed only children and content changes [14:26] niemeyer: then higher level watches can be done as a simple pipeline [14:26] wrtp: layers should not be public.. the state package is not about zookeeper nodes [14:26] wrtp: yep [14:26] niemeyer: i wouldn't export these types [14:26] wrtp, TheMue: At least that's my perception at the moment.. I'm happy to review the code later [14:26] niemeyer: or perhaps they might go in another package [14:27] wrtp: FooBar is an exported type in Go [14:27] wrtp: I know you understand that, but you've been talking about an exported type [14:27] niemeyer: they are public like the presence pinger [14:27] niemeyer: these aren't exported from the state package. [14:27] wrtp: Ok, cool [14:28] TheMue: but tbh i'm not sure these deserve their own package [14:28] hazmat: What about ec2? [14:28] niemeyer: it's an own package, parallel to presence [14:28] wrtp: like presence [14:28] TheMue: Ok.. let's see then [14:28] not entirely convinced that presence holds its weight either as a separate package. [14:28] niemeyer, i check there once a week [14:28] wrtp: Looks pretty good to me [14:28] niemeyer, what problems are you having? [14:29] wrtp: indeed, both could be re-integrated as private state libs, yes [14:29] niemeyer, btw.. some priv messages went your way [14:29] hazmat: I've pasted details on Friday [14:29] hazmat: juju-admin is still broken [14:29] niemeyer, with what version? [14:30] 494 i guess [14:36] niemeyer, i've had an env running on that version in ec2 since friday [14:37] hazmat: Well, have you seen the error? [14:37] hazmat: I'm not doing anything fancy there.. [14:38] niemeyer, all my units come up.. [14:38] * hazmat checks his juju origin [14:38] hazmat: Sounds good then.. [14:38] niemeyer, i'm using juju-origin: lp:juju [14:38] hazmat: Me too.. [14:39] niemeyer, hmm.. i'll try again with a fresh env [14:40] hazmat: I don't have any good explanations.. wtf works on 494 too [14:40] hazmat: s/works/worked/ [14:40] hazmat: But that error message is real [14:41] hazmat: Hmmm.. [14:41] % bin/juju bootstrap [14:41] error: Environments configuration error: /home/niemeyer/.juju/environments.yaml: environments.sample.default-series: required value not found [14:44] niemeyer, indeed its been required for several months [14:44] hazmat: Woah? [14:44] like back in november/dec afaicr [14:45] if you got it to deploy with that then it sounds like you have an old client version installed [14:45] er. without [14:45] TheMue: here's one possibility for a restructuring: http://paste.ubuntu.com/900559/ [14:45] hazmat: No.. I just removed the entry from my configuration file [14:45] hazmat: Hoping it would pick a default value [14:46] TheMue: (not that i've actually run the code or anything :-]) [14:47] wrtp: 173 vc 139 LoC [14:47] wrtp: ;) [14:47] niemeyer, sans a config file the default generated will include one, but its been a required thing for a while, the arguments at the time where just because i'm using an oneiric laptop doesn't mean i don't want a precise deploy.. ie. don't guess [14:48] TheMue: line count isn't everything :-) [14:48] hazmat: I don't understand the perspective [14:48] hazmat: There's a guess being made either way [14:48] hazmat: It's just hardcoding the guess in the configuration file [14:48] wrtp: yip, that's right [14:49] wrtp: will have to take a deeper look [14:49] niemeyer, which the user needs to edit likely.. ie. its explicitly configured vs implicitly guessed by the runtime [14:49] hazmat: Next time you pick a different laptop, it'll hardcode another guess [14:49] hazmat: When you change between the laptops, it'll alternate between the guesses [14:49] hazmat: That's why we're moving this onto the environment settings [14:50] niemeyer, yes.. we're changing it [14:50] hazmat: Which means this isn't supposed to be enforced in the local configuration.. the environment will have an unrelated default [14:50] niemeyer, but we're trying to remain compatible and error if its used in non legacy environments [14:51] hazmat: Ok.. if default-series isn't accepted at all in new environments, then it doesn't matter much [14:52] niemeyer, well its recorded on the environment directly [14:52] and not sync'd from every client, ie it must be explicitly set post init [14:53] hazmat: or as --default-series I suppose [14:53] ideally we just record it as a constraint against bootstrap per the syntax in the spec [14:53] hazmat: s/constraint// [14:53] where its just --constraint="series=precise" [14:54] hazmat: This is not a constraint [14:54] hazmat: This is an environment setting.. the series for a service comes from the charm (!!) [14:54] hmm.. yeah its not a user constraint [14:54] niemeyer, really ? i had no idea [14:54] hazmat: Yeah.. it's a novel concept I just came up with [14:57] hazmat, series comes from the charm; charms don't have constraints; we need the environment to get the default-series [14:57] hazmat, whoops, what niemeyer said [15:00] fwereade_, yup [15:04] niemeyer, so re your ec2 problems it sounds like you have an old client around [15:04] niemeyer, and re the env-settings proposal i don't see the review on the latest [15:05] hazmat: [15:05] [niemeyer@gopher ~/src/juju/trunk]% bzr revno [15:05] 494 [15:05] [niemeyer@gopher ~/src/juju/trunk]% bzr diff [15:05] [niemeyer@gopher ~/src/juju/trunk]% [15:05] niemeyer, okay if you can capture console output, i'd be happy to take a look [15:05] hazmat: The error from the console output is in that paste I sent you on friday [15:06] niemeyer, i fixed that on friday for r494 [15:06] hazmat: Will check the review [15:06] hazmat: No, it's a different error. it says juju-admin not found, rather than anything related to zkpython [15:06] TheMue: perhaps the separated structure becomes slightly more compelling if the events are a little more complex. for instance, i think we'll probably want to deliver child deltas rather than all children each time. here's an example that does that. http://paste.ubuntu.com/900583/ [15:07] niemeyer, the paste i have from you is http://paste.ubuntu.com/897051/ [15:07] which is the client error, not the server [15:07] hazmat: Ah, you sent another revision on env-settings, will review again [15:08] hazmat: Yeah, that's another error I'm still seeing, with the new client, but I don't care as much [15:08] niemeyer, could you pastebin the ec2-get-console-output of the bootstrap node [15:08] TheMue: do we already have this use case? [15:08] arg, talking with myself [15:09] i'm curious why its occuring or why wtf or myself can't reproduce [15:09] wrtp: do we have this use case? [15:09] TheMue: yes [15:09] TheMue: that's what the watchers tend to do in the python version AFAIR [15:09] niemeyer, is it possible you used 'juju' with a ppa package installed? [15:11] hazmat: No, only have the charmstore from the ppa [15:11] wrtp: my idea has been that the watcher is repsonsible for the raw delivering while retrieving of details, building deltas, creating configuration nodes and something like that would have to be done by the user of the watcher. [15:11] hazmat: I'm grabbing the output [15:11] wrtp: that why i showed you the idea of behaviors via paste [15:11] TheMue: if all use cases that watch for changes in the children want deltas, then i think that's what ChildWatcher should produce [15:12] hazmat: This is the real error I think: [15:12] sudo: /usr/bin/bzr: command not found^M [15:12] hazmat: Full output: http://paste.ubuntu.com/900601/ [15:12] wrtp: as long as all want it yes [15:13] interesting.. this looks like the issue ... E: Package 'python-argparse' has no installation candidate [15:13] wrtp: so once again the private one as the engine behind it and the public ones delivering raw content or children deltas [15:13] * wrtp tries to find that piece of python code [15:13] hazmat: Indeed.. argparse is part of 2.7 isn't it [15:13] niemeyer, it is [15:13] TheMue: yeah, that sounds good. [15:14] hazmat: This was probably working until python2.6 was removed [15:14] TheMue: what did you think of the example i suggested? [15:14] hazmat: By chance [15:14] niemeyer, but the package still exists in precise as a virtual [15:14] TheMue: (as a possible structure) [15:14] wrtp: i'm fine with that idea too [15:14] hazmat: Yeah, but I don't think that'd make the command work [15:14] TheMue: i think that's roughly the same idea [15:15] hazmat: It's already installed [15:15] TheMue: the watcher type is the private shared implementation [15:15] wrtp: exactly [15:15] TheMue: the other types layer type-specific behaviour on top of that [15:18] TheMue: i can only currently see two places in the python code that watches children. (both state/relation.py) [15:19] niemeyer, that's odd still, because we don't request argparse installation [15:19] niemeyer, for example here's my cloud-init from trunk against a newly bootstrapped ec2 instance.. http://paste.ubuntu.com/900611/ [15:21] niemeyer, that was removed in r441 [15:21] re argparse [15:21] juju/providers/common/cloudinit.py: "python-argparse", "python-txaws", "python-zookeeper"] [15:21] hazmat: My tree must be damaged somehow [15:22] hazmat: I'll kill it all and start over [15:22] hazmat: Yep, it's gone now.. [15:23] hazmat: It was my mistake indeed.. bzr was lying.. even though it was saying revno was 494, the content was updated to a different revision when I was debugging stuff [15:23] hazmat: and diff didn't bother to tell [15:23] hazmat: Sorry for the trouble/noise [15:24] niemeyer, yeah.. bzr isn't very nice when on non head rev [15:24] Destroying and rebootstrapping [15:28] niemeyer: i did that with the go tool for real for the first time this morning :-) [15:28] niemeyer: from the command line, with the same environment.yaml i was using for the python juju. [15:28] wrtp: Wow, that's very good to hear :) [15:28] wrtp: !! [15:28] niemeyer: i had to do a destroy first, because it found the old state file :-) [15:32] hazmat: "Can we have an equals sign within each option." [15:32] hazmat: That's talking about "apt-proxy http://us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com/ubuntu/" [15:33] hazmat: You've probably just missed it [15:39] niemeyer: are we going to have a meeting today, as discussed on fri? [15:40] wrtp: I guess we lost the timing by 2h already.. :( [15:40] wrtp: I'm game to do it right now [15:40] fwereade_, TheMue? [15:40] niemeyer: me too. [15:41] niemeyer: yeah, sad to see winter go, for that reason only :-) [15:41] niemeyer, sure [15:42] niemeyer: i'm ready. an calendar invitation would be helpful too, to send an automatic reminder [15:43] COol, let's go then! [15:43] niemeyer: will you do the invites? [15:43] wrtp: Yeah [15:44] Done [15:46] niemeyer, sure [15:52] niemeyer, re bug https://bugs.launchpad.net/juju/+bug/937949 [15:53] i'm planning on attaching a looping task to update the unit metadata [15:53] just curious if you had an objection [15:53] we have no notification from the provider when the address changes, so i don't see any other possibilities [15:54] since its performed out of band of juju itself [16:33] hazmat: Crap.. I had no idea ec2 invalidated the previous address if an EIP was assigned [16:35] hazmat: I'm stepping out for lunch.. will think about it meanwhile.. can we catch up later on that? [16:41] niemeyer, sounds good [16:41] hmm.. alternatively we could skip storage of public addr, and always resolve it [16:42] but that might break publicly exposed charms [16:42] if the use unit get-info [16:42] there's a secondary but related issue here of rebooting the bootstrap node and it comes up with a different ip [16:42] but that's private addresses [16:43] for which storing the zk address into the provider storage directly has some value, and distributing the signed url [16:43] oto the agents [17:05] Hey guys I just realized we query uec-images.ubuntu.com with http, not https ... [17:06] Going to file a bug and a quick merge proposal (its a one line change). [17:08] "its a one line change"....famous last words [17:08] lol [17:08] le sigh ;) [17:10] right, one line of code.. 15 lines of test.. :-P [17:18] http://chrisjpowell.com/do-you-have-your-juju [17:19] ./juju/providers/ec2/utils.py: "http://uec-images.ubuntu.com/query/" [17:19] oops [17:19] https://bugs.launchpad.net/ubuntu/+source/juju/+bug/965507 [17:19] hazmat: nice [17:19] SpamapS, sounds good [17:19] hazmat: please ACK and I'll push it into trunk [17:19] fwiw, status changes are about to land (discussed on list last week) [17:20] SpamapS, sure, just show me the delta and run the tests [17:21] hazmat: I don't commit until tests pass. :) [17:23] SpamapS, ack'd [17:24] hazmat: thanks, I'll push now [17:25] SpamapS, ssl without cert checks is still MITM vuln [17:26] hazmat: please don't tell me twisted doesn't verify certs [17:26] its a good step forward even ignoring that [17:26] SpamapS, it can be configured to do so [17:26] like, not by default though? WTF [17:28] Agent is a very basic HTTP client. It supports HTTP and HTTPS scheme URIs (but performs no certificate checking by default). It does not support persistent connections. [17:28] so [17:28] i'm off to enjoy the evening. see y'all tomorrow [17:28] even the store is MITM vulnerable [17:29] SpamapS, no its not configured to use it by default [17:33] * SpamapS sighs [17:34] twisted.. ye disappoint me [17:37] *wow* .. nothing even built in to do it [17:37] https://code.launchpad.net/~therve/txaws/ssl-verify/+merge/83740 [17:38] robbiew: hah.. you're right.. one line change my *** :) [17:38] lol [17:40] SpamapS, that's going to verify by platform as well [17:41] osx does something different for certs [17:44] * niemeyer waves [17:45] SpamapS, thanks for that link, thats pretty useful [17:48] * hazmat grabs a lunch snack [17:48] hazmat: indeed, twisted should already have this built in.. its sort of shocking that they don't. :-P [17:48] a shorter form of the above.. http://stackoverflow.com/questions/1087227/validate-ssl-certificates-with-python [17:49] hazmat: yeah I saw that too while looking around.. I think therve took it from there. :) [17:49] hazmat: interesting to see that txaws has this implemented.. suggesting that we have to implement it too. :-/ [17:52] SpamapS, well.. its a dep.. we could just use it [17:55] hazmat: eeeevil! ;) [17:56] hazmat: but actually, since we're in ec2 provider land anyway.. hm.. maybe not so evil [17:57] hazmat: on osx we'll just get no certs.. [17:58] hazmat: shouldn't that also be causing fails when talking to EC2 though? [18:02] SpamapS, for the ec2 api endpoint we are doing cert validation by virtue of txaws.. [18:02] and hmm yeah.. that might be problematic on osx [18:02] * hazmat verifies [18:57] hmm.. bigger problem with ostack interuppted osx test [19:50] SpamapS, ping [19:51] SpamapS, i looked at https://bugs.launchpad.net/juju/+bug/915520 over the weekend [19:51] its not that big of a delta, but it ends up fundamentally reworking local provider [20:28]