[00:56] Where is the cloud-init file that juju pushes to machines placed? === flaviamissi_ is now known as flaviamissi [01:10] marcoceppi: for lxc, /var/lib/juju/containers//cloud-init [01:10] axw: I found them in /var/lib/cloud/seed/nocloud-net, let me check that path too [01:11] marcoceppi: sorry, I'm looking on the host here [01:12] axw: ack, np. Thank for the info! [01:12] nps === jam1 is now known as jam [06:07] can anyone help with a tmux session ? [06:08] question [06:09] using tera term [06:09] the tmux bottom line causes the terminal to scroll one line every second [06:09] any suggestions ? [06:10] davecheney: futz with $COLUMNS ? [06:11] jam: inside the debug-hook ? [06:13] davecheney: I don't really know, I would have said trying it in the container before starting the tmux session. It sounds like tera disagrees with 'write to the end of the line' as off-by-one [06:13] jam: yeah [06:13] which is why some people say you should code to line 79 because sometimes the terminal wraps the final \n. :) [06:13] i don' [06:13] i don't know if its fixable right now [06:13] i might have to twiddle the tmux conf [06:13] davecheney: can you just use xterm, etc ? [06:14] jam: we are using xterm [06:14] well, tera says it's xterm [06:14] (10:09:03) davecheney: using tera term [06:14] davecheney: right, tera is lying and claiming its xterm, but then treating screen width differently (from what you've said at least). [06:15] i've tried vt100 [06:15] vt32 [06:15] vt52 [06:15] etc [06:15] have you tried a terminal other than tera ? [06:15] jam: not an option sorry, we're in an SOE [06:15] standrard operating environment [06:15] which lacks freedom [06:18] jam: tmux thinks the window is one character larger than it claims [06:18] wider [06:20] davecheney: my guess is that tmux writes " "*39 + "\r", and tera thinks that the "\r" needs to wrap. [06:20] I haven't found ways to tweak either tera or tmux in my googling. [06:20] jam: thanks [06:21] let me try one thing [06:21] Windows shells tend to do the same thing wrong (which is why in our bzr code, we always write to COLUMNS-1, though some terminals let you write all the way to COLUMNS) [06:23] jam: any idea where the default ubuntu branded tmux conf lives ? [06:23] davecheney: http://askubuntu.com/questions/192401/where-is-the-default-tmux-conf-file-located [06:24] says there isn't one [06:24] but there are examples [06:24] in /usr/share/doc/tmux/examples === tasdomas_afk is now known as tasdomas [06:27] jam: where does debug hooks get it's magic one from ? [06:27] is this byobu ? [06:28] ah, it is [06:30] davecheney: it'll use ~/.tmux.conf if it exists [06:31] on first execution, that'll get populated with "source /usr/share/byobu/profiles/tmux" [06:31] source-file.. [06:35] fuck [08:07] mornin' all [08:45] jam: mgz: Hi… would any of you be available to update gwacl on the landing bot's machine? [08:46] fwereade: yo! [08:46] rogpeppe, heyhey [08:47] fwereade: how's tricks? [08:47] rogpeppe, not bad, had a lovely peaceful weekend [08:47] rogpeppe, and yourself? [08:48] fwereade: i had a lovely weekend full of frenetic outdoor activity :-) [08:49] fwereade: and in general things are ok [08:49] jtv: are you working on code to call getImageBaseURLs() on the azure provider? [08:50] fwereade: current area of discussion is how we might make the bulk API call code a little less... bulky [08:50] wallyworld_: not working on anything in the provider ATM, why? [08:50] fwereade: one possible approach is this: https://codereview.appspot.com/12845043 [08:51] fwereade: natefinch has another thought, which you might have seen (automatic code generation) [08:52] wallyworld_: the simplestreams code is already working for Azure, apart from a few limitations (images for any location only available in West US; only daily saucy images actually functional yet) [08:52] jtv: i'm doing some refactoring to extrude into a common function the url gathering which augments the base url with provider specific ones (if the provider supports such an operation) [08:52] so the azure function can be deleted [08:52] wallyworld_: that sounds nice... will it grab both the daily and the released images? [08:53] jtv: the current function just returns the DefaultBaseURL - i wasn't going to change that behaviour [08:53] how is simplestreams working if nothing calls that function? [08:53] for azure [08:54] wallyworld_: argh, another piece of dead code then! We just use the same global variable that that function returns. [08:55] rogpeppe, interesting -- it's one of those situations that makes me weep for the lack of generics really [08:55] Sometimes I find myself wishing for a tool to warn about dead code in Go. Some kind of lint checker. [08:55] the code should have been calling that function :-) [08:55] wallyworld_: feel free to change it! [08:55] ok, i'll work on it, thanks :-) [08:55] jtv: there might have been something like that added to go vet recently [08:56] rogpeppe: thanks! Worth reading up on then. [08:56] wallyworld_: sorry to bother you with that… but do you have access to the landing bot? I need gwacl to be updated there. [08:56] rvba: yes, sure [08:56] wallyworld_: thanks a lot. [08:57] fwereade: it's this kind of repetition which was the reason i structured the API the way I did in the first place (so that the magic was all in one place, in the rpc package) [08:57] rogpeppe: not seeing anything in the godoc for "go vet." There is some stuff that might be nice to make more routinely accessible though. [08:57] jtv: on tip? [08:58] The PPA. [08:58] rvba: now on rev 217. correct? [08:58] jtv: ah, it hasn't even landed on tip yet: https://codereview.appspot.com/12507043/ [08:58] wallyworld_: perfect, thanks again. [08:59] np, anytime [09:00] rogpeppe, yeah, I can see that limiting the spread of magic is generally a good thing [09:01] jtv: it only works with unexported identifiers though, so i'm not sure if it would flag your case above (what's the dead code you're referring to?) [09:02] fwereade, rogpeppe: fwiw we agreed yesterday to continue with the current approach until we have the uniter talking to the API first, and then proceed to refactor the server-side stuff - as we agree to do it - code generation or reflection [09:03] rogpeppe: unused unexported method. But if it's not landed yet, my individual case is sort of moot. :) [09:03] dimitern, that sgtm, thanks [09:03] dimitern, I'm kinda suspicious of both approaches ;p [09:04] jtv: you could always apply the CL locally [09:04] fwereade: I have my doubts as well, but the most important thing for me now is not to lose momentum with the implementation [09:04] dimitern, +100 [09:04] rogpeppe: to detect a dead method we've already detected? Thanks. :-) [09:04] jtv: lol [09:05] jtv: but what about all the others we haven't? :-) [09:05] Their time will come. [09:39] rogpeppe, does https://bugs.launchpad.net/juju-core/+bug/1205286 ring any bells? [09:39] <_mup_> Bug #1205286: charm directory permissions now more restrictive

