[02:03] thumper: if you have a moment, i'd love a review on https://codereview.appspot.com/16550046/ so i can land it for curtis. no real hurry or anything [02:13] * thumper looks at wallyworld_'s work [02:13] \o/ thanks [02:20] wallyworld_: I suggest we skip the package review today [02:20] nothing has been suggested and axwalk isn't around [02:20] sounds good to me [02:20] cool [02:20] * thumper goes back to writing emails [02:21] thanks for review [02:21] np [02:21] sometimes I feel that if I don't suggest anything, you'll think I didn't read it [02:36] hi guys.. a quick question... [02:36] maybe not so quick. [02:37] I had a juju debug-hooks session going before I left the office. [02:37] That session got killed somehow. When I tried to start a new debug-hooks session from home, juju complains with the following error: [02:38] duplicate session: nova-cloud-controller/0 [02:38] Connection to m1basic-07.vm.draco.metal.as closed. [02:38] ERROR exit status 1 [02:38] is there a way to reset that status (possibly without reboot) ? [02:39] sodre, you can login into the machine and kill the tmux session or reattach [02:39] that was my first thought :) [02:39] tmux list-sessions shows nothing? [02:40] aha... :) my bad. I looked for byobu. [02:40] okay.. now I'm back! Thanks hazmat! [02:41] np [03:09] thumper: are you dealing with vlan stuff on the juju side? [03:09] I have a vague plan of how I want to do this and need to talk to you guys [03:17] bigjools, vlans as tag constraints or something more intrisinic? [03:17] afaicr part of the issue is that provider specific tags are all exposed globally atm [03:17] with something more intrinsic and specific to maas [03:18] though i guess could just continue to stick more one use globals on. [03:18] hazmat: it's all up for discussion. I don't necessarily like tags being used for everything. Not sure it'll work here either. [03:18] guys, is there a good starting point for deploying juju on a Private openstack install? I am having trouble with juju bootstrap [03:18] hazmat: point is - nodes may be on multiple vlans and juju can ask for a specific vlan [03:18] bigjools, you can allocate a machine on multiple vlans? [03:18] gotcha [03:19] hazmat: only if the machine has multiple network interfaces [03:19] sodre, let's switch out to #juju and pastebin your $ juju bootstrap -v --debug [03:19] got it [03:19] sodre, likely its an issue around syncing tools (juju sync-tools).. [03:19] could be. [03:20] bigjools, right, but its a possibility, why would tags be a bad match here outside of the reuse of the semantic .. the and logic seems similiar [03:21] hazmat: it could work for sure, we just need to discuss options and see if that is indeed the right way. I hate to jump on the first idea that comes up :) [03:23] fair enough [03:23] * bigjools lunches [03:25] thumper, kinda of cool albeit not working, local provider and add-machine --to=lxc:1 ... the sub container doesn't seem to be functional sadly. [03:26] er.. not really create it appears [03:46] any openstack/goose devs around? [03:55] hazmat: agreed, we don't support nested containers yet [03:56] bigjools: not sure who will be dealing with it yet [03:56] bigjools: we have to deliver a big hunk of stuff prior to network aware juju [03:56] bigjools: but I do have a big picture understanding of it [03:57] hazmat: please stop telling people to use "-v", if using --debug, verbose is implied [03:57] really need some keyword calls for help here.. sodre is on #juju but having some issues getting a private openstack installation going .. looks like tool and image metadata issues.. but also notable as an annoyance is the upload of 34mb of tools every bootstrap and the failure of sync-tools [03:57] thumper, sorry habbit [03:57] :) [04:00] thumper: ok thanks [04:00] * thumper looks at wallyworld_ for synctools problems that hazmat is watching someone have [04:00] hmmm? [04:01] k, /me read #juju [04:01] wallyworld_, http://pastebin.com/t0H8DVVG [04:02] wallyworld_, why is it doing uploads like that every bootstrap? [04:04] hazmat: it uploads when it can't find tools [04:05] iow it does a --upload-tools for you [04:05] so the user doesn't have to type it [04:05] wallyworld_, sure but every bootstrap? [04:05] but if tools are there, it won't upload anything [04:05] only if tools are missing [04:05] once set up correctly, it won't do it [04:05] umm.. he's done multiple bootstraps.. that's just his most recent run [04:06] in that case, theres a problem finding tools [04:06] yeah.. [04:06] otherwise it wouldn't upload [04:06] wallyworld_, interestingly sync-tools through an error.. http://pastebin.com/BJJUrasS [04:06] wallyworld_, way past EOD here.. hopefully you can help him out.. going to try and finish up some ODS demo work. [04:07] huh, never seen that eror before [04:07] ok, no problem [04:07] thanks for helping [04:21] wallyworld_: I'm off for a run, but the "invalid literal t" stuff looks like a bug in goose, search for something about json marshalling [04:21] specificalyl, we make a list request [04:21] and expect to get JSON back [04:22] but end up getting just a plain listing [04:22] which doesn't JSON.Unmarshal well [04:23] oh, ok [05:37] rvba: can you think of why the response to Azure's GetOSImages would get truncated inside the Go code? curl works ok. [05:38] rvba: wallyworld_ is debugging and it only reads ~16k of a 159k response [05:39] bigjools: sounds fishy… I don't recall seeing that… let me have a quick look at the code and see if anything comes back… [05:39] i blame ms... or go [05:39] rvba: sounds a lot like an File.Read() rather than ioutil.ReadAll() [05:40] jam: ioutil.ReadAll() fails the same way, so i have done my own read loop to try and see where it gets to [05:41] wallyworld_: I wonder if it is getting something like EINTR and not retrying [05:41] jam: could be. all i know is that reading from response.Body fails [05:41] it is expecting 160kb response (which is absurd in itself but that's another story) [05:42] wallyworld_: sure. I haven't seen it myself, I just know that it is easy to do a object.Read() when you actually want ioutil.ReadAll() [05:42] but the connection is closed after reading 16k [05:42] wallyworld_: there can certainly be a lot of OS Images ... [05:42] jam: have you seen the xml. sooooo verbose [05:42] all sorts of crap in there besides image details [05:46] wallyworld_: could this be related somehow to the change made in revision 226? (the "request.Close = true" thingy)? [05:46] rvba: no, that change would have improve the situation if anything afaik [05:46] cause it would have stopped go from reusing connections which may have been closed [05:47] I see. [05:56] time to pick up the kid from school. will have to continue debugging when i get back [08:30] mornin' all [10:07] morning all [10:08] mornin' [10:14] mgz, did we change the standup time to be 1h earlier? or my tz is wrong again in the calendar [10:15] hm, we just switched to summer time [10:17] so, I think it should have moved an hour forwards for both of us [10:19] what's your local time now? [10:19] 10:20 [10:20] hmm, so the clock seems right [10:20] but on the calendar I can see the standup at 11:45, whereas before it was at 12:45 [10:21] right, I think the event is pinned on gmt, so, moves an hour with summer time ending [10:21] rvba: you around? [10:21] wallyworld: yep [10:22] rvba: running the azure test example utility, any idea why i get "The versioning header is not specified or was specified incorrectly" [10:22] gwacl/example/management/run.go [10:23] i had to hack out the retrier to stop the network connection close issue [10:23] wallyworld: hum, IIRC it should "just work", let me have a look. [10:23] wallyworld: what did you have to do? [10:23] instead of using the retrier: retrier := session.retryPolicy.getForkedHttpRetrier(session.client) [10:24] i just did a session.client.Do(req) directly [10:24] that allows the images to be listed ok [10:24] Weird. [10:24] there's a separate issue with the conection getting closed [10:24] so that hack just gets past that bit [10:25] i think there may be a real issue with the header version [10:25] since juju bootstrap also fails with that error on azure all of a sudden [10:25] Maybe the version we use is not supported anymore… [10:25] That would be weird… but anything is possible. [10:25] yeah, maybe [10:25] thanks for looking :-) [10:25] I'm still looking :) [10:26] so we use "x-ms-version", "2013-03-01" [10:26] is that the header it is refering to? [10:26] Yes [10:26] ok, maybe there's anew one? where do we look to find out? [10:27] mgz, dimitern: Generally we've left the meeting at GMT so that when we have 5 different daylight switchover times triggering asynchronously we don't have to bump it around. But we can discuss changing the time if it works better for people. [10:27] Somewhere in the documentation. But the point of using version headers like this is exactly to avoid trouble when the API changes :). [10:27] My guess is that when Nate changes TZ in a couple weeks we might all want to move earlier [10:27] yeah, i would have thought so too [10:27] but we'll have to check with wallyworld if that is going to work [10:28] might work :-) [10:28] wallyworld: don't you switch on to daylight savings time? or is Queensland DST agnostic [10:28] sadly QLD is retarded. no DST here :-( [10:29] http://msdn.microsoft.com/en-us/library/windowsazure/gg592580.aspx says "2013-03-01" is still the most recent version. [10:29] hmmm. [10:29] maybe there's an azure bug [10:29] jam, nah, it's alright I just have to remember it's 1h later [10:29] rvba: it also says "last updated November 19, 2012" [10:29] jam: indeed :) [10:29] so are we using git now? [10:29] Let me try to run the example script… [10:30] dimitern: not as in "today we commit with git" but as in "we'll be working on migrating now" [10:30] rvba: ok. let me know if you have to hack out the retrier [10:30] jam, i see [10:30] I'm trying to decide my personal involvement. [10:30] rvba: my command line was: go run -a run.go -cert=/home/ian/.juju/azure.pem -location="West US" -subscriptionid="" -pause=true [10:30] it would be useful to have a "crash course" comparison between common bzr and git commands [10:30] dimitern: http://www.git-tower.com/blog/git-cheat-sheet-detail/ [10:31] jam, cheers [10:31] wallyworld: ta [10:31] dimitern: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html is the reverse [10:31] but it probably has the correlations [10:31] jam: i had a quick look at git today - it is weird. git pull doesn't actually update your branch [10:31] and you get the whole repo whether you want it or not [10:32] wallyworld: so git has a concept of a bunch of local branches that track remote branches [10:32] wallyworld: and it doesn't support remote ops like "log" [10:32] so you *have* to pull locally [10:32] to be able to see the history [10:32] :-( [10:32] wallyworld: and under that circumstance, it doesn't make sense to always merged [10:32] merge [10:32] and you need to checkout after pull to see the changes? [10:32] wallyworld: "git merge" will also "fast forward" like "bzr pull' unless you pass "--no-ff" or configure it to disable that. [10:32] wallyworld: well, you can "git log" locally [10:33] there is probably a "bzr cat" equivalent. [10:33] wallyworld: the command just hangs, no output, no nothing :/ [10:33] i wonder how to set up a lightwieght checkout scenario [10:33] rvba: really? hmmmm [10:33] Oh wait, it crashed after a while [10:33] so nothing in git like qbzr? [10:33] wallyworld: each "git repository" is a working tree + repository + multiple branches [10:34] With "The versioning header is not specified or was specified incorrectly." [10:34] so you generally just have a repo and switch between the branches in there [10:34] essentially the colocated version of bzr by default [10:34] rvba: right, that's what i see, except i have the conn closed issue too [10:34] Gosh, what a mess. [10:34] yeah :-( [10:34] morning all [10:35] wallyworld: I know it is possible to play with ENV args like GIT_REPO to allow you to say the history is "over there". And I've seen comments about other bits of sharing histories between working trees. [10:35] wallyworld: but AFAICT the *common* behavior is that you have just one tree that you switch between branches and they all share the same repo [10:35] jam: ok. seems like we need to work out best practice for bzr refugees [10:36] from what i understand, seems like a shame though it forces you to get the *whole* repo [10:36] wallyworld: well, you close/archive/rename branches when you don't need them anymore [10:36] just like in bzr, they are just pointers into the revision graph, so they are "cheap" [10:36] (gits actual objects are cheaper than bzr's because of extra files bzr keeps around for each branch) [10:37] but unlike bzr, you get the whole repo and potentially waste lots of disk space if there are lots of blos etc [10:37] i wonder if that can be avoided [10:37] wallyworld: bzr pull gets the whole history [10:37] not sure what you mean about waste [10:37] for that branch [10:37] easier to explain verbally :-) [10:37] wallyworld: so again, usually you would work in the same "working tree" and just pull the branches next to yours [10:38] right. but i was told if you get a working tree, you also get all other working tree for all other branches in the repo regardless if you want them or not [10:39] wallyworld: "git clone" defaults to hardlinking the archive [10:39] wallyworld: yes, you do. But you generally wouldn't check out multiple copies of the same project [10:39] wallyworld: no other working trees [10:39] just branch pointers [10:39] right. but if a repo contains project foo and project bar and you just want foo, you are forced to get bar too [10:40] i was hoping to avoid that [10:40] wallyworld: yes, well, don't put two projects in the same repo :/ [10:40] ok. seems like many people do though. let's hope we don't [10:40] wallyworld: sure. though as nate says, they don't generally share repositories for projects that don't share ancestry. [10:40] wallyworld: there is "git clone --shared" [10:40] and --local, --bare, --mirror [10:40] i'm just going y what i've read/seen [10:40] and shallow clones with --depth [10:40] and [10:41] --separate-git-dir [10:41] wallyworld: what was the symptom of the other issue? "panic: use of closed network connection"? [10:41] wallyworld: so you can probably do whatever the fsck you want [10:41] rvba: yes [10:41] jam: great :-) [10:41] jam: still trying to grok the best approach to suit my workflow [10:41] jam, wallyworld : except most of the time it's best to just get the whole repo and switch branches as you need to. That actually works perfectly with Gopath, that assumes one spot on your hard drive for a project [10:42] wallyworld: though as you mention, clone copies all branches by default, so mixed project repositories will generally cause clone to copy multiple ancestries. In *git's* world view there is just one global ancestry that happens to have disjoint pieces [10:42] Oh wait, it crashed after a while [10:42] wallyworld: I don't see it with revision 225. With revision 226, I get that "use of closed network connection" error: http://paste.ubuntu.com/6329291/ [10:42] natefinch: to be fair, the gopath model is particularly bad, so I'm not super keen that another tool does it, too :) [10:43] rvba: that is interesting indeed [10:43] natefinch: prior to this, I always had 3 checkouts of a project I was working on. 1 was pristine trunk, 1 was the thing I was actively working on, and 1 was for code review that came back that needed tweaks without wanting to interrupt my current work [10:43] rvba: there's another way to try and work around Go's braindead http issue. i might try that [10:43] natefinch: it is nice to be able to just fire up your text editor to see how it was done in trunk [10:44] jam: you can still do that. They're just different branches, and switching between them is super fast in git [10:44] rvba: so that still leaves the versioning issue :-( [10:44] natefinch: it is fast in bzr, too, it is *still* nice to not step on what I'm working on to see what it is like in another branch [10:44] natefinch: note that I said *3* not N for all the branches I work on. [10:44] wallyworld: yep. Let's see if the request looks sane. [10:45] anyway, stand up time for those who are joining [10:45] https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig [10:45] rogpeppe, dimitern, wallyworld, natefinch: ^^ [10:45] mgz: ^^ [10:45] ta [10:45] rvba: thanks so much for looking. i'll check back after our standup [10:45] so it is 1h earlier then [10:45] wallyworld: np [10:53] sinzui: not sure if you are online. if you are, i have some info for you [11:03] wallyworld: it's the deletion of the affinity group request that fails… [11:03] rvba: ok. do we do that during bootstrap also? [11:04] wallyworld: probably not [11:04] bootstrap fails with the "same" error [11:04] well, it did for me and curtis [11:05] wallyworld: well, maybe bootstrap does something similar (for some definition of "similar") [11:05] likely [11:05] i wonder why that particular api call fails [11:05] wallyworld: it would be worth knowing which API call fails exactly when running bootstrap. [11:05] Might help us pinpoint the problem. [11:06] Because the request seems okay to me, the api header is set. [11:06] rvba: i'll try and find out. but likely not tonight. too tired [11:06] rvba: unless ms changed something at their end? [11:06] wrt versioning? [11:07] nothing would surprise me [11:07] wallyworld: I tried using another version for that request, no dice [11:07] sigh [11:07] it shouldn't be this hard :-( [11:34] natefinch: just wanted to poke, you'll be going of DST in another couple weeks, right? Is that going to impact you for the standup? [11:35] wallyworld: Replacing the ginger beer with ginger wine leads to a particularly lethal drink known as a Turbo Dark 'N' Stormy; a favourite tipple of Pembroke College Boat Club (Oxford) [11:35] * wallyworld makes a note to try that tomorrow [11:35] jam: yeah, I was going to bring that up. The current standup time will soon be 5:45am for me, which is somewhat less than awesome [11:35] natefinch: sounds pretty awesome for us. You were complaining that your daughter was waking up before you [11:36] this way we get focused Nate time :) [11:36] jam: ha yeah [11:36] natefinch: so what time will work for you? [11:37] jam: we could do a half hour earlier, that would be 6:15 my time, whcih is enough time for me to get up and make coffee, which is really all I need before the standup :) Depends on what works for other people [11:37] 'earlier' ? [11:37] er later [11:38] i'll be totally drunk by then :-) [11:38] wallyworld: not sure if that's a problem :) [11:38] that's 21:15 for me, but should work [11:38] jam: yeah, how would you know the difference, right? [11:39] wallyworld: whmaobaou whaoeu baoeuwhaoeunwhou, might give it away [11:39] maybe :-) [11:39] wallyworld: though, I guess when you got tipsy in SFO you didn't seem to mumble [11:40] i only had a couple of drinks, i'm not a 2 pot screamer :-) [11:40] hmmm. do you know what a 2 pot screamer is in the US? [11:40] maybe that's an australian expression [11:41] a "pot" in australia is a standard 285ml glass of beer [11:41] wallyworld: never heard of a 2 pot screamer [11:41] maybe it makes sense now that i've explained what a "pot" is ? [11:42] wallyworld: I inferred what it meant from context :) [11:42] wallyworld: essentially a "cheap date" :) [11:42] yeah :-) [11:42] natefinch: so if we chip in to buy you a coffee maker with built in grinder and timer we can keep the current time ? :) [11:42] jam: sure, but I get to pick the model ;) [11:42] i don't mind if it is later [11:42] natefinch: I think we can probably move it by 30min. It may mean that I get interrupted more when my son gets home, but I think we can work it out. [11:43] natefinch: my wife and I had one, the main problem we had was that because the grinder is exposed (to let the grinds into the brewing section), it was *really* loud, and the grinding area needed to be cleaned after every run because the steam would get in there and you end up with soggy grounds [11:43] jam: we can give it a try and change things if it's not working. 5:45 is less of a horrible time for me than most people I think. [11:44] natefinch: sure, though it is the *daily* standup ,so I'd like to be at a reasonable time as much as possible [11:45] jam: we could also move it even later, though that would probably mean Ian can't go [11:45] natefinch: so we should definitely do it, you say ? :) [11:46] jam: haha... it would mean about 50% less whining during the standup ;) [11:47] he doesn't drink that much wine [12:55] interesting - https://github.com/juju [13:02] Thank you for the email wallyworld [13:30] jam, awesome stuff re scale testing.. have always enjoyed these write ups (+maas, +bzr back in the day) [13:44] one curious bit was the 5s pump on the unit agent api for watch events, was wondering where that came from [13:45] the all watcher client impl has something similiar but thats based on a periodic update and push, is that the same behavior/impl for the agent api? [13:53] Hi devs, we have a critical bug in progress that I want you all to be aware of. Any insight into this issue will be appreciated. I currently think this issue is more than just blocking my 1.16.1 release, I think it is a bug that needs fixing for 1.16.1: https://bugs.launchpad.net/juju-core/+bug/1246320 [13:53] <_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified

