[00:02] redir: thanks for doc, i may have missed it, was there a test to check that "source" of config value is updated dynamically? ie if it shows "controller" and I update the region value to match that of the controller, the source should now say "region" [00:02] erm, lemme look [00:05] redir: also, i assigned you a nice card to pick up next :-) [00:07] wallyworld: how do you update the region value to match that of the controller? [00:07] 067118 [00:07] redir: you should be able to do all the development either with lxd or aws without teardown of server so dev cycle should be fast [00:08] wallyworld: would you care to HO for a minute on the QA/CI stuff? prolly faster [00:08] sure [00:08] standup [00:23] anastasiamac: I've added a request for more information, with instructions, on that ticket [00:24] menn0: u r brilliant! tahnk you :D [00:24] thank you even [00:30] thumper: i've missed 3 days. did u have a chance to import/export workloads for model migration? [00:31] wallyworld: model confi defaults: are cloud region default done? and command re-work? [00:31] commands* [00:32] no [00:32] there's cards for it on the board [00:32] q1 or q2 or both? [00:32] region defaults done partly [00:32] k [01:05] anastasiamac: I'm back [01:05] veebers: r u available? m happy to chat without u if u r busy and pull u in if we can;t live without :D [01:07] anastasiamac: I'm available [01:08] veebers: pm-ed u [01:24] anastasiamac: payloads? [01:24] yes [01:24] resources, no [01:24] k:D [01:43] axw: ping [01:43] katco: [ong [01:43] pong even [01:43] axw: hey, long time. o/ [01:43] katco: indeed, how's it going ? [01:43] axw: kind of chaotic here. kiddo is probably coming down with something :( [01:44] axw: how is your family doing? [01:44] that's never fun [01:44] yeah, it's no fun [01:44] katco: not bad, nothing eventful as that :p [01:44] lol, well that is good to hear ;) [01:45] axw: i pushed up further refactor of the deploy command. i couldn't get the tests passing tonight, but wanted to get someone's eyes on it since i'll be out for the next 2 weeks [01:46] axw: it's http://reviews.vapour.ws/r/5582/ if you (or anyone else) get a chance today. i'm afraid it's quite long, but i think a lot of the diff is tests [01:46] katco: ok. pretty busy today, but I'll see what I can do [01:47] axw: no worries. i understand if you can't get to it [01:47] so is it getting warmer over there? [01:50] katco: not really that warm here yet [01:50] katco: not as cold as it was a few weeks ago, but still fairly chilly [01:50] lucky [01:50] we had a nice fallish day today [01:54] Someday fall will come here. It's been unseasonably hot all summer. [01:55] well we're technically still in summer i suppose [01:56] I think we've had like one below average temperature day all summer. New England... where all the days are above average [01:56] wondering how much of that is climate change too =/ [01:57] well yeah. When the last like 15 months or something have all been record highs, globally, and 14 of the 15 hottest years have been since 2000 (or some numbers pretty close to those) [01:58] perrito666, etc: juju-mongodb3.2 3.2.9 builds fine on trusty it seems https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages [02:17] so weird.... the X button (window close) in the upper left of my windows is disabled when windows are maximized [02:18] no, sorry, all those buttons (minimize and maximize too) are disabled [02:38] menn0, veebers: who is ready for a call now? [02:38] menn0: i'm around [02:39] thumper: I'm available [02:39] I'll go with menn0 first because I think it'll be shorter [02:39] menn0: 1:1? [02:39] thumper: ok [02:53] veebers: now? [02:59] mwhudson: that's awesome. maybe we can get juju-mongodb on trusty updated at some points? [02:59] wallyworld: yeah, should be possible [02:59] \o/ [03:02] thumper: in 5? [03:03] veebers: sure [03:03] thumper: actually I wanted to ask wallyworld something but he's just disconnected. Now is fine :-) [03:03] ok [03:03] veebers: https://hangouts.google.com/hangouts/_/canonical.com/manual-ci?authuser=0 [03:03] thumper: menn0: axw: is it possible to use `juju scp` to copy between units directly? [03:04] kinda [03:04] goes via the host [03:04] anastasiamac: yes [03:04] but yes, I think [03:04] juju scp -- -3 from:path/to/file to: [03:04] something like that [03:05] \o/ thank you :D then we have a bug... but i'll target it ;D [03:05] the -3 is important [03:05] you can't copy directly between machines because they don't have SSH keys for each other [03:05] anastasiamac: I even made sure there was an example of this in the help [03:05] (last one) [03:06] menn0: and that's why u r brilliant \o/ tyvm [03:08] menn0: -3 is importnt because it's...? [03:09] $ man scp | grep -- -3 [03:09] -3 Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that this option disables the progress meter. [03:09] anastasiamac: ^ [03:09] menn0: \o/ [03:10] anastasiamac: the client can connect to the 2 Juju managed hosts, but the hosts can't connect to each other, so -3 works around that [03:10] menn0: awesome! i'll add it to the comment in the bug... i hope it's a user error and we don't need to do anything! thank you [03:30] wallyworld: you recently landed changes re: controller UUID handling right? [03:31] wallyworld: would this change what appears in a log forwarded syslog? (I think maybe the CI test for log-forward needs updated as it might be looking for the wrong uuid in the syslog file) [03:31] yes - controller uuid is now different to controller model uuid [03:32] wallyworld: which uuid will get forwarded for log-forwarding (and also, how would one get that uuid used) [03:32] i'll look. if the test assumed controller UUID = controller model UUID then it needs fixing [03:32] those values happened to be the same before but it is wrong to assume that [03:33] you know the uuid of the controller as it is the one you are connecting to [03:33] let me look at the test output [03:34] wallyworld: we were using the uuid from 'show-controller' json/yaml output under controllername -> details -> uuid [03:36] that is the correct thing to do [03:37] wallyworld: hmm, that would suggest that the ci test is doing the right thing but it fails. I'll dig deeper to see what's happenig [03:38] i'm just looking at the code [03:54] veebers: it depends on what you are looking for - the rfc5424 appname contains the model uuid not the controller uuid [03:55] it would have worked by coincidence before if you are searching using controller uuid [03:55] we do record the controller uuid in syslog structured data [04:00] wallyworld: For this test I use the UUID found as outlined before to check the logs of the rsync-sink to ensure expected output is landing there. [04:00] veebers: you misunderstand - i am saying you are probably checking the wrong content [04:00] wallyworld: oh [04:00] we record the model uuid, you are checking for controller uuid [04:01] we record the model uuid in the appname field [04:01] wallyworld: right, so I'm using the wrong uuid [04:01] only if the script is looking in appname [04:01] wallyworld: how does one get the controller model uuid? [04:01] if the script if looking in structured data then it is correct [04:01] wallyworld: its checking content of syslog on the rsyslog syslog file [04:02] right, but the syslog content contans lots of diffrent fields :-) [04:02] which field is the script looking for [04:02] appname of the structured data [04:02] *or [04:03] wallyworld: the check is doing a regex grep on syslog similar to: ^[A-Z][a-z]{,2}\ +[0-9]+\ +[0-9]{1,2}:[0-9]{1,2}:[0-9]{1,2}\ machine-0.0518053c\-31cd\-4d49\-8316\-a504c6d78389\ jujud-machine-agent-0518053c\-31cd\-4d49\-8316\-a504\ .*$ [04:03] (this is a specific example from a test) [04:03] right, so i guess it is grepping assuming it is parsing the appname field [04:04] use use show-model controller to see the controller model uuid [04:06] wallyworld: ok, I'll give that a spin now [04:06] fingers crossed, should be a simple fix hopefully :-) [04:06] hopefully :-) [04:06] "juju show-model controller" prodiceds yaml similar to show-controller [04:07] and you just get that uuid instead [04:07] cool, makes sense [04:07] we just needed to see what was being searched for in the syslog output [04:07] appname field or structured data [04:07] and now the tests will be even better because a faulty assumption will be fixed :-) [04:08] wallyworld: can you have structured data in the syslog log file (or am I misunderstanding again?) [04:09] yes, it is text, and can be parsed into simple fields and structured data. i think the structured data is written out inside [] but i'd need to check that syntax [04:09] it's all in the rfc standard [04:09] we write the flat fields and structured data fields [04:10] aooname is a standard scalar field [04:10] appname [04:10] we put "juju-"modeluuid in there i think [04:11] and then things like controller uuid, model uuid as separate fields in structured data [04:11] which is then flattened out into a line of text in the syslog file [04:11] i'd have to read the rfc to get the exact syntax etc [04:15] wallyworld: ah cool, thanks for clarifying [04:16] np [04:17] wallyworld: http://reviews.vapour.ws/r/5584/ [04:17] wallyworld: just running test suite now [04:17] wallyworld: much rationalisation on aliases [04:17] ok [04:18] thumper: you sure about add-units? we can add more than one at a time [04:18] juju add-units -n 10 [04:18] wallyworld: that's what the doc says [04:18] there is no alias for add-unit [04:18] hmmpf [04:19] the thing is, if you add plural for one, you should do for all [04:19] then it just looks messy [04:19] like you haven't decided [04:19] be opinionated [04:19] I went on changes based on the 2.0 command table [04:20] just wondering whether we should have status or show-status be the alias [04:20] doc says "status" is the alias [04:20] but it also says "list-foo" should be the primary [04:21] so it appears to be slightly out of date [04:21] thumper: in that case, we are inconsistent. the PR changes to juju list-sshkeys. but we still have juju machines as the list machines example [04:22] wallyworld: refresh [04:22] I fixed that [04:22] I tried to be consistent on all the aliases [04:23] wallyworld: http://paste.ubuntu.com/23122921/ [04:23] that is all the aliases now [04:24] thumper: lgtm with a trivial [04:26] wallyworld: taking the dog for a quick walk while it is light [04:26] bbl [04:26] sure, ttyl [04:26] pushed trivial fix and lined up for merging [05:17] wallyworld: fyi that was the fix for the CI job, seems I had conflated the controller uuid and the contrller model uuid. All sorted now [05:17] veebers: yay, thank you. not just you who confused it. juju did also for about 18 months or more :-) [05:18] heh :-) I've set the log-forward job to be non-voting for now until this fix can land in the test [06:16] dimitern: you about? [06:22] frobware: yeah [06:22] frobware: aren't you out today? [06:23] dimitern: for the "unconfigured vlan" bug I think I'm just going to deal with bridging unconfigured interfaces and leave the MAAS 2.1 issues for another commit [06:23] dimitern: I am - need to leave in a bit [06:23] frobware: ok, sgtm [06:24] dimitern: the script needs to change so that we can look at forward interfaces that we may (or may not) need to bridge. That's a departure from what we do today. [06:24] frobware: btw re the other bug with hostnames - I still think we should have that as an optional "native mode", even if later we do nss by default everywhere [06:24] dimitern: I think the nss module is orthogonal to that bug. [06:25] dimitern: if we probe/scan for open ssh ports on an undefined order that should still help without nss [06:25] frobware: that way we can work consistently across the board, but still satisfy specific deployments that need to use maas hostnames and have properly configured dns settings [06:26] dimitern: from a juju client perspective (CLI, UI) we would always be dealing with ip addrs [06:26] frobware: so I'm proposing to add a maas-specific config flag that enables "put hostname on top of addresses list", otherwise it doesn't and just returns IPs [06:27] off by default [06:27] dimitern: propose via email and let's discuss with jam, et al [06:27] and ivoks [06:27] ok [06:27] dimitern: I think we should try and land "unconfigured vlans" soon - if we can. [06:28] frobware: agreed - I'm on it [06:45] Bug #1441319 changed: intermittent: failed to retrieve the template to clone: template container juju-trusty-lxc-template did not stop