[09:41] fwereade: not really, but i regularly campaign against the gratuitous use of non-0777 permissions when creating directories, usually to no avail [09:42] fwereade: I've updated the Makefile to add stable (now that the mongodb deps are there). If you can mark the MP to approved it should land: https://code.launchpad.net/~michael.nelson/juju-core/update-readme/+merge/179165 [09:43] noodles775, thanks, will do [09:43] ta [09:43] fwereade: hmm, a naive grep doesn't show that as a problem here though. [09:43] noodles775, done [09:44] rogpeppe, yeah, I was just poking at it and wondering what the deal was [09:45] * rogpeppe should really try out the local provider :-) [09:45] rogpeppe, that said, my instincts are leaning towards the "everything should keep working if everything jujey is removed" [09:46] rogpeppe, which would imply the "feature" interpretation [09:46] fwereade: by "everything", you mean the charm? [09:46] rogpeppe, yeah [09:46] fwereade: i think it's important that the charm directory be definitively available [09:47] fwereade: apart from anything, lots of charms use it to put config file templates in etc [09:47] rogpeppe, templates, fine... they'll only be used by hooks, surely [09:48] rogpeppe, but I'm pretty sure that the charm dir should be considered off-limits to anything not running as a hook [09:48] fwereade: hmm, it's certainly arguable [09:48] rogpeppe, because nothing else has any reason to believe that arbitrary changes are not happening at any given time [09:49] fwereade: yeah - assuming we overwrite charm dirs rather than duplicate them [09:50] rogpeppe, I think all it takes is assuming that hooks might do anything to the charm dir, and that v1 of a charm can't know what subsequent versions may choose to do instead [09:50] fwereade: but i'd like to at least know why we're seeing this behaviour - it doesn't look as if we're deliberately using 700 perms [09:50] rogpeppe, fwereade: https://codereview.appspot.com/12849043 - service-related uniter API calls [09:50] rogpeppe, I agree there [09:51] fwereade: personally i think the charm directory should be considered immutable [09:51] fwereade: but i realise that's probably a lost battle now [09:52] rogpeppe, one day we'll need some charm format changes, we can force it then, I hope [09:53] rogpeppe, all it really takes is *providing* a directory that charms are expected to write to [09:53] rogpeppe, and then rolling it up with some more changes that are compelling enough to make people want to switch ;p [09:53] fwereade: tbh i don't think we'll ever do it - we'd be giving up the main value of juju, which is the large base of charms [09:54] fwereade: yeah, we should definitely provide a charm scratch dir [09:54] fwereade: we could do that now actually [09:54] rogpeppe, yeah, that sounds smart actually [09:55] rogpeppe, then it's just a matter of communicating it to the charmers, and phasing in requiring its use [09:55] fwereade: yeah [09:55] rogpeppe, hard to check for automatically but we can certainly put it on the checklist [09:55] rogpeppe, on the other hand, we do lose the rollbackability [09:55] rogpeppe, however I'm not sure anyone's really using that [09:56] rogpeppe, ...but we don't know [09:56] fwereade: rollbackability assumes that *all* state is in the charm dir [09:56] * rogpeppe likes that word [09:56] rogpeppe, true [09:57] rogpeppe, or at least it assumes that external state is regenerated from the contents of the charm dir, but yeah [09:58] fwereade: anyway, we could theoretically roll back the contents of the scratch dir [09:58] mgz, jam: https://codereview.appspot.com/12849043/ [09:58] rogpeppe, yeah [09:59] fwereade: (assuming there are only files in there - what do we do if people are putting unix-domain sockets in there? :-)) [09:59] dimitern: i'm looking [09:59] rogpeppe: thanks [09:59] rogpeppe, hunt them for sport? ;p [10:00] fwereade: lol [10:05] fwereade: so did you have a response for bug #1205286 so that stub can get unblocked? [10:05] <_mup_> Bug #1205286: charm directory permissions now more restrictive

