mupBug #1512191 opened: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>01:34
mupBug #1512191 changed: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>01:37
mupBug #1512191 opened: worker/uniter: update tests to use mock clock <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1512191>01:43
cheryljanastasiamac: ping?02:25
anastasiamaccherylj: pong?02:25
cheryljhey :)02:25
cheryljgot a few minutes to chat?02:25
anastasiamaccherylj: isn't it sunday for u?02:25
anastasiamacof course02:25
cheryljtechnically, yes02:25
anastasiamactomorrow's meeting?02:26
cheryljyes, let me get my headset02:26
davechen1ymwhudson: so far joining the IBM partner network has granted me03:00
davechen1y1. zero access to the things I want03:00
davechen1y2. spam03:01
mwhudsondavechen1y: \o/03:05
mwhudsondavechen1y: i'm not sure i've gotten as far as getting spam03:06
jamdimitern: did I miss you at our 1:1 ? I thought I was in the room a while08:47
dimiternjam, sorry, I overslept :/08:48
jamdimitern: k. no prob. I just was making sure we still had the right schedule with tz changes08:53
dimiternjam, yeah, the schedule is correct08:54
voidspacedimitern: ping09:44
dimiternvoidspace, pong09:45
voidspacedimitern: hang on - trying something09:48
voidspacedimitern: may still need your help, will re-ping if necessary :-)09:48
dimiternvoidspace, :) sure09:48
voidspacedimitern: dooferlad: frobware: just grabbing coffee and taking a loo break, will be a couple of minutes late to standup09:56
dimiternvoidspace, np09:56
dimiternjam, standup?10:03
voidspacedimitern: omw10:07
voidspacewallyworld: ping10:07
frobwarejam: today is the day, my first bootstrap failed with the replica set failure; the day keeps getting better.... ??? :)10:10
voidspacedimitern: are addressable containers in 1.24?10:32
dimiternvoidspace, there are some parts of it, but it's not working fully10:33
voidspacedimitern: so there could be people using deployed environments with addressable containers10:34
dimiternvoidspace, in 1.24 ?10:35
voidspacedimitern: yep10:36
dimiternvoidspace, that's possible of course, but I highly doubt it10:36
voidspacedimitern: so making them "not work" on maas 1.8 would be a backwards compatibility issue...10:36
dimiternvoidspace, they won't work on maas without devices support, i.e. <1.8.210:37
voidspacedimitern: what do you mean by won't work?10:37
dimiternvoidspace, juju cannot guarantee container resources will be full released10:39
voidspacedimitern: don't we support the older ways of requesting addresses - we used to10:39
voidspacedimitern: so by "won't work" you mean "will work but there might be a temporary issue later under some circumstances"10:40
voidspacedimitern: I really dislike the abuse of the phrase "won't work"10:40
dimiternvoidspace, the "temporary" issue is quite critical for some of our users10:40
voidspacedimitern: specific users in specific cases10:41
voidspacedimitern: that we can communicate with10:41
dimiternvoidspace, since maas 1.8.2 is in trusty, as a user you most likely won't even see that error10:41
voidspacedimitern: we have many users with many use cases, breaking stuff that works for one use case - when we have fixed the problem for the other use case and can communicate with them - seems like a real backwards step to me10:44
voidspacedimitern: we're [potentially] breaking things for some users - to avoid a problem that we've already fixed another way!10:45
dimiternvoidspace, all of that depends on the definition of "works"10:46
dimiternvoidspace, does it work if you can re-do the same deployment on the same maas only a certain number of times?10:47
voidspacedimitern: well sort of but "the feature does what it says but under some circumstances might temporarily leak resources when you've *finished using it*"  is a funny definition of "doesn't work"10:47
voidspacedimitern: using thousands of containers within a short space of time is a pretty specific use case - and one we *have addressed*10:48
voidspacedimitern: we're not ignoring that use case, but to block *all other use cases* because of it is not good10:48
dimiternvoidspace, sorry, but that's sounds to me like saying "leaving instances around after destroy-environment is not our problem, as it did work fine while the environment was running"10:48
voidspaceperrito666: morningg10:48
voidspacedimitern: leaving instances around, that cost money, would be much worse and we should really avoid it10:49
voidspacedimitern: temporarily leaking a dhcp lease is not the same10:49
dimiternvoidspace, it's the same, but it takes more retries for it to become a problem10:49
dimiternvoidspace, the same as with memory leaks really -  a small leak won't be a problem, unless you run your application for a long time10:50
voidspacedimitern: they're not at all the same10:50
voidspacedimitern: resource leakage is not a good thing10:50
wallyworldvoidspace: hi10:51
voidspacedimitern: having temporary leaks that don't cost money under specific known corner cases - addressed in a later release - is not the end of the world10:51
voidspacedimitern: stopping *existing deployments* working, is much worse10:51
dimiternvoidspace, why you keep calling the leaks "temporary" ? it's not like they're going way by themselves after a while10:52
voidspacedimitern: the dhcp lease expires, true?10:52
dimiternvoidspace, that depends on the dhcp server config10:52
voidspacewallyworld: I would like to talk to you about bug 140368910:53
mupBug #1403689: Server should handle tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Triaged> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1403689>10:53
dimiternvoidspace, I think MAAS dhcpd uses rather long leases by default10:53
voidspacewallyworld: did you fix it in the server or client?10:54
voidspacewallyworld: server I assume10:54
wallyworldvoidspace: tim had already found and fixed most of the cases of mapping series -> version, but there was one place in simplestreams search that was not covered10:55
voidspacedimitern: this is a specific use case for *experimentation*, real users aren't burning through all their dhcp leases! I'm not saying ignore the issue - we've fixed it! (Requiring maas 1.8).10:55
voidspacedimitern: however blocking all other "normal uses" because of it, seems wrong / bad10:55
wallyworldvoidspace: so all the usages that i can see that would panic or return an error have been patched10:55
voidspacewallyworld: where?10:56
voidspacewallyworld: we have this problem on 1.20 / 1.22 servers...10:56
dimiternvoidspace, can you explain which "normal users" will be blocked?10:56
voidspacewallyworld: which can't be upgraded with --upload-tools10:56
wallyworldi fixed it in master10:56
wallyworldand 1.25 i think10:56
voidspacedimitern: anyone using addressable containers10:56
dimiternvoidspace, for existing environments, it will keep working as before10:56
wallyworldupload-tools is bad10:56
dimiternvoidspace, for new environments, the new behavior is enforced by default10:56
wallyworldwe try not to encourage its use10:57
voidspacewallyworld: however if you want to give users new binaries to test a fix it is what we have10:57
wallyworldis there a use case for it?10:57
voidspacewallyworld: unless you can suggest an alternative?10:57
voidspacedimitern: upgrading a deployed environment10:57
dimiternvoidspace, the only affected users will be those using maas 1.7 or earlier10:57
wallyworldour policy afaik is to get them to upgrade to latest stable relase10:57
wallyworldaka 1.2510:57
wallyworlduness that's changed10:58
voidspacewallyworld: that upgrade doesn't work10:58
wallyworldfrom 1.22 to 1.25?10:58
voidspacewallyworld: we need to know if a proposed change has fixed the problem they have10:58
voidspacewallyworld: yep10:58
voidspacewallyworld: lots of horrible problems10:58
wallyworldwe haven't cuaght that in CI?10:59
wallyworldCI should have flagged those issues10:59
voidspacewallyworld: https://bugs.launchpad.net/juju-core/+bug/150786710:59
mupBug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1507867>10:59
voidspacewallyworld: for a specific user10:59
wallyworldvoidspace: ah right ignore-machine-addresses10:59
voidspacewallyworld: not just that though11:00
wallyworldwhat else?11:00
wallyworldthere was a mongo corrution11:00
wallyworldbut we were witing for logs11:00
wallyworldmogo got corrupt before upgarde11:00
wallyworldand could be fixed by running repairDatabase()11:00
voidspacewallyworld: meanwhile, I've fixed the ignore-machine-addresses issue11:00
voidspacewallyworld: but I can't get them to test that11:01
wallyworldwhat about trying upload-tools with a 1.25 client?11:01
wallyworldand having a custom jujud in the path11:01
wallyworldunless w ebackport all the series versio fixes (and there were several, older clients will get stuck i expect)11:02
wallyworldand we are not doing any new 1.20/1.22 releases11:02
dimiternvoidspace, so is the whole argument about displaying a warning if we detect no devices api instead of an error?11:02
voidspacewallyworld: is the fix in the client then?11:04
voidspacewallyworld: the 1.25 client won't attempt to upload a version that the 1.22 server rejects?11:04
voidspacedimitern: a warning would be better, rather than refusing to create a new container (for deployed environment that may already have addressable containers created under 1.24)11:05
voidspacewallyworld: sinzui said he *would* do new 1.22 release if required for this bug11:05
wallyworldvoidspace: --upload-tools will IIRC choose a jujud in the path - so you put the jujud that you want to test where the client can see it11:05
dimiternvoidspace, in this specific case, I agree11:05
voidspacedimitern: \o/ :-)11:05
dimiternvoidspace, :)11:06
wallyworldvoidspace: and using a 1.25 client with all the series version fixes should work (that's my theory)11:06
voidspacewallyworld: ok11:06
dimiternvoidspace, how about in other cases - new environment on older maas (<1.8)?11:06
wallyworldvoidspace: if we are to do a new 1.22, then all the series version fixes from tim and me would need backporting11:06
voidspacewallyworld: right11:06
voidspacedimitern: I care less I guess - but I don't think addressable containers are broken just because deploying thousands of them and using destroy-environment force causes an issue11:07
voidspacedimitern: that's a very specific (and experimental) use case - that we have a fix for11:07
voidspacedimitern: so even then, preventing addressable containers seems wrong to me11:07
voidspacedimitern: not the world's worst wrong, only a minor wrong...11:07
voidspacedimitern: so I would prefer a warning then too11:07
wallyworldvoidspace: we can do that backport if needed. but it would be intersting to try 1.25 client with custom 1.22 jujud push up via upload-tools11:08
voidspacewallyworld: however, we are seeing --upload-tools *not work* on 1.22 (with a custom jujud in the path)11:08
voidspacewallyworld: try it yourself, deploy 1.22 then try --upload-tools with only the new jujud in the path11:08
voidspacewallyworld: you hit the wily bug11:08
wallyworldvoidspace: it would be intersting to see then error then so we can see where the issue is11:08
dimiternvoidspace, how about an extra flag - error by default, with the flag - warning and proceed?11:08
voidspacedimitern: more flags! don't like it11:09
wallyworldvoidspace: ok, i'll try, but likely tomorrow11:09
wallyworldneed to finish ome other stuff tonight11:09
voidspacewallyworld: I'll try again today and email you (currently working on a different environment)11:09
voidspacewallyworld: and confirm that I can't upgrade from 1.22 to latest trunk11:09
voidspacewallyworld: and you can believe me or not! :-)11:09
wallyworldman, we need to fix our upgrades11:10
dimiternvoidspace, users are unlikely to see a mere warning in the case where juju is used as a tool (e.g. autopilot or a scripted deployer-based deployment)11:10
wallyworldand figure out why CI didn't catch the issues11:10
wallyworldvoidspace:  i believe you but just don't have enough info yet11:10
voidspacewallyworld: sure :-)11:10
voidspacewallyworld: I'll email you and you can tell me what more diagnostic information you need11:10
wallyworldonce i see the symptoms i can look at the code and see where the issue might be11:10
voidspacedimitern: users are unlikely to hit the problem11:11
wallyworldok, and i'll try also11:11
voidspacedimitern: and if they do we have a known fix for them11:11
voidspacewallyworld: thanks11:11
dimiternvoidspace, which is?11:11
voidspacedimitern: upgrade maas...11:11
dimiternvoidspace, and how are we communicating that to the users?11:11
voidspacedimitern: all our available communication channels11:12
voidspacedimitern: creating hundreds of containers and then destroying them is a pretty specific use case11:13
dimiternvoidspace, like the docs that suggest "oh, and by the way just in case set disable-network-management: true in your environments.yaml" ? :)11:13
dimiternvoidspace, yeah, it's one of the cases we should support well - for density11:14
voidspacedimitern: yep, I definitely agree we should make it work11:14
voidspacewe don't really have any choice in that matter11:14
voidspacedimitern: new topic11:19
voidspacedimitern: hopefully less contentious11:19
dimiternvoidspace, ok :)11:19
voidspacedimitern: I'm trying to recreate the ignore-machine-addresses issue11:19
dimiternvoidspace, yeah?11:19
voidspacedimitern: I have a deployed environment (current trunk) with a deployed unit of wordpress11:19
voidspacedimitern: on that machine I've added a new nic11:20
voidspacedimitern: this is my nic definition http://pastebin.ubuntu.com/13081446/11:20
voidspacedimitern: I see "eth0:1" with that assigned (and spurious) 10.0 address when I do ifconfig11:21
voidspacedimitern: but I don't see any issue with the machine from juju11:21
voidspacedimitern: it isn't visibly picking up that new (wrong) address11:21
dimiternvoidspace, did you wait ~10m for the instance poller to try refreshing the machine addresses?11:21
voidspacedimitern: no...11:21
voidspacedimitern: :-)11:21
voidspacedimitern: I'll go get coffee and see what happens11:21
dimiternvoidspace, :)11:22
voidspacedimitern: thanks11:22
dimiternvoidspace, np, might not be the only thing, but I'd start there11:22
voidspacedimitern: cool11:22
jamdooferlad: frobware: I'm back around if you wanted to chat11:27
rogpeppei need a review of this please, towards fixing a juju critical bug: https://github.com/juju/persistent-cookiejar/pull/911:28
rogpeppemgz_: ^11:29
rogpeppemgz_: i don't think that this will entirely fix CI problems with the cookies though11:29
jamfrobware, dooferlad, dimitern, voidspace: did any of you get a chance to play with the updated kvm_mass script?11:41
dooferladjam not I11:41
jamdooferlad: did you have any other questions about bug #1510651?11:41
mupBug #1510651: Agents are "lost" after terminating a state server in an HA env <bug-squad> <ensure-availability> <juju-core:Triaged by dooferlad> <https://launchpad.net/bugs/1510651>11:41
dimiternjam, not yet, I have to fix my vmaas first11:42
dooferladjam: I probably will have, just not yet.11:42
frobwarejam: not me either11:43
jamk. I'm happy  to get feedback if there are thoughts about what could make it better11:43
jamthe next step I was considering was creating networks11:43
frobwarejam: I have 12+ nodes in various combos already.11:43
jamsay you could tell maas what networks and what spaces you wanted, and then it would make sure those existed in libvirt11:43
jamfrobware: hopefully a given node isn't in more than one maas, given each maas wants to control its subnet11:44
frobwarejam: no I have some half-baked naming scheme that mostly keeps me out of trouble.11:44
jamfrobware: heh. I was just using "m1-foo1" and was planning to go to "m2" if I set up another maas.11:47
voidspacejam: not yet11:49
voidspacedimitern: no dice11:50
voidspacedimitern: it still reports imaginative-hose.maas as the dns name11:50
voidspacedimitern: and I can still ssh to the machine via "juju ssh 1"11:50
voidspacedimitern: I guess imaginative-hose still sorts earlier11:51
voidspacedimitern: although 10.0 should sort before 172.16 - anything else I can do to trigger the bug11:51
dimiternvoidspace, but do you see the extra address you added?11:51
voidspacedimitern: see it where?11:51
dimiternvoidspace, well, in the log - as part of the machine addresses11:52
voidspacedimitern: I'll check11:52
voidspacedimitern: not in all-machines.log11:53
voidspacedimitern: I'll change the log level and check again11:53
voidspacein 10 minutes...11:53
dimiternvoidspace, for the sake of the test, you could reduce the instance poller timeout11:54
voidspacedimitern: yeah, adding better instrumentation would be a good idea too11:54
voidspacedimitern: thanks11:54
dimiternvoidspace, looking at the network package's address sort order is: public IPs first, hostnames next (except "localhost"), cloud-local, machine-local, link-local11:55
voidspacedimitern: I'll try and find the bug report and see if it has repro instructions11:55
dimiternvoidspace, there's also the piece of code in maas that *always* adds the hostname of the machine in the response of the provider addresses11:56
voidspacedimitern: yeah, but the bug was a problem for maas users - so it is obviously possible to trigger it11:57
dimiternvoidspace, I think the difference is machines hosting units (and needing a preferred private address) and machines not hosting units (which only need the public address to display in status)11:58
dimiternvoidspace, so I'd try not add-machine + add extra IP, but deploy a unit and then add extra IP on that machine11:58
voidspacedimitern: I did the latter anyway (used deploy and not add-machine)12:00
voidspaceI'll find the bug report12:00
rogpeppeif you want master unblocked, could someone please review this? https://github.com/juju/persistent-cookiejar/pull/912:00
dimiternrogpeppe, reviewed12:01
rogpeppedimitern: ta!12:01
mupBug #1512371 opened: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>14:45
mupBug #1512371 changed: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>14:48
mupBug #1512371 opened: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1512371>14:51
cmarswwitzel3, can i get a review of http://reviews.vapour.ws/r/3040/ ? (fixes-1511717)15:16
cmarswwitzel3, thanks!15:17
mgz_cmars: if a user has both an old juju client installed, and a newer juju in ~/.local or something for testing a shiny new feature15:21
mgz_do we break them?15:22
cmarsmgz_, hmm.. i guess such a user would need to use separate JUJU_HOME directories in that case, wouldn't they?15:23
mgz_well, I know they don't in practice15:23
cmarsmgz_, but they'd have to, because the newer juju will have providers that the old juju doesn't understand15:23
mgz_when I give someone a binary to test I don't say "only use this with JUJU_HOME=/tmp"15:23
mgz_natefinch: I believe we are still on step #1: make the unit tests pass with go 1.515:34
natefinchmgz_: oh man.  is there a list of what needs to be fixed?  The LXD provider is dependent on go 1.3+ due to limitations with the LXD Go library15:35
=== meetingology` is now known as meetingology
mgz_the remaining issues with run-unit-tests-wily-amd64 look like big environmental things rather than nice easy things like map ordering15:35
mgz_bug 1494951 looks like one place to start15:36
mupBug #1494951: Panic "unexpected message" in vivid and wily tests <bug-squad> <ci> <intermittent-failure> <panic> <unit-tests> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1494951>15:36
natefinchmgz_: do you know if there's a team assigned to get us working on 1.5?15:37
mgz_I know that some of the other-way-uppers have fixed bugs relating to it, but just as good citizens15:37
mfoorddimitern: ping15:37
katcofrobware 's team is on bug squad i think15:37
katconatefinch: mgz_: frobware: seems like getting 1.5 bugs fixed needs to be high priority15:38
ericsnowwith a plugin provider it wouldn't be a short-term issue...15:39
ericsnowjust sayin' :)15:39
mgz_the other thing I see a lot of in the history is worker/peer group related test failures15:39
natefinchericsnow: we'd still need 1.5 support in trusty, and I don't think we'd also have 1.2 in trusty, so that would be a problem15:40
ericsnownatefinch: true15:40
mgz_yeah, we can't backport toolchain to trusty15:40
frobwarekatco, ack15:41
dimiternmfoord, pong15:41
mfoorddimitern: reading through the ignore-machine-addresses bug it looks like it only affected containers15:42
mfoorddimitern: is that true?15:42
mfoorddimitern: https://bugs.launchpad.net/juju-core/+bug/146348015:42
mupBug #1463480: Failed upgrade, mixed up HA addresses <blocker> <canonical-bootstack> <ha> <upgrade-juju> <juju-core:Fix Released by wallyworld> <juju-core15:42
mup1.22:Fix Committed by thumper> <juju-core 1.24:Fix Released by wallyworld> <hacluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1463480>15:42
mfoordI assume without addressable containers on as they're starting pre-1.2415:42
dimiternmfoord, yeah15:42
mfoordalso it looks hard to reproduce (timing related)15:42
mfoorddimitern: so to reproduce this I really need to add an lxc container15:43
mfoordand add the virtual nic there (?)15:43
mfoordI have a build with extra instrumentation and a shorter poll time on the instancepoller15:43
dimiternmfoord, let me think15:43
natefinchmgz_: how can we require 1.5 if 1.5 is not in trusty?15:43
mfoordalthough it looks to me like the instancepoller only requests provider addresses and that machine addresses are done by the machiner15:43
dimiternmfoord, yeah, the machine addresses are updated on machiner startup15:44
mfoorddimitern: so really rebooting the machine should trigger it15:44
mfoorddimitern: I'll add a container and reboot15:44
mfoordonce the container is up15:44
dimiternmfoord, no need to reboot - just restart the machine agent15:44
mfoorddimitern: but should I add the extra nic to the container or to the host15:45
mfoordor both just to be sure...15:45
dimiternmfoord, I guess both, and that address should be like 10.0.0.x15:45
mfoorddimitern: ok15:45
mgz_natefinch: you can't, but how are you running an lxd provider on trusty?15:47
natefinchmgz_: Is trusty never having anything beyond juju 1.25?15:47
mgz_natefinch: that's not the plan, but I don't know what the intention is with your lxd provider work15:50
natefinchmgz_: our intention is to have a juju provider that uses lxd in 1.2615:50
mgz_so, what's your plan with the existing backports to trusty scheme?15:51
* mgz_ enjoys circular conversations15:52
mfoordour normal plan is to leave that up to QA to sort out...15:53
mgz_how to release software you're writing is not someone else's problem15:53
natefinchmgz_: it is when someone else is putting up the restrictions while simultaneously telling us to deliver software that has a problem with those restrictions15:53
mgz_you do know those two things are not from me, and are different parties, right?15:54
natefinchmgz_: absolutely.  Sorry if my tone indicated I thought it was your fault.  I know it's not.15:54
mgz_the distro, and sanity in general, limits what we can do in terms of backports15:54
mgz_and mark, and the desire for shiny features, wants everyone to have a great experience15:55
natefinchmgz_: I guess the answer is, people at a higher pay grade are going to have to figure out what to do15:55
natefinchmgz_: the LXD provider will fail gracefully if lxd is not installed... but the code still requires 1.5 to build.15:56
mgz_there's so such thing as a !build for go versions, right...15:56
mgz_we can always do the equivelent in the debian rules, just rm the package15:57
natefinchmgz_: no, but you can just set flags at build time to trigger !build code15:57
natefinchmgz_: however, having the same codebase support both 1.2 and 1.5 would seem to be adding a lot of developer/qa/etc overhead.... but again, that's above my pay grade.15:58
mgz_anyway, the first thing is getting it working well in development15:58
mgz_natefinch: well, it's what we do currently, and isn't too hard15:59
mgz_I know it's anti-go, but python code manages to support multiple *interpreter* versions okay15:59
mgz_trusty has go 1.21. vivid has go 1.33. wily/xenial have go 1.5.116:01
alexisbmgz_, natefinch trusty will need 1.5 for lxd as well as juju16:01
alexisbthe current plan is to work on getting it into backports16:01
alexisbso it can be used both by juju and lxd16:01
mgz_alexisb: actual backports? or srued?16:02
alexisbmgz_, actual backports16:02
alexisbsru not needed16:02
mgz_okay, ace. so, the provider failing neatly is a requirement.16:03
mupBug #1512399 opened: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1512399>16:06
mgz_anyway, this is something to work out early, thanks for asking nate, we do want to know exactly how we're getting the lxc provider distributed.16:10
=== You're now known as ubuntulog2
rogpeppemgz_: do you know whether cookie isolation in CI has been done yet?16:25
mgz_jog set the env var as you'd discussed, not sure it's everywhere it's needed but at least in the obvious place.16:28
mgz_hm, actually that change got reverted16:28
mgz_rogpeppe: gimme a sec, I'll find out.16:28
jogmgz_, It broke other tests16:28
jogolder versions of Juju16:28
mupBug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>17:09
mupBug #1511771 opened: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>17:12
mupBug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>17:15
mupBug #1511771 opened: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>17:18
mupBug #1511771 changed: regression setting tools-metadata-url <blocker> <ci> <regression> <set-env> <juju-core:Triaged> <https://launchpad.net/bugs/1511771>17:21
natefinchericsnow: you mentioned in your review of my better error message PR that I should rebase against either your or wayne's personal branches... I hesitate to rebase against a personal branch. Are you guys going to get one of those things landed soon so I can just rebase against the main lxd branch?17:28
ericsnownatefinch: just waiting for your reviews :)17:28
natefinchericsnow: that the support using local lxd as remote?17:29
ericsnownatefinch: http://reviews.vapour.ws/r/3012/ and http://reviews.vapour.ws/r/3013/17:29
natefinchericsnow: ok, yeah, I'm looking at those now.  Guess it'll be an unofficial review day for me17:30
ericsnownatefinch: thanks17:30
frobwaremfoord, a heads-up on our recent changes to rendering /e/n/i --- https://bugs.launchpad.net/juju-core/+bug/151237117:32
mupBug #1512371: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <bug-squad> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1512371>17:32
natefinchericsnow: gah... saw the copied file from github.com/lxd, so I went to look at their repo for licensing... and they don't even have a LICENSE file.  Geez17:34
ericsnownatefinch: yep17:34
cmarsmgz_, here's a cookie update for 1.25, what do you think? http://reviews.vapour.ws/r/3041/17:39
natefinchericsnow: wow, that lxd/shared.GenCert function is awful.  Have you filed a bug to their project to de-awful it?17:54
ericsnownatefinch: was waiting :)17:54
natefinchericsnow: for what?17:55
ericsnownatefinch: until we had settled down on our LXD provider work17:55
natefinchericsnow: If that's the only way to create certs for LXD, seems pretty awful regardless of what anyone else is doing17:56
ericsnownatefinch: agreed17:57
natefinchericsnow: I'm willing to write a bug now if you'd prefer.17:58
ericsnownatefinch: sure, though I'd prefer the reviews first :)17:58
natefinchericsnow: right right17:58
mfoordfrobware: I saw18:03
mfoordfrobware: ouch18:03
mfoordfrobware: although I don't think it's the recent changes to be fair, I think it's maas 1.918:03
mfoordfrobware: will look tomorrow18:03
davechen1ythumper: afk breakfast20:57
davechen1yi'll call you after taht20:57
mupBug #1512481 opened: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>21:01
mupBug #1512481 changed: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>21:04
mupBug #1512481 opened: register dns names for units in MAAS <juju-core:New> <https://launchpad.net/bugs/1512481>21:07
thumperdavechen1y: ack21:09
cmarshey waigani i'd like to try writing a CI test. where should I start?21:34
waiganicmars: https://github.com/juju/juju/wiki/ci-tests :)21:37
cmarswaigani, thanks21:38
perrito666ah finally, the server holding my irc got cut from part of the world22:33
perrito666(and by cut I mean something sliced the fiber)22:33
mwhudsonperrito666: https://www.reddit.com/r/cablefail/comments/1y2ei8/lost_in_the_woods_call_a_backhoe/cfh4wox22:39
davechen1ythumper: ping23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!