[01:33] <mup> Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090>
[01:36] <mup> Bug #1511090 opened: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090>
[01:39] <mup> Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090>
[02:22] <thumper> ericsnow: around?
[02:29] <thumper> menn0: http://reviews.vapour.ws/r/3018/diff/# a rename PR that I thought was up already
[02:38] <thumper> grrr... FFS
[02:38]  * thumper headdesks
[02:38] <menn0> thumper: ship it
[02:38] <thumper> ta
[02:39] <menn0> thumper: that one should have come with a warning about not operating heavy machine due to drowsiness
[02:39] <menn0> :-p
[02:39] <thumper> :)
[03:05] <natefinch> ericsnow: don't suppose you're around?
[03:36] <thumper> menn0: what watches the allwatcher?
[03:37] <menn0> thumper: what do you mean? what uses it?
[03:37] <thumper> yeah...
[03:37] <thumper> It has a ServerUUID on environmenst
[03:37] <thumper> and I want to rename it :)
[03:38] <menn0> thumper: it's exposed via the apiserver ... primarily used by the GUI
[03:39] <thumper> so... probably no one is looking at the ServerUUID...
[03:39] <thumper> because it is always the same...
[03:39] <thumper> for now at least
[03:40] <menn0> thumper: the reporting of environments was only just added
[03:40] <menn0> for the allenvwatcher
[03:40]  * thumper nods
[03:40] <menn0> thumper: the allwatcher (aka megawatcher) doesn't return environment entities
[03:41] <menn0> thumper: it's only the allenvwatcher
[03:41] <menn0> thumper: you might want to check with rog because he's the only potential user of that right now
[03:41] <menn0> thumper: just let him know it's changing
[03:43] <thumper> I just sent an email to rog and uros saying names are changing
[03:46] <wallyworld> menn0: is it true that when we define a new state doc for a collection, we no longer need EnvUUID   string `bson:"env-uuid"
[03:47] <menn0> wallyworld: that's correct, the underlying multi-env layer will add it
[03:47] <wallyworld> menn0: awesome, and TxnRevno ?
[03:47] <menn0> wallyworld: I have a tech debt item to remove all the existing structs and code the constructs them
[03:48] <wallyworld> ok, i won't add to your burden :-)
[03:48] <menn0> wallyworld: you don't normally put txnrevno on your structs
[03:48] <wallyworld> rightio
[03:48] <menn0> wallyworld: that's a mgo/txn field
[03:48] <wallyworld> indeed
[03:48] <wallyworld> i guess we use it in places
[03:48] <menn0> wallyworld: some places in the code do read it, but they're rare/evil cases
[03:49] <wallyworld> that's what i thought
[03:49] <wallyworld> thanks
[07:10] <mup> Bug #1511235 opened: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235>
[07:13] <mup> Bug #1511235 changed: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235>
[07:16] <mup> Bug #1511235 opened: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235>
[09:09] <dimitern> jam, hey, I wanted to pass an idea by you, if you have 5m..
[09:11] <dimitern> jam, as part of fixing that d-m and d-e --force issue on maas, I'm thinking of adding a few optional methods that a provider can implement if it wants to observe containers - OnContainerIni, OnContainerCreate, OnContainerDestroy
[09:12] <dimitern> jam, those are going to be called at the apiserver side of the provisioner - at the one-time container init step (per container type), during the container broker's StartInstance, and before the broker destroys a container
[09:14] <dimitern> jam, this will give maas and other providers that want to, the ability to hook into those steps and do extra stuff - i.e. in maas, creating/removing a device for the container, allocating IPs from the provider, etc.
[09:26] <jam> dimitern: what is Init vs Create ?
[09:27] <jam> dimitern: and how does the APIServer know the ContainerBroker is doing StartInstance, isn't ContainerBroker part of the machine agent?
[09:28] <dimitern> jam, Init is the one-time container initialization the first time we need to provision a container of a given type, Create is called before actually starting the container (ideally the callback can take the cloudconfig and modify it, as well as the container entity to tweak its config)
[09:30] <dimitern> jam, the apiserver knows we're about to provision a container as the container provisioner, which uses the container broker, will call ContainerManagerConfig on Init and ProvisioningInfo before Start
[09:49] <jam> dimitern: I might call it something like "InitializeContainers" then, but maybe not. not a big deal
[09:51] <jam> dimitern: I don't really think we want side-effects from calling Config, but having the InstanceBroker send an explicit message to theAPI server that its about to start a container is fine
[09:51] <dimitern> jam, I'm ok with finding better names, but the idea is very useful I think - and can decouple provider-specific container management from the provisioner
[09:53] <jam> dimitern: sure
[09:54] <jam> for AMZ we want to be able to grab IP addresses as well
[09:54] <jam> ContainerInit might also be a time when we reconfigure bridges, etc. in the future
[09:54] <dimitern> jam, yeah, and for maas - create a device, possibly allocate an IP as well
[09:58] <dimitern> jam, this is the rough sketch - http://paste.ubuntu.com/12997865/ (in the container package) << fwereade, I'd like your thoughts on this as well - we can topic it during standup
[10:01] <dimitern> jam, fwereade, voidspace, frobware, standup?
[10:02] <jam> omw
[11:18] <frobware> dimitern, voidspace, jam: as utopic is no longer supported do we care that our 'add juju-br0' to /e/n/i does not work?
[11:21] <dimitern> frobware, I'm not sure I follow you - what's utopic specific about that?
[11:21] <frobware> dimitern, the ifup fails.
[11:22] <rogpeppe> anyone know of a tool that can merge Go coverage profiles?
[11:22] <rogpeppe> axw: ^
[11:23] <jam> frobware: I don't think we care if it is broken on U, but it matters if it doesn't work on T or V/W/X
[11:35] <rogpeppe> here's a branch that fixes two outstanding hight-priority juju-core bugs (and makes tools uploading work with macaroons too): http://reviews.vapour.ws/r/3023/; reviews appreciated.
[11:35] <rogpeppe> s/hight/high/
[11:51] <dimitern> frobware, sorry, got distracted with the iter. spreadsheet
[11:52] <dimitern> frobware, ifup juju-br0 fails only on utopic due to what?
[11:53] <frobware> dimitern, no such device
[11:54] <dimitern> frobware, even though juju-br0 is in /e/n/i ?
[11:55] <frobware> dimitern, yes
[11:56] <frobware> dimitern, I didn't look further - perhaps bridge-utils is missing.
[11:56] <dimitern> frobware, but I guess that's because even if /e/n/i has juju-br0, /run/network/ifstate doesn't
[11:56] <frobware> dimitern, possibly; but trusty, vivid, wily are OK
[11:57] <dimitern> frobware, I think we can ignore utopic then :)
[11:57] <voidspace> sounds good to me
[11:57] <frobware> dimitern, I already have.
[11:57] <voidspace> I even managed to upgrade my laptop (one of the few flawless upgrades I've ever done...)
[12:05] <frobware> voidspace, news in your INBOX
[12:06] <voidspace> frobware: I saw, I can pick it up after my current branch is done - but that will mean Monday
[12:06] <perrito666> frobware: you are making a risky bet on how voidspace manages his mail filters :p
[12:06] <frobware> perrito666, I just beame his filter. :)
[12:06] <frobware> s/beam/became/...
[12:06] <voidspace> hah
[12:07] <voidspace> perrito666: if/when I pick it up I'll probably talk to you about it
[12:07] <perrito666> mm, that would be a very interesting feature on mail "make sure this mail stays in  the inbox"
[12:07] <perrito666> voidspace: sure I have all sorts of bad things to say about
[12:07] <frobware> perrito666, about ...
[12:07] <perrito666> the task :)
[12:07] <frobware> perrito666, anything you want to get off your chest. :)
[12:08] <perrito666> nah :)
[12:08] <voidspace> :-)
[12:12] <perrito666> frobware: voidspace none of you is telling me if its off or over :p
[12:13] <frobware> perrito666, https://www.englishforums.com/English/ToHandOverAndToHandOff/bchhkz/post.htm
[12:14] <frobware> perrito666, the slang would be "chucking it over the wall" - and thanks! :)
[12:14] <perrito666> we should all switch to spanish
[12:14] <perrito666> :p
[12:14] <frobware> we should all switch to spanish beer
[12:15] <perrito666> frobware: well for what I have seen in english speakers, beer can give them the idea that they can speak spanish
[12:15] <perrito666> :p
[12:17] <frobware> voidspace, please could you put your last comment in the bug if not already captured -- seems useful info.
[12:17] <voidspace> frobware: ok
[13:50] <jam> dooferlad: dimitern: https://github.com/dooferlad/kvm_maas/pull/2 is my update to the script that is working here (at least for 1 node) with multiple subnets/interfaces
[13:51] <dimitern> jam, nice! I'll give it a try on my vmaas later
[13:51] <jam> the CLI I tested is: ./kmaas.py m1-test1 -s <IP_ADDRESS>/24 -s <IP_ADDRESS>/24 -t dual-nic-template.xml --debug
[13:52] <jam> where <IP_ADDRESS>/24 and <IP_ADDRESS> is registered already in both virt-manager and maas
[13:54] <dimitern> and maas CC is on both of these, but managing only the first one?
[13:58] <jam> dimitern: yeah, CC is managing <IP_ADDRESS>
[13:58] <jam> <IP_ADDRESS> is registerd with virt as an internal-only netwok
[13:58] <dimitern> right, ok
[14:30] <mup> Bug #1511390 opened: Setup of MAAS Server using pod-cloud-installer failing <juju-core:New> <https://launchpad.net/bugs/1511390>
[14:57] <mup> Bug #1511390 changed: Setup of MAAS Server using pod-cloud-installer failing <juju-core:New> <https://launchpad.net/bugs/1511390>
[15:06] <katco> wwitzel3: meeting time
[15:32] <fwereade> natefinch, is this the right diff range: http://reviews.vapour.ws/r/2814/diff/24-26/ ?
[15:40] <fwereade> natefinch, assuming it is, LGTM with a trivial
[15:43] <perrito666> bbl lunch with wife
[15:57] <rogpeppe> please could someone review this change (it fixes two high-priority bugs)? http://reviews.vapour.ws/r/3023/
[15:57] <rogpeppe> ericsnow: ^
[15:57] <ericsnow> rogpeppe: will do
[15:57] <rogpeppe> ericsnow: thanks
[16:18] <rogpeppe> ericsnow: and another little one: http://reviews.vapour.ws/r/3026/
[16:18] <ericsnow> rogpeppe: k
[16:19] <rogpeppe> ericsnow: ta
[16:35] <rogpeppe> ericsnow: responded to your review of http://reviews.vapour.ws/r/3023/
[16:35] <ericsnow> rogpeppe: k
[17:39] <frobware> voidspace, http://reviews.vapour.ws/r/3027/
[17:43] <voidspace> frobware: looking
[17:43] <voidspace> frobware: LGTM
[17:44] <frobware> voidspace, thanks. I forget - to merge this it is just $$merge$$ in the PR?
[17:49] <natefinch> fwereade: that's the right diff, yeah
[17:51] <voidspace> frobware: correct
[17:52] <frobware> voidspace, and because it is not master do I need some incantation with [fixes-xyz]?
[18:01] <alexisb> heh juju core team, meeting?
[18:01] <alexisb> wwitzel3, perrito666, cherylj, natefinch
[18:01] <alexisb> others who are around and it is not there eod
[18:01] <cherylj> brt
[18:02] <voidspace> frobware: no, you only need $$fixes-xyz$$  if the branch you're merging to (including master) is blocked by a critical bug
[18:02] <frobware> voidspace, thanks for the clarification
[18:07] <alexisb> ericsnow, ping
[18:07] <katco> ericsnow: wwitzel3: not coming to the core meeting?
[18:07] <frobware> cherylj, I saw that https://bugs.launchpad.net/ubuntu/+bug/1496972 was just reset to 1.26, but I had already started landing into 1.25.
[18:07] <mup> Bug #1496972: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <kernel-da-key> <network> <juju-core:Triaged
[18:07] <mup> by frobware> <juju-core 1.25:Triaged by frobware> <Ubuntu:Invalid by jsalisbury> <Ubuntu Wily:Invalid by jsalisbury> <https://launchpad.net/bugs/1496972>
[18:08] <cherylj> frobware: I just created a 1.25 task
[18:08] <cherylj> frobware: so it should go into 1.25 and 1.26
[18:08] <frobware> cherylj, it's currently landing in 1.25.... ok
[18:11] <frobware> cherylj, also wondering whether this should go into 1.24
[18:11] <cherylj> frobware: how complex is the fix?
[18:12] <frobware> cherylj, trivial but significant: http://reviews.vapour.ws/r/3027/
[18:15] <ericsnow> rogpeppe: updates to both patches LGTM
[18:16] <rogpeppe> ericsnow: ta!
[18:38] <wwitzel3> katco: was away eating, forgot about it, you all still going?
[18:38] <natefinch> wwitzel3: done now
[18:51] <alexisb> wwitzel3, I figured you were out rolling tractor tires
[19:31] <rogpeppe> mgz_: just reviewed https://github.com/juju/charm/pull/164
[19:33] <mgz_> rogpeppe: they're ignored because I wanted to preserve existing behaviour to make the branch easy to land
[19:33] <rogpeppe> mgz_: ok, fair enough
[19:33] <rogpeppe> mgz_: please add a TODO, then LGTM
[19:33] <mgz_> but it got messed up anyway because callers are so confused
[19:33] <mgz_> rogpeppe: okay
[19:41] <rogpeppe> mgz_: unfortunately this commit in utils breaks some tests in juju-core: e6c1e5206ced12cd6201ad2a488e3df6a245eed4
[19:42] <mgz_> rogpeppe: that's expected, the mass dep bump will need to bring in test changes as well
[19:42] <rogpeppe> mgz_: yeah
[19:42] <rogpeppe> mgz_: i'll stick on the old utils for now then
[19:53] <voidspace> EOW
[19:53] <voidspace> o/
[19:53] <perrito666> voidspace: bye
[20:08] <katco> ericsnow: i'm ready when you are
[21:34] <jog> rogpeppe, looks like a possible regression in the latest CI run on master, related to cookies
[21:34] <rogpeppe> jog: interesting, thanks. i'll take a look.
[21:34] <jog> rogpeppe, I'll open a bug but you can see failures here: http://reports.vapour.ws/releases/rules/735
[21:35] <rogpeppe> jog: ah yes, i knew about that but thought it wouldn't be a problem for CI
[21:35] <rogpeppe> jog: the cookie format has changed
[21:36] <rogpeppe> jog: i did consider ignoring the error
[21:36] <rogpeppe> jog: but thought it was easy enough for people to delete the cookie file if they got that error
[21:37] <rogpeppe> jog: do you know if that CI run is starting with a fresh home dir?
[21:38] <rogpeppe> jog: given that the juju version using the previous format hasn't been released, i am surprised that this is an issue
[21:38] <jog> rogpeppe, we ensure jenv file are removed but I don't think we clean the entire JUJU_HOME
[21:38] <rogpeppe> jog: ah
[21:39] <rogpeppe> jog: that seems like it's an easy way to run into test pollution to me
[21:39] <rogpeppe> jog: i think you should really clean $HOME/.go-cookies before running the tests at the very least
[21:40] <mup> Bug #1511537 opened: Failed to load cookies EOF <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1511537>
[21:40] <rogpeppe> jog: or set $JUJU_COOKIEFILE to something else
[21:41] <jog> rogpeppe, I'm checking our test slaves
[21:41] <rogpeppe> jog: hmm, that bug is another interesting one.
[21:42] <jog> ses just opened that one for something he saw yesterday
[21:42] <rogpeppe> jog: this makes me more inclined to the view that failing to load cookies should just be a warning not an error
[21:43] <rogpeppe> jog: i swithered about that decision when implementing this
[21:43] <jog> where should the .go-cookies file be? In $JUJU_HOME?
[21:43] <rogpeppe> jog: usually in $HOME/.go-cookies
[21:44] <rogpeppe> jog: but $JUJU_COOKIEFILE can place them elsewhere
[21:44] <rogpeppe> jog: how can i find out the commit hash of http://reports.vapour.ws/releases/3230/job/functional-ha-backup-restore/attempt/2766 ?
[21:45] <jog> rogpeppe, there are breadcrumbs at the top of that page. Go back one to http://reports.vapour.ws/releases/3230
[21:45] <jog> you'll see 'Revision ID' with a link near the top
[21:46] <rogpeppe> jog: ah, i didn't realise that grey text was clickable
[21:48] <rogpeppe> jog: i *think* that bug (1511537) has been fixed by the dependency update landed today
[21:49] <jog> rogpeppe, ah... you said in $HOME... .go-cookies is global for the user
[21:49] <rogpeppe> jog: i think the intermittent problem was probably caused by the fact that concurrent juju client instances were stepping one one anothers' toes because the cookie logic wasn't safe for concurrent use
[21:50] <rogpeppe> jog: yes it is (very deliberately)
[21:50] <jog> so we drive multiple tests in parallel from a single slave...
[21:50] <rogpeppe> jog: ok, that makes sense
[21:50] <jog> and they can be varying version of Juju
[21:50] <rogpeppe> jog: do you use a different value of $JUJU_HOME for each running test?
[21:51] <jog> yes
[21:51] <jog> err... no
[21:51] <jog> each test has a unique environment name though
[21:51] <rogpeppe> jog: ok, well you should probably do that. and set JUJU_COOKIEFILE=$JUJU_HOME/cookies
[21:52] <rogpeppe> jog: i mean, it's *supposed* to work ok with everything concurrently, but i think it's probably best to have each test as isolated as possible (i'd probably have a different value of $HOME too)
[21:52] <jog> we have a $JUJU_HOME with an environment.yaml for each to the various clouds and substrates that we test on.
[21:53] <rogpeppe> jog: anyway, this will be more important in the future when you have CI tests that rely on macaroon authorization
[21:57] <jog> rogpeppe, with 75+ tests that's not a trivial change for CI. There is also likely CI driver code that sets $JUJU_HOME. Not that it can't be done but not at the flip of a switch.
[21:57] <rogpeppe> jog: fair enough
[21:57] <rogpeppe> jog: anyway, i hope the intermittent issue should have gone away now
[21:58] <rogpeppe> jog: and deleting the cookie file should cause the CI to succeed OK
[21:58] <rogpeppe> jog: well, at least to fix *that* issue :)
[21:59] <rogpeppe> jog: you could always set JUJU_COOKIEFILE=$(tempfile)
[22:00] <jog> that's that type of change I'm thinking of making in the short term
[22:00] <jog> also are you going to make that a Warning?
[22:03] <rogpeppe> jog: the reason i'm not sure about that is that i'm not sure of the best API for persistent-cookiejar. It seems kind of wrong to not give the caller any info about the fact that loading the cookie jar has failed, but the alternative is returning both a valid cookiejar *and* an error which also seems wrong
[22:04] <rogpeppe> jog: for the time being, i might leave it as an error but if it causes further CI issues, i'll change it
[22:05] <rogpeppe> jog: after all, if it hadn't been an error, we wouldn't have discovered this potential test cross-talk issue
[22:05] <rogpeppe> jog: so it's not all bad :)
[22:16] <mup> Bug #1511543 opened: Unhelpful error message when trying from a location with a full disk <juju-core:Triaged> <https://launchpad.net/bugs/1511543>
[23:05] <axw> rogpeppe: gocov can merge profiles
[23:05] <axw> rogpeppe: not aware of any others


 They have an office in AA http://careers.stackoverflow.com/company/careevolution
[17:28] <jrwren> brousch: best company around. I have dozen friends there.
[17:28] <jrwren> brousch: if I didn't work for canonical, I'd maybe work there.
[17:31] <brousch> Excellent
[17:36] <cscheib> "No defined roles - just malleable, permeable areas of responsibility; e.g.:
[17:36] <cscheib> "
[17:36] <cscheib> that's pretty awesome.
[17:37] <cscheib> is there a way to set an alert for if they open a devopsy role? heh
[17:38] <jrwren> cscheib: honestly, if you are good, they will hire you. If you really want to work there. contact them, tell them what you do and that you want to work with them.
[17:38] <jrwren> cscheib: no defined roles also means that they might not open a role
[17:40] <cscheib> yea
[21:30] <brousch> I sucked
[21:30] <jrwren> brousch: :(
[21:30] <jrwren> brousch: with whom was the interview?
[21:30] <jrwren> brousch: I mean people, not place.
[21:32] <brousch> John umbaugh
[21:32] <jrwren> hrm, i don't think I know him
[21:33] <brousch> I think he's remote from new york
[21:35] <jrwren> ah