[10:10] fwereade: also, you never commented on Placement Directives and I wanted to send that to the list: https://docs.google.com/a/canonical.com/document/d/1Gq8RKyI4uLSYeamz7C2F0tgXdHhTj-d8thKhyX6ae4c/edit?usp=sharing [10:10] jam, I'm still thinking/trying to figure out what's happened with the bug [10:11] k [10:11] I don't have a particular stake in the matter, just care that stub has a way forward [10:12] and no particular rush on placement directives, but sort of a "lets get docs from the sprint out to everyone lese" [10:19] jam, I've just made the only comment I think I want to on placement directives [10:20] fwereade: well, if you want to barf on the overlaps, you'd need a way to disable the overlap for the current request (i think) [10:21] and the MaaS case for tags that might be service level, but might be unit level [10:21] are a bit less obviously "broken" than zone [10:25] dimitern: reviewed [10:25] rogpeppe: cheers [10:26] rogpeppe: LifeGetter works on units, how can it work on services as well? [10:27] dimitern: with no problem? [10:27] rogpeppe: with different entities? [10:27] rogpeppe: and we need both Watch for units and services [10:27] dimitern: LifeGetter works on any entity that has a Life method [10:28] rogpeppe: we need different methods for watching units and services [10:28] dimitern: all you'd need to do is make the auth func return ok for both units and services [10:28] dimitern: really? [10:28] rogpeppe: yes [10:28] dimitern: don't we watch both units and services with a Watch method? [10:28] dimitern: which has the same signature for each [10:28] rogpeppe: why should the same method operate differently? [10:29] rogpeppe: that's mixing responsibilities [10:29] dimitern: it's not operating differently - we're passing in entity names to watch, and it's doing that [10:29] rogpeppe: it should work either on units or on services, you can't mix them [10:29] dimitern: why not? [10:30] dimitern: we're saying "watch these things" [10:30] dimitern: where a thing is uniquely identified by its tag [10:30] rogpeppe: how about configsettings then? [10:30] rogpeppe: by your logic we shouldn't need another method [10:30] dimitern: we still need an entry point for that [10:31] dimitern: because we don't have an entity for config settings [10:31] dimitern: we don't consider having a Lifer interface to be mixing responsibilities [10:31] rogpeppe: so you propose to create a different authFunc just for LifeGetter and Watch works on either only units or only services [10:32] rogpeppe: I don't think it should accept mixed units and services tags in one call [10:32] dimitern: why not? [10:32] dimitern: it's a bulk call [10:32] rogpeppe: because it complicates the tests - we need to test all variations [10:32] dimitern: it takes a load of entities [10:33] dimitern: it's no more complicated than having extra entry points [10:33] dimitern: probably less so [10:33] dimitern: and the API calls make more sense that way, i think [10:34] rogpeppe: no, the simplification for having a single entry point will be transfered to increasing the test size 4-fold [10:34] dimitern: why should the API provide both UnitLife and ServiceLife when a single Life entry point is sufficient? [10:34] dimitern: really? isn't it a single extra entry in the argument slice? [10:35] rogpeppe: and we're talking about both Watch and Life - so AgentEntityWatcher and LifeGetter both need to work on units and/or services [10:35] dimitern: isn't that trivial? we just make an auth function that allows both the unit or the unit's service [10:35] rogpeppe: no, each tests tests at least 3 cases: valid tag, invalid tag, valid but unauthorized tag [10:36] dimitern: so that's 2 more entries in the arg slice, no? [10:36] rogpeppe: when we take into account services and units can be passed, that comes to 6 cases [10:37] rogpeppe: and in addition, we need to add a case when the tag is neither service nor unit [10:37] rogpeppe: so that's 7 cases to test [10:37] rogpeppe: i agree they can be done in a single call [10:38] rogpeppe: just the testing logic will be a bit more complicated after we get the results and check the resources [10:39] dimitern: yes, you'll have some extra cases to check, but you'd need to check all those cases if you had a different API call, no? [10:39] rogpeppe: and when relations come into play, I suppose their Life will be using the same entry point, so that's 3 more cases [10:39] dimitern: sure - but isn't it great that we can use the same API call (and code) for getting the Life of any entity? [10:40] dimitern: doesn't that make it particularly nice that we are actually sending tags over the wire, rather than just ids? [10:40] rogpeppe: I'll think about it a bit [10:40] dimitern: we already have the LifeGetter implementation, which can be used for all of this [10:41] rogpeppe: so I think they may end up in different facades, and the different facade may need to restrict what they are allowed to look at. But as long as the Auth is valid (unit agents can't look at machines, for example) having a unified call sounds good. [10:41] dimitern: (which, FWIW, would be wrong to use if you continue in the same direction - why should we have Life and ServiceLife not UnitLife and ServiceLife?) [10:42] jam: yeah, LifeGetter allows arbitrary restrictions on what you can look at [10:43] rogpeppe: so the auth func for LifeGetter should check AuthOwner for units and 1) get auth'ed entity, 2) compare it's service tag with the given tag - for services [10:44] rogpeppe: and basically the same for AgentEntityWatcher as well [10:44] dimitern: well, it could be simpler than that [10:45] dimitern: it sounds reasonable. i'll wait to see the code [10:46] dimitern: it basically comes down to: return tag == unit.Tag() || tag == names.ServiceTag(unit.ServiceName) [10:48] rogpeppe: what is '.tsv' stand for? tab-separated-value (like csv, just with a \t ?) [10:48] rogpeppe: I though you suggested having a way to get the auth'ed entity from the authorizier [10:48] jam: yeah [10:48] rogpeppe: like GetAuthEntity() interface{} [10:48] dimitern: yes - the above is assuming you've got unit from there [10:48] jam: i thought it was better than .txt and it does seem to have precedent [10:49] good evening gentlemen [10:50] i have a request from the far east [10:50] i need to build a version of juju that does not attempt to create security groups on openstack/hp cloud [10:51] is anyone able to help me ? [10:51] davecheney: do you need tests to pass too? [10:52] rogpeppe: no [10:52] davecheney: have you tried just commenting out the code that creates the security groups? [10:52] rogpeppe: yes, that is what I wanted to do [10:53] i was hoping for some advice [10:53] maybe I should just turn off the firewaller [10:54] davecheney: hmm, without security groups, how can you open any ports at all? [10:54] davecheney: 'cos presumably by default all ports are closed [10:55] rogpeppe: according to marcoceppi they don't actually firewall anything [10:55] just prevent most people from being able to deploy more than 10 services in total on their hp cloud account [10:55] rogpeppe: I know in ec2, the default is that all machines in the same security group can talk to eachother on any port. I'm not sure about hp/openstack in general. [10:55] davecheney: ah, so it should be irrelevant [10:55] jam: presumably these machines won't be in the same security group (because we can't create one) [10:56] jam: yeah, security groups in ec2 work [10:56] they don't in hp cloud [10:56] rogpeppe: I don't know that dave is asking for 0, just not 1-per-machine. [10:56] so the creation of the groups just presents an annoying limit [10:57] davecheney: ah, so you can create one group for the whole environment? [10:57] rogpeppe: preferably zero [10:57] groups [10:58] wallyworld_: poing [10:58] ping [10:58] davecheney: in that case, i'd just see what happens when you change environ.setUpGroups to return nil, nil [10:58] rogpeppe: ok, will do [10:58] davecheney: wat [10:59] davecheney, otherwise firewall-mode global will create just one, if that helps? [10:59] wallyworld_: we're going to be demoing on az1 and az2 "tomorrow", however last I checked az2 and az3 don't have simple stream data [10:59] fwereade, davecheney: yes, that was going to be my other suggestion [11:00] marcoceppi: maybe not, i haven't checked. i did some initial data for az1 using the juju tool. if we need it for the other regions it will need to be hand crafted. when is "tomorrow"? [11:01] fwereade: that might be better [11:01] marcoceppi: there won't be simplestreams data in cloud-images, since hp isn't (yet) a CPC [11:01] i'll try that [11:01] wallyworld_: 12 hours from now [11:01] wallyworld_: can we generate stuff and put it with the tools we copied over there ? [11:02] marcoceppi: ok, i'll see if i can whip something up tonight. i may not be around tomorrow as it's a holiday here. how long will you e around for now? [11:02] jam: az1 data exits already, it'd be nice if az2 and 3 were also in there [11:02] wallyworld_: I'll be around for 2-3 hours [11:02] jam: what he said - the existing nmetadata nwds to be added to [11:03] marcoceppi: ok, i'll see what i can do. maybe you could test once i do it [11:03] wallyworld_: I'd be happy to test! [11:03] ok, leave it with me [11:03] marcoceppi: what image ids do we want? [11:04] there's a bug i think with those listed [11:04] wallyworld_: thanks for taking a look! If not I can dig through the metadata plugin if you run out of time and put it in a seperate bucket [11:04] i'll see if i can find it [11:04] wallyworld_: I'll double check in the console [11:04] they may have changed [11:04] ok, if you tell me the images ids for az2 and az3 that would be great [11:04] marcoceppi: what series also [11:04] precise? [11:05] wallyworld_: I see endpoint data but no content: https://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:hpcloud.sjson [11:05] jam: the data isn't there yet. it's in the hp cloud public bucket [11:05] ah, ok. [11:06] * wallyworld_ wishes it was there [11:06] sorry, marcoceppi has lagged out [11:06] he'll be back in a sec [11:09] marcoceppi: firewall-mode: global [11:09] fwereade: firewall-mode: global might be the trick for us [11:10] davecheney, cool [11:10] davecheney, glad it's good for something, I was worried about it for a while ;p [11:10] fwereade: that means we're down to 2 sec groups per student [11:10] that'll do [11:10] we can squeak by [11:11] thanks [11:12] wallyworld_: yes, precise [11:12] ok [11:12] wallyworld_: would it be possible to put the data in the same bucket as the one davecheney sends out during ANN for juju-core testing on hpcloud? [11:13] marcoceppi: yeah,that's what i'm doing [11:13] wallyworld_: <3 awesome, thanks! [11:13] updating existing metadata [11:13] just need the images ids :-) [11:13] wallyworld_: thanks man [11:14] anytime [11:14] so far we've been able to avoid spinning custom tools [11:14] there is one more problem which I'm not sure I can fix without changing the tools [11:14] yes? [11:15] byobu doesn't interact well with tera term [11:15] wallyworld_: AZ2: 68481 AZ3: 49850 [11:15] ta [11:15] so I need to put `apt-get remove byobu` in the cloud-init so I can remove byobu and fall back to tmux [11:16] wallyworld_: don't you need the uuids or HP being Diablo just has the short names [11:16] ? [11:16] morning all [11:17] jam: we support both uuids and ints transparently [11:17] (and afternoon and evening as the case may be) [11:17] hi natefinch [11:18] wallyworld_: I created simplestream data a while a go for az3, if it helps [11:19] natefinch: おはようございます [11:19] marcoceppi: i've done the new data, just using the validation tool to smoke test it. but i have no perms to re-upload it turns out [11:20] wallyworld_: ack [11:20] wallyworld_: sad trombone [11:20] marcoceppi: do you have permission to write to the public bucket? [11:20] davecheney: ha. Sorta surprised google knew what to do with that. [11:20] wallyworld_: no that I know of [11:21] marcoceppi: is arosales around? he can [11:21] wallyworld_: arosales has been up for about a day [11:21] he's been sorting out all our shit today [11:21] wallyworld_: he may be around, but I'm not sure [11:21] i think he's turned in [11:22] ok [11:22] slacker ;) [11:22] rogpeppe: RE the HP provider returning ErrNoInstances, I just went to make the change to shortAttempt that you mentioned, but afaics from the bug, it's not related? That said, I *think* I found another potential cause... details in the description: https://codereview.appspot.com/12795045 [11:22] only one day? [11:22] so what you can do is create a new container, make it globally readable, and put tools and new metadata in it [11:22] wallyworld_: I might be able to actually, let me check [11:22] and set the public-bucket-url accordingly [11:24] noodles775: looking [11:25] marcoceppi: davecheney: i have the new metadata if only we could write it [11:25] you guys need to give me more advance notice [11:26] wallyworld_: i'll thank you personally for that helpful comment next week [11:26] davecheney: just saying [11:26] wallyworld_: I have perms to the hp public bucket, but I thought you did, too. [11:26] yeah, sorry, we're really hulk smashing this whole training [11:27] davecheney: just being a prick, sorry [11:27] s'ok [11:27] if that was the worst thing that had happende this week, i'd be upset [11:27] but it isn't [11:27] not by a long shot [11:27] jam: i logged in and can only see us-west [11:28] and cannot see the public bucket [11:28] wallyworld_: I have a bukkit [11:28] marcoceppi: we may be able to write the files [11:28] noodles775: good catch! [11:28] \o/ [11:28] wallyworld_: there is only 1 storage [11:28] there are 3 computes [11:28] they all use the same storage [11:28] noodles775: looks like a good fix. it would be nice to be able to test it though. [11:28] az3.geo-1, vs just geo-1 [11:28] IIRC [11:29] jam: i can only see 3 containers, none of which is the public bucket when i log in [11:29] wallyworld_: I see roughly the same thing, but we have the tools somewhere in that account :) [11:30] wallyworld_: "control-bucket: juju-dist" [11:30] jam: ah, maybe i am a dickhead, there is a drop down with projects which i didnt see [11:30] let me try selecting the right project [11:30] wallyworld_: I didn't see it either [11:30] wallyworld_: https://console.hpcloud.com/object_store/region-a_geo-1/containers/juju-dist [11:31] yep, uploading now [11:31] marcoceppi: ready for testing [11:31] davecheney: ^^^ [11:33] dimitern, rogpeppe, standup? https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 [11:33] wallyworld_: ok, will test [11:33] wallyworld_: thank you [11:33] axw: ^^ [11:33] davecheney: np at all. if it doesn't work, i'll fix, let me know [11:35] wallyworld_: http://paste.ubuntu.com/5980804/ [11:35] ^ it's copying tools, is this expected ? [11:35] davecheney: it wasn't expected for me [11:35] do you have public-bucket-url set for HP? [11:36] jam: sorr, i might have screwed up [11:36] yes, looks like public bucket is not set right if it can't see tools [11:36] public-bucket-url: https://console.hpcloud.com/object_store/region-a_geo-1/containers/juju-dist [11:36] davecheney: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910 [11:37] ok, that was what I had before [11:37] my bad [11:37] davecheney: soon, public bucket will not be necessary at all \o/ [11:37] 2013-08-13 11:37:34 INFO juju provider.go:734 environs/openstack: started instance "1670895" [11:37] 2013-08-13 11:37:35 INFO juju supercommand.go:276 command finished [11:37] got an instance in az3 [11:37]