[06:51] Bug #1475509 changed: upgrade-charm --force behavior causes races

[06:51] Bug #1531589 changed: debug-log does not work with local provider on xenial + 1.25.0

[07:12] Bug #1475509 opened: upgrade-charm --force behavior causes races

[07:12] Bug #1531589 opened: debug-log does not work with local provider on xenial + 1.25.0

[07:15] Bug # changed: 1394223, 1475509, 1514456, 1531589, 1554088, 1613804, 1615106, 1615112, 1615118 [07:18] Bug # opened: 1394223, 1514456, 1554088, 1613804, 1615106, 1615112, 1615118 [07:21] Bug # changed: 1301367, 1394223, 1444576, 1446885, 1448308, 1514456, 1554088, 1613804, 1615106, 1615112, 1615118 === frankban|afk is now known as frankban [08:31] axw: here's a PR to handle the list controllers things http://reviews.vapour.ws/r/5585/ no rush to land, can do it next week [08:39] wallyworld: ok, will probably review on monday. still butting heads with auth [08:40] axw: yeah, no worries, figures as much :-) just letting you know [10:10] wallyworld: At the moment I'm not exposing much of the tags functionality in gomaasapi - just enough to do what we need in the provider. Is that ok? [10:10] wallyworld: We can always flesh out the other parts later as needed. [10:11] wallyworld: (is my thinking) [10:12] babbageclunk: in [10:12] oops [10:13] babbageclunk: in general, only exposing what we need is the way we've gone [10:13] babbageclunk: so that sounds good [10:13] babbageclunk: gomaasapi itself is open source - so if anyone needs more they can add it themselves [10:14] voidspace: cool, thanks - might get you to look at the interface I'm thinking about for tags before I start implementing it if that's ok? [10:15] babbageclunk: sure [10:27] down to only seven test packages that fail or won't build [10:27] progress [10:42] babbageclunk: sounds ok - just enough to satisfy our use case, but if there's a tateful way to do it so that we can accommodate future requirements, that would be good. the main thing for juju is to be able to get and set arbitary tags on machines and storage/volumes [10:44] wallyworld: ok - sounds good. [11:02] wallyworld: Just rereading your email - do we expose tagging to users somewhere? Or is it just something we use to find instances by custom tags internally. [11:02] ? [11:03] babbageclunk: the primary use case is to allow the Environ ControllerInstances() method to correctly identity which machines are controllers - that eliminates the provider-state file requirement. But we also support the resource-tags attribute in config to allow users to specify their own tags as well. There are typically seen via cloud specific tools, like the aws console for example [11:04] but juju could be asked to query and present them [11:07] wallyworld: Ah, ok - reading about resource-tags now. [11:08] babbageclunk: what happens when juju provisions a resource is that it applies standard tag values (eg controller uuid, model uuid etc) and then adds to those any user specified values [11:08] babbageclunk: so for example, model admins amay set different tags which are then used for accounting or other purposes [11:09] wallyworld: Ok, and then the point of those custom tags is that users can find them in the provider's UI (the maas one in this case)? [11:09] babbageclunk: see usages of the environs.tags.ResourceTags() method [11:10] yes [11:10] maybe juju can display those in stats, i can;t recall now exactly what the yaml contains [11:10] *status [11:13] wallyworld: Ok. [11:13] wallyworld: When you talk about storage volumes, that would correspond to block devices in maas-land? They don't seem to be able to be tagged in the same way. [11:16] babbageclunk: yeah, i'm not sure what maas supports there. in aws for example, we can tag ebs block volumes. but if maas doesn't support a similar concept that's fine. the main thing is to tag machines. but we may also query tags when killing the controller so that we clean up all resources. but that's only really relevant to clouds like aws where the storage is separate and is attached dynamically to a machine [11:16] s/is/may be [11:17] babbageclunk: you'll find StartInstance() in particilar for provider/ec2 or provider/openstack will have code to collect all the required tags and then apply them to the newly started instance [11:17] maas provider would do something similar [11:17] and then ControllerInstances() for maas would be changed to not use provider-state, and instead query machines where controller-uuid tag is the relevant one [11:18] and we'd move the Environ.Storage implementation off the maas 2.0 provider and retain it for use in 1.9, and the mass 2.0 work could be nice and clean [11:19] because Environ.Storage is i think only used to access the provider-state file [11:19] babbageclunk, wallyworld, voidspace: hey guys, can you have a look at http://reviews.vapour.ws/r/5586/ ? it should be straightforward [11:19] which we won't need on maas 2.0 now [11:21] wallyworld: ok, makes sense - thanks! [11:21] dimitern: Looking [11:22] dimitern: is SysClassNetPath const necessary as an arg? will it ever be anything different? [11:22] babbageclunk: ta! [11:22] wallyworld: well, I wrote it initially to take just a name, but then I found it awkward to test without introducing global vars unecessarily [11:23] wallyworld: it will only be called in a couple of places anyway [11:25] dimitern: yeah, understood. i also wonder if at least the error from say reading the file should be checked. fair enough if it's a notexists. but what happens if you get an eof? maybe worth at least loggin something before returning UnknownInterface. i'm a little wary of swallowing all errors [11:25] wallyworld: yeah, ok - I'll add Debug logging on error [11:26] dimitern: you'll appreciate the log entry when something goes wrong and you're asked to diagnose and fix :-) [11:26] wallyworld: sure - I'm usually the one to add insane level of trace logging all over the place :) [11:27] warranted in this case IMHO :-) [11:27] +1 [11:30] wallyworld, voidspace - here's how I'm planning to add tags to the gomaasapi interface: https://github.com/juju/gomaasapi/compare/master...babbageclunk:tags?expand=1 [11:33] babbageclunk: i don't know the gomaasapi very well, but i generlly prefer not to define interfaces domain entities like Tags and then add verbs to them, like Delete() or Machines() or UpdateNodes(). those verbs I tend to add to a service type of interface [11:34] the above really belong on Controller interface IMO [11:34] DeleteTag(machine, tag) [11:34] etc [11:36] wallyworld: I was trying to keep consistency with the other types - like Device.Delete or File.Delete. [11:37] wallyworld: (And to a lesser extent with the underlying API.) [11:39] dimitern: LGTM [11:39] dimitern: (Other than the logging that wallyworld mentioned) [11:40] babbageclunk: thanks! I've added logging and will push an update shortly [11:40] dimitern: cool [11:41] babbageclunk: Device and Machine interfaces for example in gomaaspi - these tend to only expose methods relevant to the domain entity which they prepresent [11:42] so given a Machine instance, you can query aspects of that machine. but you can't do things *with* that machine [11:42] it seems the Controller interface performs that role [11:43] eg AllocateMachine, ReleaseMachine etc [11:43] there could be tag related methods on a machine I guess [11:43] wallyworld: No, for example Machine has Start and CreateDevice. [11:44] right, but Device (which is analogoues to tag) doesn't have methods that can be used to manipulate machines. a Device is tied to a machine, hence I can see why CreateDevice is there [11:45] so a Machine interface could gain a Tagger interface, providing AddTag() DeleteTag() GetTag() on the Machine interface [11:45] wallyworld: Yeah, that makes sense. [11:46] babbageclunk: and Controller already has a Machine() method - the MachineArgs would gain tags to filter on [11:47] Machines() [11:47] wallyworld: That would make gomaasapi quite differently structured from the underlying API - do we think that's a problem? [11:48] babbageclunk: and hopefully/maybe the StartInstance args used to start an instance in maas would have a tags attribute so you can start an instance and apply tags in one call without having to follow up with AddTag() [11:48] doesn't the underlying api have a query machines method? [11:48] where you pass filter attributes to query on for example? [11:48] which is implemented by Controller.Machines() [11:49] wallyworld: It does, but it doesn't support tags. [11:49] oh, damn [11:50] wallyworld: The tag querying is done from a separate place in the api - you couldn't search by tag AND mac addresses, for example. [11:50] babbageclunk: so, we should construct the api to be the best it can be for juju and so it is consistent with our design goals; we can adapt that to the underlying maas api and then work with them to improve theor api if it is not "tasteful" [11:50] (Well, without doing that filtering in the gomaasapi ourselves.) [11:50] if the underlying api is not perfect, we should not build on that an expose it [11:51] we should adapt to it so that if/wehn it improves, out api stays nice and clean [11:51] that's IMHO [11:52] wallyworld: yeah, I see what you mean. [11:52] there's nothoing wrong with writing an abstraction layer that hides some dirty laundry :-) [11:54] ok - I'm going to think about that while I go for a run. Thanks! [11:54] babbageclunk: so yeah, think of a Tag like a Device; a machine instance has a Devices() method; it would also have a Tags() method. and just as there's CreateDevice(), also there will be a CreateTag() etc [11:54] have fun [11:54] or AddTag() [12:00] Hi. I want to deploy openstack using [MAAS+openstack-base-bundle]. Can anyone please give me the detailed hardware requirements. and refrence links for doing that. [13:05] wallyworld: still around? [13:08] wallyworld: Actually, I'm seeing a yoda-like apparition of you telling me how to handle the thing that occured to me on the run, so that's fine. [13:26] down to two failing packages [13:35] voidspace: \o/ [13:35] out of how many? [13:41] anyone familiar with configuring squid? [13:45] dimitern, voidspace, frankban, dooferlad: ^^ [13:46] all I want is the simplest "just forward everything from everyone" ... which google seems to think I am unique in wanting [13:49] natefinch: I've been there :) let me check my maas proxy setup [13:49] dimitern: exactly what I need it for :) [13:50] Bug #1619682 opened: [azure] can't bootstrap in Central US : no OS images found for location [13:52] natefinch: here's my /var/lib/maas/maas-proxy.conf: http://paste.ubuntu.com/23124122/ [13:53] natefinch: it's not exactly allow everything from everyone, but every segment defined in localnet [13:56] the problem with that is that then I have to edit it when things change... and if it breaks, I have to figure out what I messed up... whereas if there were something like "mode transparent" that just did the right thing, I wouldn't have to wonder if juju is broken or my proxy is broken. [13:56] dimitern: I'll try to make yours work for me. Thanks [13:57] natefinch: I hope it helps; fwiw I found transparent mode to be quite difficult to get working right [13:57] dimitern: not so transparent, eh? [13:58] natefinch: I found that using explicit http_proxy like http://10.20.20.2:8000 works best [13:58] with transparent mode you'll have tons of issues around TLS [13:58] dimitern: ahh yeah, that makes sense [14:00] natefinch: last time I tried to get transparent mode working with e.g. https://cloud-images.ubuntu.com/ took me a few hours and at the end it was still not usable [14:00] dimitern: well that makes testing this bug a lot harder [14:01] natefinch: you could do other things, like iptables + DNAT to the non-transparent proxy host:port [14:04] dimitern: that sounds much easier :/ [14:06] natefinch: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat [14:07] dimitern: Hi. I pused my charm to charm store. I am trying to set BUG URL. Here I am facing issue. pasted issue info : http://paste.openstack.org/show/566078/ [14:14] rock_: hey, I'm not sure why you're getting this error - where's your charm's source ? [14:20] natefinch: I don't have a maas2 setup. Maybe first step is me installing something and seeing what it needs for you? [14:20] dimitern: my charm source https://jujucharms.com/u/siva9296/kaminario-openstack [14:21] rock_: I mean is it on launchpad or github, etc. ? [14:22] macgreagoir: we could just screen share on my machine, would seem more efficient [14:23] natefinch: Aye, true enough. I mostly want to see what it has now as a proxy service, compared to 1.x. [14:27] dimitern: my source is not on Github. And please tell me what it means [is it on launchpad] [14:28] rock_: e.g. the cinder charm (https://jujucharms.com/cinder/) has bugs-url=https://bugs.launchpad.net/charms/+source/cinder/+filebug but that's because its source is at https://code.launchpad.net/charms/+source/cinder [14:32] dimitern: So How can I put my source on launchpad? [14:32] rock_: it doesn't have to be on launchpad - use whichever code hosting / bug tracker you're familiar with [14:33] rock_: have a look if this might help: https://jujucharms.com/docs/stable/charm-review-process [14:35] rock_: maybe someone from the charmers team might be able to help you better (or in #juju), like marcoceppi, jcastro, lazyPower [14:37] dimitern: we don't have any bug tracker as of now. for pushing charm we used https://jujucharms.com/docs/2.0/authors-charm-store. And Used https://github.com/openstack-charmers/release-tools/blob/master/push-and-publish#L138 to set bug URL. [14:37] dimitern: OK. Tahank you. I will ask. [14:39] sure, np [14:42] katco: ping [14:42] dimitern: pong [14:42] dimitern: err i mean "route to katco not found because of some obscure networking setup affecting juju" [14:42] katco: so it was decided to go less verbose and no way to bump it back up even you want all the details? [14:42] hehe [14:43] dimitern: yeah, that was what was suggested in the bug rick opened [14:44] dimitern: i wanted to log the messages to debug instead, but was getting late and couldn't find a hook to a logger with debug on it. i can certainly figure that out though [14:44] katco: ok [14:45] natefinch: double checking, this issue is wht dbus thing you fixed in 1.25.6? http://paste.ubuntu.com/23124253 [14:51] Bug #1619682 changed: [azure] can't bootstrap in Central US : no OS images found for location

[14:52] katco: you've got a review - though not terribly useful I'm afraid [14:52] dimitern: not a problem, tyvm for looking at it in the 1st place [15:01] macgreagoir: so, I have an answer on how we've done charmstore testing [15:01] mgz: I'm interested! :-) [15:01] we had a test that monkeyed with iptables after bootstrap on the state server [15:02] so when deploy happened after it would go off and talk to the staging store [15:02] but... we appear to have lost the test [15:04] macgreagoir: aha, assess_cs_staging.py in juju-ci-tools [15:04] macgreagoir: also, there seems to be a JUJU_CHARMSTORE envvar that should do something [15:04] but I'm not sure where or what [15:05] mgz: Let me see if I can find that. Rings a bell from a code comment. [15:05] mgz: oh god please don't check something like that into juju's src tree =| [15:07] mgz: yes, exactly [15:48] voidspace: still around? What timezone are you in at the moment? [15:54] morning === frankban is now known as frankban|afk [16:17]