mup | Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090> | 01:33 |
---|---|---|
mup | Bug #1511090 opened: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090> | 01:36 |
mup | Bug #1511090 changed: MAAS documentation on jujucharms.com incorrectly advised disable network management <juju-core:Invalid> <https://launchpad.net/bugs/1511090> | 01:39 |
thumper | ericsnow: around? | 02:22 |
thumper | menn0: http://reviews.vapour.ws/r/3018/diff/# a rename PR that I thought was up already | 02:29 |
thumper | grrr... FFS | 02:38 |
* thumper headdesks | 02:38 | |
menn0 | thumper: ship it | 02:38 |
thumper | ta | 02:38 |
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 | :) | 02:39 |
natefinch | ericsnow: don't suppose you're around? | 03:05 |
thumper | menn0: what watches the allwatcher? | 03:36 |
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:37 |
menn0 | thumper: it's exposed via the apiserver ... primarily used by the GUI | 03:38 |
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:39 |
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:40 |
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:41 |
thumper | I just sent an email to rog and uros saying names are changing | 03:43 |
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:46 |
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:47 |
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:48 |
wallyworld | that's what i thought | 03:49 |
wallyworld | thanks | 03:49 |
mup | Bug #1511235 opened: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235> | 07:10 |
mup | Bug #1511235 changed: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235> | 07:13 |
mup | Bug #1511235 opened: juju-reboot --now defect in 1.24.7 <juju-core:New> <https://launchpad.net/bugs/1511235> | 07:16 |
dimitern | jam, hey, I wanted to pass an idea by you, if you have 5m.. | 09:09 |
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:11 |
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:12 |
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:14 |
jam | dimitern: what is Init vs Create ? | 09:26 |
jam | dimitern: and how does the APIServer know the ContainerBroker is doing StartInstance, isn't ContainerBroker part of the machine agent? | 09:27 |
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:28 |
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:30 |
jam | dimitern: I might call it something like "InitializeContainers" then, but maybe not. not a big deal | 09:49 |
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:51 |
jam | dimitern: sure | 09:53 |
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:54 |
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 | 09:58 |
dimitern | jam, fwereade, voidspace, frobware, standup? | 10:01 |
=== akhavr1 is now known as akhavr | ||
jam | omw | 10:02 |
=== akhavr1 is now known as akhavr | ||
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:18 |
dimitern | frobware, I'm not sure I follow you - what's utopic specific about that? | 11:21 |
frobware | dimitern, the ifup fails. | 11:21 |
rogpeppe | anyone know of a tool that can merge Go coverage profiles? | 11:22 |
rogpeppe | axw: ^ | 11:22 |
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:23 |
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:35 |
dimitern | frobware, sorry, got distracted with the iter. spreadsheet | 11:51 |
dimitern | frobware, ifup juju-br0 fails only on utopic due to what? | 11:52 |
frobware | dimitern, no such device | 11:53 |
dimitern | frobware, even though juju-br0 is in /e/n/i ? | 11:54 |
frobware | dimitern, yes | 11:55 |
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:56 |
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...) | 11:57 |
frobware | voidspace, news in your INBOX | 12:05 |
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:06 |
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:07 |
perrito666 | nah :) | 12:08 |
voidspace | :-) | 12:08 |
perrito666 | frobware: voidspace none of you is telling me if its off or over :p | 12:12 |
frobware | perrito666, https://www.englishforums.com/English/ToHandOverAndToHandOff/bchhkz/post.htm | 12:13 |
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:14 |
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:15 |
frobware | voidspace, please could you put your last comment in the bug if not already captured -- seems useful info. | 12:17 |
voidspace | frobware: ok | 12:17 |
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:50 |
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 10.10.0.0/24 -s 10.10.100.1/24 -t dual-nic-template.xml --debug | 13:51 |
jam | where 10.10.0.0/24 and 10.10.100.0 is registered already in both virt-manager and maas | 13:52 |
dimitern | and maas CC is on both of these, but managing only the first one? | 13:54 |
jam | dimitern: yeah, CC is managing 10.10.0.0 | 13:58 |
jam | 10.10.100.0 is registerd with virt as an internal-only netwok | 13:58 |
dimitern | right, ok | 13:58 |
mup | Bug #1511390 opened: Setup of MAAS Server using pod-cloud-installer failing <juju-core:New> <https://launchpad.net/bugs/1511390> | 14:30 |
mup | Bug #1511390 changed: Setup of MAAS Server using pod-cloud-installer failing <juju-core:New> <https://launchpad.net/bugs/1511390> | 14:57 |
katco | wwitzel3: meeting time | 15:06 |
fwereade | natefinch, is this the right diff range: http://reviews.vapour.ws/r/2814/diff/24-26/ ? | 15:32 |
fwereade | natefinch, assuming it is, LGTM with a trivial | 15:40 |
perrito666 | bbl lunch with wife | 15:43 |
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 | 15:57 |
rogpeppe | ericsnow: and another little one: http://reviews.vapour.ws/r/3026/ | 16:18 |
ericsnow | rogpeppe: k | 16:18 |
rogpeppe | ericsnow: ta | 16:19 |
rogpeppe | ericsnow: responded to your review of http://reviews.vapour.ws/r/3023/ | 16:35 |
ericsnow | rogpeppe: k | 16:35 |
frobware | voidspace, http://reviews.vapour.ws/r/3027/ | 17:39 |
voidspace | frobware: looking | 17:43 |
voidspace | frobware: LGTM | 17:43 |
frobware | voidspace, thanks. I forget - to merge this it is just $$merge$$ in the PR? | 17:44 |
natefinch | fwereade: that's the right diff, yeah | 17:49 |
voidspace | frobware: correct | 17:51 |
frobware | voidspace, and because it is not master do I need some incantation with [fixes-xyz]? | 17:52 |
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:01 |
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:02 |
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:07 |
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:08 |
frobware | cherylj, also wondering whether this should go into 1.24 | 18:11 |
cherylj | frobware: how complex is the fix? | 18:11 |
frobware | cherylj, trivial but significant: http://reviews.vapour.ws/r/3027/ | 18:12 |
ericsnow | rogpeppe: updates to both patches LGTM | 18:15 |
rogpeppe | ericsnow: ta! | 18:16 |
wwitzel3 | katco: was away eating, forgot about it, you all still going? | 18:38 |
natefinch | wwitzel3: done now | 18:38 |
alexisb | wwitzel3, I figured you were out rolling tractor tires | 18:51 |
rogpeppe | mgz_: just reviewed https://github.com/juju/charm/pull/164 | 19:31 |
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:33 |
rogpeppe | mgz_: unfortunately this commit in utils breaks some tests in juju-core: e6c1e5206ced12cd6201ad2a488e3df6a245eed4 | 19:41 |
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:42 |
voidspace | EOW | 19:53 |
voidspace | o/ | 19:53 |
perrito666 | voidspace: bye | 19:53 |
katco | ericsnow: i'm ready when you are | 20:08 |
=== mup_ is now known as mup | ||
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:34 |
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:35 |
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:36 |
rogpeppe | jog: do you know if that CI run is starting with a fresh home dir? | 21:37 |
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:38 |
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:39 |
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:40 |
jog | rogpeppe, I'm checking our test slaves | 21:41 |
rogpeppe | jog: hmm, that bug is another interesting one. | 21:41 |
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:42 |
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:43 |
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:44 |
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:45 |
rogpeppe | jog: ah, i didn't realise that grey text was clickable | 21:46 |
rogpeppe | jog: i *think* that bug (1511537) has been fixed by the dependency update landed today | 21:48 |
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:49 |
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:50 |
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:51 |
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:52 |
rogpeppe | jog: anyway, this will be more important in the future when you have CI tests that rely on macaroon authorization | 21:53 |
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:57 |
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:58 |
rogpeppe | jog: you could always set JUJU_COOKIEFILE=$(tempfile) | 21:59 |
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:00 |
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:03 |
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:04 |
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:05 |
mup | Bug #1511543 opened: Unhelpful error message when trying from a location with a full disk <juju-core:Triaged> <https://launchpad.net/bugs/1511543> | 22:16 |
axw | rogpeppe: gocov can merge profiles | 23:05 |
axw | rogpeppe: not aware of any others | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!