[00:19] davecheney: :-) [00:19] davecheney: Are you using cobzr? [00:19] davecheney: It may help [00:20] davecheney: It's really boring to use GOPATH without it [00:33] Alright, calling a day I am [00:33] Have a good night/day all [00:34] niemeyer: yes, alias bzr=cobzr [00:35] will cobzr close (ie, remove from my local branch list) branches that have been submitted ? [06:38] morning [06:38] * davecheney waves [06:38] * TheMue waves back [06:38] i heard tell there is a pastebin for canonical [06:38] the public one [06:38] davArrived in the right timezone? ;) [06:39] yesterday was not pretty [06:39] davecheney: Yes [06:39] walked around like a zombie til 5pm [06:39] then gave in to the inevitable [06:39] http://paste.ubuntu.com/ [06:40] TheMue: http://paste.ubuntu.com/988455/ [06:40] davecheney: Funnily this time I had almost no problems. But I slept a lot during flight. [06:40] what do you think of that? [06:40] the logic is, watch /environment [06:41] get the *ConfigNode, pass config.Map() to this function, receive Environ [06:42] davecheney: Loks straight. [06:43] Looks [07:18] * davecheney shakes his fist at the interface{}'s being passed around everywhere [07:19] well, mainly inside environs/config.go [07:22] davecheney: Hehe, indeed, anonymous interfaces are always some kind of double-edged. [07:23] dummy.Open expect a schema.MapType, but ec2,Open expects a *providerConfig [07:24] I can't see a way to reconcile the two [07:24] apart from changing environProvider.ConfigCheck() to coerce everything to a map[string]interface{} [07:26] ohh, it's actually worse than that [07:31] davecheney: I hope Roger is around soon. This is his playground. [07:37] OK: 6 passed [07:37] i got it to pass, but it is really ugly [07:47] davecheney: Now that it's working it's time to make it elegant. ;) [07:50] in the face of interface{}, little can be done [07:52] but I think I pushed some of the nastyness out of sight [07:54] TheMue: https://codereview.appspot.com/6215045 [07:55] just checking it over before i send it out [08:07] halo rog [08:07] i'm just finishing up [08:07] check out https://codereview.appspot.com/6215045 [08:07] davecheney: hi there [08:07] davecheney: am very bleary! [08:07] took far too long (read most the day) [08:07] to produce that [08:07] * rog looks [08:07] but hopefully it's a faithful representation of what we discussed last week [08:08] davecheney: cool. [08:08] davecheney: what time of day is it for you? [08:08] 18:06 [08:08] so i'd better go and make the dinner [08:08] and tackle the mountain of washing up that sam left for me [08:09] rog: Heya [08:09] davecheney: ok :-) [08:09] TheMue: mornin' [08:09] davecheney: You got my comment. Mostly looks good. [08:10] davecheney: i thought we were going to use Setter/Getter or something like that [08:12] Open can't take a getter, the value of attributes is provider specific [08:12] it spent most the day bashing my head on that [08:12] ok, going afk for a few hours at least [08:12] davecheney: ok, have fun. [08:12] davecheney: washing up, yeah! [08:13] davecheney: BTW i was suggesting to pass a Getter to Check, not Open. [08:17] rog: Too late. (lol) [08:17] rog: Seen on the log that you yesterday asked for running Ubuntu in a VM. [08:17] TheMue: yeah [08:18] TheMue: was just wondering if my crash scenario was specific to me only... [08:18] rog: Oh, tell me more. [08:19] TheMue: ok, if you don't mind your VM crashing, try this: echo /dev/*/tun* [08:20] rog: Maybe later on a copy. ;) So you play around with the tunneling? [08:20] TheMue: yeah, but i couldn't get it working, and i don't know why. [08:20] TheMue: that was on the plane. [08:21] rog: That can't work. [08:21] TheMue: what can't work? [08:21] rog: Tunnels are below earth, not 10.000 feet above. (scnr) [08:21] :-) [08:22] rog: But what did you expect by echoing directly on the devices? [08:22] TheMue: i expected it to tell me what files were in /dev [08:23] TheMue: i ended up posting a stackoverflow question: http://stackoverflow.com/questions/10583601/how-should-the-tunattachfilter-ioctl-be-called [08:23] rog: Never used echo for it, only ls. [08:24] TheMue: you'd get the same behaviour if you passed the same argument to ls [08:24] TheMue: echo is nice because it prints all the names on one line [09:07] rog: attributes in config are always a map[string]interface{}? I already wondered about the usage of interface{} here. [09:08] TheMue: they only happen to be a map[string]interface{} if the yaml is written correctly. [09:08] rog: So I would define a type Attributes map[string]interface{} with setter/getter and Check(*EnvironChecker) (or something like that). [09:08] actually.... [09:08] i think they're usually map[interface{} [09:09] ] interface{} [09:09] TheMue: don't you like my Getter/Setter idea? [09:09] rog: Could live with that too, even if it's very generic. [09:09] rog: Get and Set on Checker? [09:10] TheMue: the idea is that you should be able to pass a *ConfigNode to EnvironProvider.Check [09:10] TheMue: you saw my comment, right? [09:10] rog: Only a quick look so far. [09:10] TheMue: https://codereview.appspot.com/6215045/diff/13/environs/open.go#newcode36 [09:13] rog: So your idea is to pass anything where you can "get" a value by key from as an input to the checker? Am I right? [09:13] TheMue: yes [09:13] rog: Sounds good. [09:14] TheMue: and it also works the other way around [09:14] rog: Yes [09:14] TheMue: an environ config can be saved directly to a config node [09:14] rog: So if it later will be something else and not the config node it's no problem. [09:14] TheMue: yes [09:14] +1 [09:15] cool [09:17] rog: Got this one http://shop.canonical.com/product_info.php?products_id=708 at UDS. Now here in the cold and wet Germany it's really useful. [09:18] TheMue: doesn't look like it'll keep out the rain much :-) [09:19] rog: No, but it keeps warm. Thankfully there's no rain inside my house. ;) And it's dry enough for the way to the car. [09:19] :-) [09:58] TheMue, rog: I *did* sleep well last night but I'm feeling the aggregate effect of too many weird days... taking a swap day today [09:58] fwereade: ok, good plan [09:58] fwereade: enjoy the day! [09:58] fwereade: OK, enjoy it. [09:58] rog, cheers :) [09:58] TheMue, cheers also :) [09:58] ;) === TheMue_ is now known as TheMue === rog is now known as Guest16956 === Guest16956 is now known as rogpeppe [13:51] Heya! [13:59] niemeyer: Heya. [14:15] TheMue: How're things? [14:16] niemeyer: Fine, just working on relations. And you? [14:17] niemeyer: yo! [14:18] TheMue: I'm waking up after a rough night where the jetlag ruled out, and getting on some reviewing [14:18] rogpeppe: Heya! [14:19] niemeyer: Yeah, adjusting the inner clock back is hard. And you've been there almost two weeks. [14:20] I have a 26 hour biological clock, it's terrible. [14:20] niemeyer: https://codereview.appspot.com/6145043/ is feeling a bit neglected :-) [14:21] rogpeppe: The whole queue is feeling neglected [14:21] niemeyer: i think that might be one of the older items... [14:22] rogpeppe: I'm sure some of them are older than the others :) [14:22] rogpeppe: My day will be pretty much just reviews today [14:23] Except for lunch and a meeting I have in about 1h [14:24] rogpeppe: Will do a quick pass on this one now.. hopefully we can get it in now [14:24] niemeyer: thanks! [14:26] rogpeppe: version.ToolsPath makes no sense to me [14:26] niemeyer: where do you think it should go? [14:26] niemeyer: i was duplicating it all over the place [14:27] rogpeppe: If anywhere, this should live within environs.ToolsPath [14:27] niemeyer: that could make sense. let me check. [14:27] rogpeppe: Although, maybe it should be a function instead, and let the implementation details off [14:28] rogpeppe: environs.GetTools(env) [14:30] Aram: Ouch :) [14:30] niemeyer: i'm not sure that's right [14:30] niemeyer: the tools path is independent of the provider [14:30] niemeyer: i think [14:31] niemeyer: otherwise we've documented the interface to PutFile wrong. [14:31] rogpeppe: Not sure I see what you mean.. environs is not environment-specific either [14:31] niemeyer: ah, so you'd have environs.PutTools too? [14:32] niemeyer: yeah, basically only once every 13 days I wake up when I should. All the other days I feel jet lagged. I compensate with caffeine, heh. [14:32] maybe that makes it worse. [14:32] rogpeppe: Don't we have that already? [14:33] niemeyer: UploadTools, yeah. [14:33] niemeyer: but without ToolsPath, it's difficult to test that the correct file has been written, because we don't know its name. [14:33] Aram: I bet it does indeed :) [14:34] rogpeppe: We only have to know its name once, in a single test [14:34] rogpeppe: If UploadTools works as it should, everything is else may rely on that [14:35] rogpeppe: We can test that DownloadTools (?) gets the same content that UploadTools supposedly uploaded, for example [14:35] rogpeppe: We don't have to test the path for that [14:35] niemeyer: i'm still not happy about cmd_test.go knowing about the underlying path name. [14:36] rogpeppe: I just pointed out that it doesn't have to..? [14:36] rogpeppe: I'm happy with PutTools and GetTools as well, btw [14:36] rogpeppe: Probably more sensible for GetFile/PutFile [14:37] niemeyer: yeah, i tend to agree [14:37] niemeyer: even though the flag is called --upload-tools [14:37] maybe it might be better named --put-tools in fact [14:37] rogpeppe: Yeah, that's fine.. the language on the command line has to be more sensible for the user instead [14:37] rogpeppe: --upload-tools feels more clear in that sense [14:37] niemeyer: ok [14:38] niemeyer: ok, i'll see how it goes without ToolsPath [14:38] rogpeppe: Thanks.. I'll be here for about 20 mins more before lunch [14:41] niemeyer: one thought: nothing is ever going to use GetTools except tests. [14:42] niemeyer: hmm, update will, i suppose. [14:42] rogpeppe: Curious.. I wonder what's the purpose of uploading a file we never download :-) [14:42] niemeyer: we use wget and tar... [14:42] rogpeppe: That's done for bootstrap only [14:42] niemeyer: when else do we download tools? [14:43] niemeyer: update will, i think, so i think it seems ok to me. [14:43] rogpeppe: Yep [14:43] rogpeppe: Whenever we have Go code running that wants to download tools [14:44] rogpeppe: Updating has to do that [14:44] niemeyer: yeah [14:44] niemeyer: i'll still need to verify against tar xz though [14:44] rogpeppe: Yeah, once, though [14:48] oh darn [14:48] niemeyer: GetTools won't work without support for ListFiles in Environ [14:48] niemeyer: and even that's not quite there, as we've got a two-tier system. [14:50] rogpeppe: I don't understand how we can have ToolsPath in version and can't have a function instead [14:50] niemeyer: because GetTools doesn't get a particular version - it searches for the latest appropriate version. [14:50] rogpeppe: So ToolsPath is equally bogus [14:50] niemeyer: ToolsPath gives the path for the *current* tools. that's why i put it in version. [14:51] rogpeppe: Ugh.. that's not great [14:51] rogpeppe: Let's have ListFiles in the environment then, and have GetTools [14:52] niemeyer: we'll need two ListFiles-type functions (or one with a bool arg) because we need to be able to look in private storage first before failing over to public storage. [14:53] niemeyer: perhaps ListFiles(private bool) ([]string, error) [14:53] rogpeppe: That sounds like yet another great reason to have GetTools.. this is unrelated to ListFiles in the environment [14:53] niemeyer: really? [14:53] niemeyer: which bucket would ListFiles list? [14:53] rogpeppe: Well, maybe it could be.. thinking [14:54] rogpeppe: ListFiles should list the files in the environment [14:54] rogpeppe: That has a very well defined meaning [14:54] niemeyer: so how do we list the files in the public bucket so we can use publicly uploaded tools? [14:54] rogpeppe: Which is in theory unrelated to anything about how-do-I-get-public-tools [14:55] rogpeppe: That's a good question for which we need a good answer.. it doesn't invalidate the former point, though [14:55] niemeyer: the environment knows about both, so i'd put that logic into the environment. if it's not in the environment, then we need some way of extracting info about the public bucket from it [14:56] s/i'd/i/ [14:56] rogpeppe: Please explain "the environment knows about both" [14:56] niemeyer: the names for both the private and public buckets are stored in environments.yaml [14:57] niemeyer: and they're environment-specific [14:57] rogpeppe: You're putting statements as if they were true as you go, but it feels to me like the implementation of these details is actually still undefined [14:58] niemeyer: ok. i'm happy to refactor. [14:58] rogpeppe: It is not true that the public files are environment-specific, for instance [14:58] niemeyer: i'm not sure how we'd specify mutable storage in a provider-independent way though. [14:59] rogpeppe: All the environments for a given provider, or even for multiple providers, may share files [14:59] niemeyer: oh, is the list-bucket functionality provider-independent? [14:59] rogpeppe: It is also not necessarily true that they are stored in environments.yaml either [14:59] rogpeppe: Since we'll have defaults [15:00] rogpeppe: It may be.. and it doesn't even have to be a bucket, for example [15:00] niemeyer: what we need is some generic "container-like" functionality, i think [15:01] niemeyer: if we want to go in this direction [15:01] rogpeppe: I think we can actually have an interface that defines a public-files thingy (name to be defined), and have a HTTP(S) consumer implementation for that [15:02] rogpeppe: I *suspect* we can use that single implementation with every provider we know about so far [15:02] * rogpeppe doesn't know about anything other than s3 [15:02] rogpeppe: Then, we can have a env.PublicFilesThingy() or similar [15:03] rogpeppe: Which in pretty much all cases does [15:03] niemeyer: and PrivateFilesThing() ? [15:03] rogpeppe: I suspect the env itself is a PrivateFilesThing [15:03] ew [15:04] niemeyer: that seems a little icky [15:05] niemeyer: i'm not sure why PublicFiles and PrivateFiles wouldn't be symmetrical [15:05] rogpeppe: env.PublicFilesThingy() will return TheBasicHTTPPublicFilesThingy(defaultURL or configURL) for pretty much all providers [15:05] rogpeppe: Because they are not in real life.. the environment manages storage of its own files.. the public files is managed by someone else [15:05] rogpeppe: There's nothing icky about that to me [15:06] rogpeppe: Although, I'm fine to have PrivateFilesThingy if you prefer that [15:06] niemeyer: i'll think about it. [15:06] rogpeppe: It sounds sane to me as well [15:06] Environ.Files vs Environ.PublicFiles ? [15:07] niemeyer: then the file interface can be simply be: interface {Put(...) error; Get(...) error; List( ...) ([]string, error)} [15:07] niemeyer: because we won't need to disambiguate [15:08] rogpeppe: I'm happy with that.. feels very clean [15:08] niemeyer: i'll see how it looks [15:08] rogpeppe: Happy with PrivateFilesThing too [15:08] rogpeppe: Btw, we need a name :) [15:08] rogpeppe: I'll have lunch, and try to come up with some suggestions [15:08] niemeyer: Storage? [15:08] niemeyer: ok, enjoy [15:08] ! [15:09] rogpeppe: Sounds great [15:09] * niemeyer => lunch [16:13] * niemeyer_ is back [16:13] rogpeppe: How does it feel? [16:14] niemeyer_: it's looking quite nice [16:14] niemeyer_: http://paste.ubuntu.com/989159/ [16:14] niemeyer_: it feels like another piece of the puzzle has dropped into place [16:16] niemeyer_: what do you think? [16:18] * niemeyer_ reads [16:19] rogpeppe: Looks very good indeed [16:19] rogpeppe: A couple of suggestions: [16:19] niemeyer_: cool. [16:19] rogpeppe: Let's not get into the S3 prefix madness [16:19] rogpeppe: Let's call it a dir [16:20] niemeyer_: ok. i started with that. [16:20] niemeyer_: but it's hard to do proper dirs with s3 [16:20] rogpeppe: I thougth it was trivial? [16:20] niemeyer_: List(prefix="e", separator="/") will return "elephant" AFAIR [16:21] (if "elephant" exists, of course) [16:21] rogpeppe: What will "e/" return? [16:21] niemeyer_: good point - just always append a / [16:22] rogpeppe: The only reason to not do that would be efficiency I guess [16:22] rogpeppe: In the sense we could list precisely what we want, if possible [16:22] rogpeppe: This might be enough of a reason to implement the prefix-based stuff [16:22] niemeyer_: if we know precisely what we want, then why are we doing a LIST? [16:22] rogpeppe: "foo-* [16:23] niemeyer_: i don't think we should worry. [16:23] niemeyer_: we're not going to have *that* many versions. [16:23] niemeyer_: and if we do, we can partition the dirs [16:23] rogpeppe: It may be useful to avoid returning 100s of tools from the public storage, actually [16:23] rogpeppe: tools-.* [16:24] niemeyer_: in which case, why not make tools- a directory? [16:24] niemeyer_: as you said, the S3 prefix stuff is madness [16:25] rogpeppe: Well, we can make it saner.. we'd not support varied separators, or distinguish common prefixes in separate lists [16:25] niemeyer_: not quite whether to go for "/" or "" as the root directory. [16:25] niemeyer_: i don't see the need for the abstraction - you've persuaded me. prefix might not be as easy to implement in other providers [16:25] niemeyer_: directories are sufficient [16:25] rogpeppe: I can't see how that would possibly be the case [16:26] niemeyer_: if the provider actually uses a directory-like structure, prefix matching will be harder to do efficiently. [16:26] niemeyer_: (we'd need to do it client-side) [16:27] rogpeppe: Anywhere we can list a directory, we can filter it out with three lines (for+if+append) [16:27] niemeyer_: exactly. but then we'll be getting the inefficiency we're trying to remove by using the prefix abstraction. [16:27] niemeyer_: and using a directory will be the same efficiency in both cases. [16:27] rogpeppe: We'll be getting the inefficiency you're suggesting we'd have all the time [16:28] rogpeppe: Yes, the same *inefficiency* in both cases.. [16:28] niemeyer_: not if we store tools as tools-$MAJOR/$MINOR-$PATCH.tgz [16:28] rogpeppe: Which means filtering it out by hand, client side, in both cases.. [16:28] rogpeppe: Not sure about what you're arguing for, to be honest [16:28] the above [16:29] niemeyer_: note the "/" between major and minor versions [16:29] niemeyer_: then we can just List("tools-$MAJOR") [16:29] rogpeppe: Ok, but this naming isn't great [16:30] niemeyer_: no? [16:30] rogpeppe: "tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz" then [16:30] niemeyer_: why does it need to have the same pattern on the provider as on disk? [16:30] rogpeppe: Because I don't want to wget 1.2.tar.gz [16:31] wget tools/2/1.2.tgz seems ok to me. [16:31] rogpeppe: Sorry, 1.2.tar.gz isn't a proper file name [16:32] niemeyer_: but anyway, all this is premature optimisation - we can change it all later trivially. [16:32] niemeyer_: i think we've shown that we don't need prefix matching to do this efficiently [16:32] niemeyer_: and i'm ok with the redundant major version too [16:33] niemeyer_: by the time we've got hundreds of versions, we'll have upgrade and we can change the schema on the fly :-) [16:33] rogpeppe: No, let's do it now please.. the need is obvious, the implementation trivial [16:34] rogpeppe: You can pick either.. tools/tools-$MAJOR.$MINOR.PATCH.tar.gz + prefix tools/$MAJOR/tools-$MAJOR.$MINOR.$PATCH.tar.gz + dir [16:34] niemeyer_: ok. [16:34] niemeyer_: i vote for the latter. [16:35] rogpeppe: Cool, let's go with it then [16:37] niemeyer_: any other suggestions? === niemeyer__ is now known as niemeyer [17:01] right, off for the day. see y'all tomorrow. [17:05] What the heck [17:06] Google+ Hangout has f* up my connection permanently.. [17:06] I had to reboot and reconnect the router.. [17:07] I wonder if the Hangout servers are DoSing me somehow [17:10] I wonder if he had the 'DoS me' option enabled in Advance pref's? [17:20] hi guys, niemeyer tells me his internet is down for good [17:21] hazmat, jimbaker, others: ^^^ [17:22] ahasenack, thanks for relaying [17:22] hazmat: 3g is also down, not just adsl, so it must be something more serious in that region [17:23] indeed, that's uncommon [17:23] interesting [17:24] Okay [17:24] Something funky is happening with the local ISPs [17:24] Managed to get in via 3G now [17:25] maybe everybody is playing diablo 3 ;) [17:25] ahasenack: That might explain it [17:27] niemeyer: Who may be interested in a possible bug in relation.py in the current implementation? [17:27] TheMue: Ben, Jim, or Kapil [17:27] TheMue: Everybody would be *interested* though, but one of them will have to look at the code [17:28] niemeyer: I'm not sure if it's a bug, but I think it's worth a look. [17:28] jimbaker: Still around? [17:31] TheMue, what's up? [17:32] hazmat: Ah, heya. [17:32] hazmat: Please take a look at relation.py at line 91. [17:34] TheMue, yeah.. thats suspect its only checking one endpoint [17:34] hazmat: I think service_id has to be service_relation.internal_service_id(). [17:34] hazmat: Yep, that's what I thought. Especially inside the loop. [17:35] TheMue, it should be service_relation.service_id [17:35] er. internal_service_id [17:35] hazmat: The service id is stored in _service_id. So you have to use the accessor. [17:35] hazmat: Yeah [17:36] TheMue, still around, but looks like hazmat has got you covered [17:36] jimbaker: Heya. Yes, hes has. ;) Thx. [17:37] bzr blame suggests otherwise ;-) [17:38] jimbaker, trivial http://paste.ubuntu.com/989322/ [17:40] hazmat, looks like a check to ensure we are not seeing inconsistent topology. iirc this was a bug fix to fix looping tests [17:40] jimbaker, it looks it was part of the initial impl [17:41] jimbaker, updated trivial w/ test http://paste.ubuntu.com/989333/ [17:44] jimbaker, okay.. given lack of objections.. adding to trunk.. the failure without the change is InternalTopo..Error instead of StateChanged [17:44] hazmat, ok, got context - it just looked like all the other checks we have added to avoid InternalTopologyError, so along the same lines [17:44] hazmat, +1 [17:46] thanks TheMue [17:47] rogpeppe: ping [17:48] hazmat: np, happy to help [18:08] mthaddon: ping [19:03] So, I'm off. Good night. [19:06] * hazmat meanders off for food [20:39] do you guys have any intention of implementing an api for juju? [20:58] flaviamissi, definitely [21:12] flaviamissi, there's a very rough draft extant in http://bazaar.launchpad.net/~hazmat/juju/rest-api-spec/files/head:/source/drafts/ [21:33] hazmat: great! it would be very useful, I'll take a look at it, maybe I can help on that [21:34] flaviamissi, great, comments welcome, its basically in three parts, a REST api, an HTTP command api corresponding to the CLI, and websocket notification mechanism. [21:37] hazmat: yeah, I'm reading the spec now, is anyone working on that? [21:39] flaviamissi, there's an experimental branch that someone through together, but its probably not going in as is. there's some drive to have this done for 12.10 to support other activities though. [21:40] flaviamissi, the experiment is attached to https://bugs.launchpad.net/juju/+bug/804284 [21:41] hazmat: great, thank you [21:41] flaviamissi, that's a client side rest api though.. [21:42] ie. its not deployed as part of juju [21:43] hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju? [21:43] flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet [21:43] hazmat: ok [21:44] hazmat: that's for the python version, right? [21:44] flaviamissi, it is [21:45] flaviamissi, at this point feedback on the spec would be the most helpful, ie. making sure we're covering appropriate use cases and functionality [21:45] hazmat: I can do that [21:45] negronjl, where would you want to take jrapi? [21:48] 'sup 'sup [21:52] hazmat: what do you mean ? [21:54] hazmat: If it serves a purpose, let's use it. If anyone comes up with something better, we can use that ... [21:54] hazmat: but, until something better shows up, I am playing with jrapi [21:56] negronjl, sure, but trying to figure out where it goes from here.. ie do we evolve it add tests, match it to spec and try to merge it, or do we end up with a separate official project that gets merged. [21:57] hazmat: the spec looks really good, looks like all cases are covered, but I'll take another look later === niemeyer__ is now known as niemeyer [22:01] flaviamissi: There was some mixup there.. [22:02] <flaviamissi> hazmat: hmm... but this is the intention? I mean, the api won't be deployed as part of juju? [22:02] <hazmat> flaviamissi, yes that's the goal.. like i said that branch is experimental.. its not clear its the basis for an official rest api yet [22:02] flaviamissi: hazmat intended to say that, yes the goal is to have the API deployed as part of juju [22:03] niemeyer: hmmm [22:03] niemeyer: that makes more sense to me :) [22:03] flaviamissi: It's one of the next major features that will come [22:03] flaviamissi: After the port is done [22:04] niemeyer: so, the plan is not have the api for the python version? [22:05] flaviamissi: Yes, Python is in maintenance mode, and we're working on getting the port done in time for 12.10 [22:05] niemeyer: great [22:06] I'm leaving, we chat more later [22:07] * niemeyer => dinner too [22:11] niemeyer, doh.. yeah.. totally it should be deployed as part of juju [22:11] that was unclear [22:11] async response communication fail [22:26] hazmat: Can you make the spec available to me? [22:26] hazmat: I'm up for using this API of course but, the final decision on that I believe it to be yours [22:27]