[14:05] lunch [14:10] hazmat: all watchers use the same underlying poller (implemented by the state/watcher package) [14:15] sinzui, this might sound like an odd question but the 1.16.1 release will just be juju-core changes right? [14:15] not a re-sync of trunk of deps as well [14:19] jamespage, https://launchpad.net/juju-core/+milestone/1.16.1is just bug fixes that are not entangled with other libraries. The fixes were backported from trunk [14:20] sinzui, goody [14:20] just making sure [14:20] sinzui, dependency management needs to be a key focus for 14.04 if we want to get juju-core into main [14:22] jamespage, understood. [14:31] sinzui, I'm going to take a look at the state of the golang tooling for packaging early in cycle [14:31] if its good enough I'd like to push out dependencies into their own packages [14:46] jamespage, I am considering releases doe gwacl, goose, and gomaasapi. Would you want them as packages in 14.04? [14:50] sinzui, jamespage: I would find it odd to have random Go packages as packages for apt-get. They're basically useless on their own, and don't represent an actual usable application, unlike juju-core. But maybe I'm misunderstanding what's being proposed. [14:52] natefinch, it is odd. We tend to bend things like java to debian package management. debian maven for example strives to collect java libs in a tree that is shared for debian package management [14:53] natefinch, I don't know the right path for go, but since it can wrap c libs, it cannot assume all packages are the same [14:54] sinzui, not yet [14:55] PS I had zero success with debian and maven for 13.04 and don't want to try anything like that again [14:58] mgz, if you have some time today could you take a look at the merge request @ https://code.launchpad.net/~dstroppa/juju-core/add-joyent-provider/+merge/189360 [14:59] mgz, or possibly get it to the correct person for review [15:01] arosales: sure, that sounds reasonable [15:01] ah, whoops, I fixed bug 1243861 but didn't link the bug [15:01] <_mup_> Bug #1243861: juju should add the cloud-archive repository differently [15:02] mgz, thank you sir [15:02] ah, it's an ubuntu bug, that's why I missed it [15:03] mgz, we have a fix for that bug going in 1.17 ? [15:03] sinzui: it's in 1.16.1 too [15:03] fab. [15:03] linking up now [15:04] er... or, actually not merged on 1.16 branch yet, just proposed [15:07] submitted. [15:08] knew I was forgetting some branch as well as the openstack one === natefinch is now known as natefinch-afk [15:40] Hi juju dev's I have updated https://bugs.launchpad.net/juju-core/+bug/1246320 . juju 1.14.1 is also broken with the same error. I think azure or streams has changed. I am looking for insight into the root cause [15:40] <_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified

[15:45] does seem like an azure change, we discussed it briefly in the standup [15:46] I guess the next step is fiddling with the version info gwacl sends and seeing what happens [15:46] or just escalating to microsoft and asking what changed [15:55] +1 on the importance of sinzui's bug [15:55] bug 1246320 [15:55] <_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified

[15:55] arosales: have you got anyone on the azure end you can bother? [15:55] mgz, sure if its a platform issue I can ping microsoft [15:56] arosales: given it's failing on 1.14, 1.16, and trunk, when the exact same code was working before, something their side has changed [15:57] it may be that we now need to do something different, but it would be good to find out what they changed [15:57] mgz, if you can point me to an error message I can pass it their way [15:57] error message that would indicate azure is failing as they can still provision instances [15:58] be right back [16:00] is's basically MissingOrIncorrectVersionHeader, but we may still need to trace exactly what we're sending in the case it fails [16:01] hm... I have an idea [16:18] mgz, I discussed azure APIVersion with utlemming in #juju. [16:19] mgz, I just tried a global change of the APIVersion is gwacl by setting the date to today. All I accomplished was making bootstrap fail faster [16:19] dimitern: how's your knowledge of charm upgrade semantics? [16:19] I will try some alternate dates [16:20] sinzui: too many jujus. I see that log now. did you also catch the earlier discussion here on it between wallyworld and rvba? [16:20] I read it without full comprehension [16:21] well, rvba tried an alternate date and it didn't help === rogpeppe2 is now known as rogpeppe [16:23] mgz, fab, I will stop this line of inquiry [16:24] I do still worry about the whole on-some-requests-but-not-others aspects [16:25] could still be our http stack screwing up I guess, would be nice to wireshark and confirm the exact bits we send for the working vs non-working api calls [17:00] rogpeppe, good [17:01] dimitern: i'm trying to upgrade a charm that's in an error state, but it doesn't seem to be upgrading [17:01] dimitern: from my reading of the logic in ModeHookError, it should allow upgrading in that case [17:18] dimitern: ah, i get it now - i didn't use the upgrade-charm --force flag [17:18] rogpeppe, right! [17:19] rogpeppe, also, there's resolve --retry on the unit that's in an error state [17:19] dimitern: yeah, i knew about that [17:19] dimitern: i was just confused by the fact that the new charm had been downloaded, but the unit wasn't using it [17:26] cool, it all works now. === natefinch-afk is now known as natefinch [18:15] rogpeppe, mgz, dimitern: my instance type constraint: https://codereview.appspot.com/14523052/ [18:47] natefinch: sorry, i'll have a look in the morning' [18:47] rogpeppe: no problem [18:48] natefinch: you might be interested to have a look at http://godoc.org/launchpad.net/juju-utils/cmd/gocharm [18:48] natefinch: it's in an early stage - there are a few things that i know will change [18:48] rogpeppe: nice, I'll definitely check it out [18:48] natefinch: but the basic structure seems ok, i think [18:49] natefinch: you'll also want to look at http://godoc.org/launchpad.net/juju-utils/hook [18:49] natefinch: and there's an example charm in launchpad.net/juju-utils/cmd/gocharm/example-charms [18:49] * rogpeppe is now done for the day [18:49] rogpeppe: that's awesome. Nice work [18:51] natefinch: ta [18:51] g'night all [19:18] sinzui: would you have a moment for a hangout? [19:19] I do [19:26] arosales, juju-devs, I am contemplating freezing 1.16.1 and doing a release. I don't know how long it will take to sort out the azure issue, but I would rather do a 1.16.2 tomorrow then delay the maas and lxc fixes [19:28]