[01:33] Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management [01:36] Bug #1511090 opened: MAAS documentation on jujucharms.com incorrectly advised disable network management [01:39] Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management [02:22] ericsnow: around? [02:29] menn0: http://reviews.vapour.ws/r/3018/diff/# a rename PR that I thought was up already [02:38] grrr... FFS [02:38] * thumper headdesks [02:38] thumper: ship it [02:38] ta [02:39] thumper: that one should have come with a warning about not operating heavy machine due to drowsiness [02:39] :-p [02:39] :) [03:05] ericsnow: don't suppose you're around? [03:36] menn0: what watches the allwatcher? [03:37] thumper: what do you mean? what uses it? [03:37] yeah... [03:37] It has a ServerUUID on environmenst [03:37] and I want to rename it :) [03:38] thumper: it's exposed via the apiserver ... primarily used by the GUI [03:39] so... probably no one is looking at the ServerUUID... [03:39] because it is always the same... [03:39] for now at least [03:40] thumper: the reporting of environments was only just added [03:40] for the allenvwatcher [03:40] * thumper nods [03:40] thumper: the allwatcher (aka megawatcher) doesn't return environment entities [03:41] thumper: it's only the allenvwatcher [03:41] thumper: you might want to check with rog because he's the only potential user of that right now [03:41] thumper: just let him know it's changing [03:43] I just sent an email to rog and uros saying names are changing [03:46] 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] wallyworld: that's correct, the underlying multi-env layer will add it [03:47] menn0: awesome, and TxnRevno ? [03:47] wallyworld: I have a tech debt item to remove all the existing structs and code the constructs them [03:48] ok, i won't add to your burden :-) [03:48] wallyworld: you don't normally put txnrevno on your structs [03:48] rightio [03:48] wallyworld: that's a mgo/txn field [03:48] indeed [03:48] i guess we use it in places [03:48] wallyworld: some places in the code do read it, but they're rare/evil cases [03:49] that's what i thought [03:49] thanks [07:10] Bug #1511235 opened: juju-reboot --now defect in 1.24.7 [07:13] Bug #1511235 changed: juju-reboot --now defect in 1.24.7 [07:16] Bug #1511235 opened: juju-reboot --now defect in 1.24.7 [09:09] jam, hey, I wanted to pass an idea by you, if you have 5m.. [09:11] 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] 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] 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] dimitern: what is Init vs Create ? [09:27] dimitern: and how does the APIServer know the ContainerBroker is doing StartInstance, isn't ContainerBroker part of the machine agent? [09:28] 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] 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] dimitern: I might call it something like "InitializeContainers" then, but maybe not. not a big deal [09:51] 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] 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] dimitern: sure [09:54] for AMZ we want to be able to grab IP addresses as well [09:54] ContainerInit might also be a time when we reconfigure bridges, etc. in the future [09:54] jam, yeah, and for maas - create a device, possibly allocate an IP as well [09:58] 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] jam, fwereade, voidspace, frobware, standup? === akhavr1 is now known as akhavr [10:02] omw === akhavr1 is now known as akhavr [11:18] 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] frobware, I'm not sure I follow you - what's utopic specific about that? [11:21] dimitern, the ifup fails. [11:22] anyone know of a tool that can merge Go coverage profiles? [11:22] axw: ^ [11:23] 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] 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] s/hight/high/ [11:51] frobware, sorry, got distracted with the iter. spreadsheet [11:52] frobware, ifup juju-br0 fails only on utopic due to what? [11:53] dimitern, no such device [11:54] frobware, even though juju-br0 is in /e/n/i ? [11:55] dimitern, yes [11:56] dimitern, I didn't look further - perhaps bridge-utils is missing. [11:56] frobware, but I guess that's because even if /e/n/i has juju-br0, /run/network/ifstate doesn't [11:56] dimitern, possibly; but trusty, vivid, wily are OK [11:57] frobware, I think we can ignore utopic then :) [11:57] sounds good to me [11:57] dimitern, I already have. [11:57] I even managed to upgrade my laptop (one of the few flawless upgrades I've ever done...) [12:05] voidspace, news in your INBOX [12:06] frobware: I saw, I can pick it up after my current branch is done - but that will mean Monday [12:06] frobware: you are making a risky bet on how voidspace manages his mail filters :p [12:06] perrito666, I just beame his filter. :) [12:06] s/beam/became/... [12:06] hah [12:07] perrito666: if/when I pick it up I'll probably talk to you about it [12:07] mm, that would be a very interesting feature on mail "make sure this mail stays in the inbox" [12:07] voidspace: sure I have all sorts of bad things to say about [12:07] perrito666, about ... [12:07] the task :) [12:07] perrito666, anything you want to get off your chest. :) [12:08] nah :) [12:08] :-) [12:12] frobware: voidspace none of you is telling me if its off or over :p [12:13] perrito666, https://www.englishforums.com/English/ToHandOverAndToHandOff/bchhkz/post.htm [12:14] perrito666, the slang would be "chucking it over the wall" - and thanks! :) [12:14] we should all switch to spanish [12:14] :p [12:14] we should all switch to spanish beer [12:15] frobware: well for what I have seen in english speakers, beer can give them the idea that they can speak spanish [12:15] :p [12:17] voidspace, please could you put your last comment in the bug if not already captured -- seems useful info. [12:17] frobware: ok [13:50] 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] jam, nice! I'll give it a try on my vmaas later [13:51] the CLI I tested is: ./kmaas.py m1-test1 -s 10.10.0.0/24 -s 10.10.100.1/24 -t dual-nic-template.xml --debug [13:52] where 10.10.0.0/24 and 10.10.100.0 is registered already in both virt-manager and maas [13:54] and maas CC is on both of these, but managing only the first one? [13:58] dimitern: yeah, CC is managing 10.10.0.0 [13:58] 10.10.100.0 is registerd with virt as an internal-only netwok [13:58] right, ok [14:30] Bug #1511390 opened: Setup of MAAS Server using pod-cloud-installer failing [14:57] Bug #1511390 changed: Setup of MAAS Server using pod-cloud-installer failing [15:06] wwitzel3: meeting time [15:32] natefinch, is this the right diff range: http://reviews.vapour.ws/r/2814/diff/24-26/ ? [15:40] natefinch, assuming it is, LGTM with a trivial [15:43] bbl lunch with wife [15:57] please could someone review this change (it fixes two high-priority bugs)? http://reviews.vapour.ws/r/3023/ [15:57] ericsnow: ^ [15:57] rogpeppe: will do [15:57] ericsnow: thanks [16:18] ericsnow: and another little one: http://reviews.vapour.ws/r/3026/ [16:18] rogpeppe: k [16:19] ericsnow: ta [16:35] ericsnow: responded to your review of http://reviews.vapour.ws/r/3023/ [16:35] rogpeppe: k [17:39] voidspace, http://reviews.vapour.ws/r/3027/ [17:43] frobware: looking [17:43] frobware: LGTM [17:44] voidspace, thanks. I forget - to merge this it is just $$merge$$ in the PR? [17:49] fwereade: that's the right diff, yeah [17:51] frobware: correct [17:52] voidspace, and because it is not master do I need some incantation with [fixes-xyz]? [18:01] heh juju core team, meeting? [18:01] wwitzel3, perrito666, cherylj, natefinch [18:01] others who are around and it is not there eod [18:01] brt [18:02] frobware: no, you only need $$fixes-xyz$$ if the branch you're merging to (including master) is blocked by a critical bug [18:02] voidspace, thanks for the clarification [18:07] ericsnow, ping [18:07] ericsnow: wwitzel3: not coming to the core meeting? [18:07] 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] Bug #1496972: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel by frobware> [18:08] frobware: I just created a 1.25 task [18:08] frobware: so it should go into 1.25 and 1.26 [18:08] cherylj, it's currently landing in 1.25.... ok [18:11] cherylj, also wondering whether this should go into 1.24 [18:11] frobware: how complex is the fix? [18:12] cherylj, trivial but significant: http://reviews.vapour.ws/r/3027/ [18:15] rogpeppe: updates to both patches LGTM [18:16] ericsnow: ta! [18:38] katco: was away eating, forgot about it, you all still going? [18:38] wwitzel3: done now [18:51] wwitzel3, I figured you were out rolling tractor tires [19:31] mgz_: just reviewed https://github.com/juju/charm/pull/164 [19:33] rogpeppe: they're ignored because I wanted to preserve existing behaviour to make the branch easy to land [19:33] mgz_: ok, fair enough [19:33] mgz_: please add a TODO, then LGTM [19:33] but it got messed up anyway because callers are so confused [19:33] rogpeppe: okay [19:41] mgz_: unfortunately this commit in utils breaks some tests in juju-core: e6c1e5206ced12cd6201ad2a488e3df6a245eed4 [19:42] rogpeppe: that's expected, the mass dep bump will need to bring in test changes as well [19:42] mgz_: yeah [19:42] mgz_: i'll stick on the old utils for now then [19:53] EOW [19:53] o/ [19:53] voidspace: bye [20:08] ericsnow: i'm ready when you are === mup_ is now known as mup [21:34] rogpeppe, looks like a possible regression in the latest CI run on master, related to cookies [21:34] jog: interesting, thanks. i'll take a look. [21:34] rogpeppe, I'll open a bug but you can see failures here: http://reports.vapour.ws/releases/rules/735 [21:35] jog: ah yes, i knew about that but thought it wouldn't be a problem for CI [21:35] jog: the cookie format has changed [21:36] jog: i did consider ignoring the error [21:36] jog: but thought it was easy enough for people to delete the cookie file if they got that error [21:37] jog: do you know if that CI run is starting with a fresh home dir? [21:38] jog: given that the juju version using the previous format hasn't been released, i am surprised that this is an issue [21:38] rogpeppe, we ensure jenv file are removed but I don't think we clean the entire JUJU_HOME [21:38] jog: ah [21:39] jog: that seems like it's an easy way to run into test pollution to me [21:39] jog: i think you should really clean $HOME/.go-cookies before running the tests at the very least [21:40] Bug #1511537 opened: Failed to load cookies EOF [21:40] jog: or set $JUJU_COOKIEFILE to something else [21:41] rogpeppe, I'm checking our test slaves [21:41] jog: hmm, that bug is another interesting one. [21:42] ses just opened that one for something he saw yesterday [21:42] jog: this makes me more inclined to the view that failing to load cookies should just be a warning not an error [21:43] jog: i swithered about that decision when implementing this [21:43] where should the .go-cookies file be? In $JUJU_HOME? [21:43] jog: usually in $HOME/.go-cookies [21:44] jog: but $JUJU_COOKIEFILE can place them elsewhere [21:44] 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] rogpeppe, there are breadcrumbs at the top of that page. Go back one to http://reports.vapour.ws/releases/3230 [21:45] you'll see 'Revision ID' with a link near the top [21:46] jog: ah, i didn't realise that grey text was clickable [21:48] jog: i *think* that bug (1511537) has been fixed by the dependency update landed today [21:49] rogpeppe, ah... you said in $HOME... .go-cookies is global for the user [21:49] 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] jog: yes it is (very deliberately) [21:50] so we drive multiple tests in parallel from a single slave... [21:50] jog: ok, that makes sense [21:50] and they can be varying version of Juju [21:50] jog: do you use a different value of $JUJU_HOME for each running test? [21:51] yes [21:51] err... no [21:51] each test has a unique environment name though [21:51] jog: ok, well you should probably do that. and set JUJU_COOKIEFILE=$JUJU_HOME/cookies [21:52] 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] we have a $JUJU_HOME with an environment.yaml for each to the various clouds and substrates that we test on. [21:53] jog: anyway, this will be more important in the future when you have CI tests that rely on macaroon authorization [21:57] 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] jog: fair enough [21:57] jog: anyway, i hope the intermittent issue should have gone away now [21:58] jog: and deleting the cookie file should cause the CI to succeed OK [21:58] jog: well, at least to fix *that* issue :) [21:59] jog: you could always set JUJU_COOKIEFILE=$(tempfile) [22:00] that's that type of change I'm thinking of making in the short term [22:00] also are you going to make that a Warning? [22:03] 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] 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] jog: after all, if it hadn't been an error, we wouldn't have discovered this potential test cross-talk issue [22:05] jog: so it's not all bad :) [22:16] Bug #1511543 opened: Unhelpful error message when trying from a location with a full disk [23:05] rogpeppe: gocov can merge profiles [23:05] rogpeppe: not aware of any others