| menn0 | thumper, wallyworld: for the record, using a abstract domain socket path like "@juju-mutex-" doesn't work | 00:51 |
|---|---|---|
| mup | Bug #1610239 changed: Race in src/gopkg.in/mgo.v2 <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1610239> | 00:51 |
| wallyworld | sad trombone | 00:51 |
| menn0 | wallyworld: in fact, I can't even get it to work if I patch the path prefix to "/var/snap/juju-menno/current/mutux-" | 00:52 |
| wallyworld | hmmmm, well that is unfortunate | 00:53 |
| wallyworld | looks like we do need an interface | 00:53 |
| menn0 | which makes sense... I don't think the path is an issue. it might be that juju isn't being allowed to use abstract domain sockets at all | 00:53 |
| thumper | menn0: damn | 00:53 |
| menn0 | wallyworld: thumper: installing with --devmode works though | 00:57 |
| wallyworld | yep | 00:57 |
| menn0 | that will do for my immediate use | 00:57 |
| mup | Bug #1555969 changed: API server stops responding after juju add-unit <canonical-is> <juju-core:Won't Fix> <https://launchpad.net/bugs/1555969> | 01:30 |
| mup | Bug #1449044 opened: juju add-unit resets AWS security groups <add-unit> <ec2-provider> <security> <juju-core:New> <https://launchpad.net/bugs/1449044> | 01:30 |
| menn0 | wallyworld: looks like the snappy developer namespace is used after all | 01:41 |
| wallyworld | oh, right, ok | 01:41 |
| menn0 | wallyworld: i've just uploaded my snap and the name in the store is now "juju-menno.menno" (where .menno is the developer namespace) | 01:42 |
| menn0 | wallyworld: so including your own suffix in the name isn't really necessary | 01:42 |
| wallyworld | menn0: ah, did try that (juju.wallyworld) but still got a clash | 01:42 |
| wallyworld | i think it's all a bit in flux | 01:43 |
| menn0 | wallyworld: ok fair enough... maybe there's still a global check | 01:43 |
| veebers | Am I doing something wrong or does the cs:ubuntu application have no content in status or anything? I want to know when it's gone/cleaned up | 01:44 |
| menn0 | wallyworld: actually... I have no idea what's going on - I get "snap not found" when I try to install juju-menno or juju-menno.menno | 01:46 |
| menn0 | wallyworld: the store website says it's there and published though | 01:46 |
| wallyworld | menn0: you need to use --devmode | 01:46 |
| menn0 | wallyworld: I am | 01:46 |
| wallyworld | and --edge | 01:46 |
| menn0 | sudo snap install juju-menno --edge --devmode | 01:46 |
| wallyworld | get rid of the dev namespace, that screwed me up as well | 01:47 |
| menn0 | wallyworld: i'll ask on #snappy in case there's something i'm doing wrong | 01:50 |
| wallyworld | or u1-internal | 01:50 |
| menn0 | ok | 01:51 |
| menn0 | wallyworld: why u1-internal? | 02:04 |
| mwhudson | wallyworld: hey juju-mongodb2.6 is just there for upgrades, right? | 02:34 |
| mwhudson | wallyworld: can we lose it from yakkety? | 02:34 |
| wallyworld | mwhudson: yeah, and now that we wil not be upgrading from 1.25 to 2.0 directly, but via model migration, we don't even need it t all | 02:35 |
| mwhudson | wallyworld: this is the best kind of bugix | 02:35 |
| mwhudson | *bugfix | 02:35 |
| wallyworld | yep :-) | 02:35 |
| mwhudson | fixing mongo 3.2 seems not too bad | 02:35 |
| mwhudson | wallyworld: can you comment to this effect on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb2.6/+bug/1610778 | 02:37 |
| mup | Bug #1610778: please remove this package from yakkety <juju-mongodb2.6 (Ubuntu):New> <https://launchpad.net/bugs/1610778> | 02:37 |
| wallyworld | ok | 02:38 |
| mwhudson | wallyworld: do we need juju-mongodb (i.e. 2.4) in yakkety? | 02:41 |
| wallyworld | only if we need to support juju 1.25 in yajjety | 02:41 |
| wallyworld | which i think we do as we have committed to 12 (or 18?) months of support | 02:42 |
| wallyworld | but that should be confirmed | 02:42 |
| axw | veebers: does QA have a vsphere set up that I can test some changes with? | 02:49 |
| mwhudson | wallyworld: ok | 02:50 |
| veebers | axw: I'm not sure off the top of my head, let me have a look | 03:03 |
| veebers | axw: is vsphere known as anything else? | 03:05 |
| axw | veebers: vmware vsphere? | 03:05 |
| axw | veebers: not that I know of otherwise... | 03:05 |
| axw | I'm not very familiar with vmware tools tho | 03:05 |
| veebers | axw: sorry the only thing close to a mention I can see is "VMware vCenter Server Appliance" | 03:06 |
| axw | veebers: that might be it | 03:06 |
| axw | wallyworld: do you know about vsphere? | 03:06 |
| wallyworld | no :-( | 03:06 |
| wallyworld | that was eric et al | 03:06 |
| axw | veebers: I don't see anything about it in cloud-city, so I guess it's not part of CI at the moment... | 03:09 |
| veebers | axw I saw that mention in consoles.txt but that's all, I don't know if or how it's used. | 03:09 |
| axw | veebers: no worries, thanks for checking | 03:10 |
| veebers | axw: sorry I couldn't be immediately helpful. I'll follow up tonight/tomorrow if we don't come across anything else | 03:10 |
| veebers | axw: would you have any insight to my previous query re: status and cs:ubuntu application? | 03:10 |
| axw | veebers: sorry, which query was that? | 03:11 |
| veebers | axw: I'm unable to see any status re: the cs:ubuntu charm/application. i.e. I want to see if it's been removed, but I can't seem to see it when It's been deployed | 03:12 |
| axw | veebers: don't know sorry. you didn't rename the app (juju deploy cs:ubuntu <something-else>)? which user is the test logged in as when running status? | 03:14 |
| veebers | axw: (this is for the test) I do rename the application to a timestamp, but don't see it mentioned in any status. The user is the one that just successfully deployed it (not sure at the moment which it is) | 03:15 |
| veebers | I just know that if it happens quick it errors due to "the application 'ubuntu' is already deloyed" | 03:15 |
| axw | veebers: you're definitely deploying to and running status on the same model? | 03:17 |
| axw | veebers: if you push your branch I might spot something, otherwise I'm stabbing in the dark | 03:18 |
| veebers | axw ack, let me dig around a bit so I have answers for you. | 03:18 |
| thumper | http://reviews.vapour.ws/r/5388/ | 03:48 |
| thumper | menn0: if you feel like a break ^^^ | 03:48 |
| mup | Bug #1595155 changed: new systemd and dbus dependencies are broken <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1595155> | 03:49 |
| menn0 | thumper: i'll get there soon... want to finish battling with this snap first | 04:02 |
| veebers | axw: btw I figured out what I needed to do :-) | 04:06 |
| axw | veebers: cool | 04:07 |
| anastasiamac | axw: talking about vsphere :) | 04:30 |
| axw | anastasiamac: ? | 04:30 |
| anastasiamac | axw: bug 1588390 has a question about how to specify host and datacentre.. | 04:30 |
| mup | Bug #1588390: 2.0 beta7: can't bootstrap with vsphere cloud provider - ERROR invalid config: host: expected string, got nothing <oil> <oil-2.0> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1588390> | 04:30 |
| anastasiamac | axw: could u comment? | 04:31 |
| axw | anastasiamac: sure | 04:31 |
| anastasiamac | axw: \o/ | 04:31 |
| thumper | menn0: ack | 04:32 |
| mup | Bug #1575797 changed: AddressableContainerSetupSuite.TestContainerInitialised lxc-net: no such file or directory <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1575797> | 04:34 |
| mup | Bug #1592366 changed: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366> | 04:37 |
| menn0 | wallyworld: I've just emailed you with those instructions, can you try running through them please? | 04:50 |
| wallyworld | ok | 04:50 |
| mup | Bug #1592366 opened: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366> | 04:52 |
| menn0 | thumper: ship it | 04:56 |
| veebers | wallyworld, axw: Re: model config tree. Does this start of a test plan make sense? Does it cover concerns? https://pastebin.canonical.com/162579/ | 05:02 |
| wallyworld | veebers: yes, but you really need to set up an environment with controller defaults also, using clouds.yaml | 05:04 |
| mup | Bug #1592366 changed: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366> | 05:04 |
| axw | veebers: as a start, I think so. we'll also want to cover controller- and region-inherited config | 05:04 |
| wallyworld | and you also need to check the dynamic nature of the source values | 05:04 |
| wallyworld | ie a value may come from "model" but if the controller default is changed to match, it will say "controller" | 05:05 |
| veebers | wallyworld, axw; good feedback. Is there any docs re: the region stuff? | 05:05 |
| wallyworld | only the spec | 05:05 |
| veebers | ack | 05:05 |
| wallyworld | https://docs.google.com/document/d/1PWUwx9kITQajQQgvHnweUuqTGmBo9p35bVwd-uLKAi4/edit?ts=57626636 | 05:06 |
| mup | Bug #1524572 changed: Azure provider: bootstrap results in error "PUT request failed: BadRequest - XML Schema validation error in network configuration at line 24,18." <azure-provider> <bootstrap> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1524572> | 05:07 |
| wallyworld | menn0: something's wrong, after the controllers got set up (looking at watch and running the setup script), there's no juju home created under ~/snap/juju-menno and the controllers can't be found | 05:15 |
| axw | veebers: do you know which, if any, of the QA MAASes I can use to test a bootstrap change? | 05:19 |
| veebers | axw: I should but I don't sorry :-\ that's 0-2 for today | 05:20 |
| axw | veebers: no worries :) | 05:20 |
| veebers | axw: I see "munna-maas-slave (A machine capable of running kvm, and maas 1.9)" in the agent configs, but that's as much as I can tell from there | 05:21 |
| axw | veebers: yeah just don't want to step on anyone's toes | 05:21 |
| veebers | axw: I've given myself 2 action points to sort out for tomorrow (vsphere and maas). I'll add that to the information that I intend to add to the wiki etc. | 05:23 |
| axw | veebers: thanks :) | 05:23 |
| menn0 | wallyworld: hmmmm... works for me... are you running juju-menno.juju instead of plain old juju? | 05:29 |
| wallyworld | menn0: i tried juju as well | 05:29 |
| wallyworld | but how could plain juju work? | 05:29 |
| wallyworld | the snap doesn't write to ~/.local/share/juju | 05:30 |
| menn0 | wallyworld: indeed. I was making sure you *weren't* running juju | 05:31 |
| wallyworld | menn0: right | 05:31 |
| menn0 | wallyworld: I'm just running through the instructions again. | 05:31 |
| wallyworld | the email says "juju", but i did use /snap/bin/juju-menno.juju | 05:31 |
| menn0 | wallyworld: so the boostrap starts? | 05:32 |
| wallyworld | yeah, and the watch output is fine. then when I ^C once everything is started, there's nothing there | 05:32 |
| wallyworld | well, there's a ssh file but no controller.yaml | 05:33 |
| wallyworld | ssh directory | 05:33 |
| wallyworld | i'll try again | 05:33 |
| menn0 | I get all the usual stuff in ./juju-menno/2/snap/juju-menno/2/.local/share/juju | 05:33 |
| wallyworld | yeah, all i got was an ssh directory | 05:34 |
| menn0 | wtf | 05:34 |
| wallyworld | menn0: there's an extra level of directories | 05:35 |
| wallyworld | ls ~/snap/juju-menno/2/snap/juju-menno/2/.local/share/juju/ | 05:35 |
| wallyworld | that has all the stuff in it | 05:35 |
| menn0 | wallyworld: yep, that's where everything is | 05:36 |
| wallyworld | when i run juju from snap, everything is in ~/snap/juju-wallyworld/2/.local/share/juju | 05:36 |
| wallyworld | yours has an extra bit of the path duplicated | 05:36 |
| wallyworld | and in ~/snap/juju-menno/2/.local/share/juju i have just an ssh dir | 05:37 |
| wallyworld | maybe it's a race or something starting 2 controllers at the same time? | 05:37 |
| menn0 | I wonder if it's because the setup script is in the snap and is running another thing in the snap | 05:38 |
| menn0 | I might just distribute the script separately if that's the case | 05:39 |
| anastasiamac | mwhudson: the bug 1570650 u commented on deals specifically with 2.6 for 1.25 on xenial... could u please clarifywhy you think that yakkety approach is inconsistent with this bug? | 05:39 |
| mup | Bug #1570650: Use juju-mongodb2.6 for 1.25 on xenial <local-provider> <packaging> <juju-core:Fix Released> <juju-core 1.25:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1570650> | 05:39 |
| menn0 | wallyworld: I've got to stop for now but I'll play around with it some more later on | 05:40 |
| menn0 | wallyworld: thanks for trying it out | 05:40 |
| wallyworld | menn0: no worries, i'll try again later if i can, try starting one controller at a time | 05:41 |
| wallyworld | anastasiamac: 1.25 is only getting critical fixes. i doubt upgrading mongo is a critical fix, but i could be wrong | 05:42 |
| wallyworld | and i think 1.25 support is xenial or trusty only, but again, i could be wrong | 05:42 |
| anastasiamac | wallyworld: i completely agree. did u read the bug? | 05:44 |
| wallyworld | i did, may have misunderstood it. it seems to be asking for cganges to 1.25 to support mongo 2.6 | 05:45 |
| anastasiamac | wallyworld: so if this fix goes into 1.25 is yet to b decided by leads. my question ws with respect to michael's commnet about yakkety :) | 05:46 |
| anastasiamac | wallyworld: m not sure how this relates to whther we r going to suport mongo2.6 on 1.25 on xenial and wanted to clarify in case I missed something: "Ian just told me that it would be safe to remove juju-mongodb2.6 from | 05:48 |
| anastasiamac | yakkety, which seems inconsistent with this." | 05:48 |
| wallyworld | ok. i very much doubt we'll be expending effort on mongo 2.6 in 1.25,unless people have changed their minds or we get a bunch of new resources | 05:48 |
| anastasiamac | wallyworld: this decision is not related to my question | 05:48 |
| wallyworld | yeah, i'm a bit confused by the "inconsistent" bit | 05:50 |
| anastasiamac | wallyworld: the bug is about xenial. why are mentioing yakkety here? | 05:50 |
| wallyworld | don't know | 05:50 |
| anastasiamac | wallyworld: k. i'll ask Michael tomorrow ;0 NZ must be coming offline \o/ | 05:50 |
| veebers | wallyworld: There is support for --upload-tools within juju-ci-tools, the abrupt removal of it would trip up some tests. | 05:56 |
| wallyworld | veebers: yeah, i grepped the source just before, i'll add an alias | 05:56 |
| wallyworld | thanks for looking, doesn't look like there's too much to change, but it will take some time | 05:56 |
| veebers | wallyworld: ah sorry had meant to get back to you earlier. You intend to fully remove it at some poitn? | 05:56 |
| veebers | no, not much to change, but might need some mechanism to make it backwards compat. | 05:57 |
| wallyworld | yeah, once everyone agrees, right now it's a spike | 05:57 |
| wallyworld | we have a mechanism for 1.25 vs 2.0 tests i think | 05:57 |
| veebers | wallyworld: Ah ok. If you could ping the qa list closer to the time to warn of intentions (i.e. we intend to remove/rename/revamp upload-tools arg within x time) | 05:58 |
| wallyworld | veebers: on my list - en email will be going to a wider audience than just qa | 05:58 |
| veebers | yeah there is (also, every beta revision release too) | 05:58 |
| veebers | wallyworld: awesome, thanks. | 05:59 |
| veebers | axw, wallyworld: what requirements (config, cloud etc.) is required to get the regional config tree options? i.e. the apt-mirror example in the spec: | 06:20 |
| veebers | Attribute Default Controller | 06:20 |
| veebers | apt-mirror: archive.ubuntu.com - | 06:20 |
| veebers | aws/us-east-1: us-east-1.aws.ubuntu.com - | 06:20 |
| axw | veebers: I don't think it's implemented yet -- right wallyworld? | 06:21 |
| axw | veebers: yeah, the initial work is still pending: http://reviews.vapour.ws/r/5339/ | 06:22 |
| wallyworld | veebers: yep, still wip | 06:22 |
| wallyworld | only the controller inherited config is done | 06:22 |
| veebers | ah ok, I'll ask that question at a later date then :-) | 06:22 |
| wallyworld | veebers: what's done is documented in the release notes, as is what is still todo | 06:22 |
| veebers | Ok, I'm just trying to figure out the clouds.yaml and how it can be used in a test | 06:23 |
| wallyworld | release notes contain that info too | 06:23 |
| veebers | are latest release notes always found here: https://jujucharms.com/docs/devel/temp-release-notes | 06:24 |
| veebers | hmm, nvm. I see that it is | 06:27 |
| veebers | wallyworld: Cool, the release notes pretty much outline a test where having a controller default, setting it to a model value then unsetting should revert back to the controller value (not the default) | 06:35 |
| wallyworld | veebers: yep, but there's then additional nuances. eg change a controller value to be the same/different to a model value and see the source get updated each time model-config is run; create new models with different varioations of config etc | 06:37 |
| mup | Bug # changed: 1402696, 1568181, 1568185, 1568190 | 06:37 |
| veebers | wallyworld: how does one change a controller value after a bootstrap? Or is it always read from clouds.yaml? | 06:39 |
| wallyworld | juju set-model-default | 06:39 |
| veebers | that sets a controller default? or am I getting confused | 06:40 |
| wallyworld | also juju unset-model-default | 06:40 |
| veebers | there is base default config, model config and controller config right? | 06:40 |
| wallyworld | it sets the default value for a model attribute, which just happens to be a controller wide default | 06:40 |
| wallyworld | it will grow the ability to set a region default also when that bit is done | 06:41 |
| wallyworld | juju set-model-default --region=us-east-1 http-proxy=foo | 06:41 |
| wallyworld | or something liek that | 06:41 |
| veebers | ah ok. | 06:41 |
| veebers | I'll update that testplan I shared earlier and bother you again about it tomorrow :-) | 06:42 |
| wallyworld | there's current 3 sources of model config: default, controller, model | 06:42 |
| wallyworld | it will soon be 4 | 06:42 |
| wallyworld | the order goes: default, controller, region, model | 06:42 |
| === frankban|afk is now known as frankban | ||
| mup | Bug #1605770 changed: firewallerSuite.TearDownTest inst.Dial() failed <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1605770> | 07:07 |
| mup | Bug #1610260 changed: AWS Error fetching security groups EOF/timeout <bootstrap> <ec2-provider> <intermittent-failure> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1610260> | 07:07 |
| mup | Bug #1610880 opened: Downloading container templates fails in manual environment <juju-core:New> <https://launchpad.net/bugs/1610880> | 08:01 |
| dimitern | fwereade__: hey, do you think upgrading from e.g. 2.0-beta14.1 to 2.0-beta14 should be allowed? | 09:02 |
| dimitern | fwereade__: currently the upgrader does not compare patch or build numbers when deciding to upgrade (or downgrade, which is more puzzling - see allowedTargetVersion's doc comment in worker/upgrader/upgrader.go | 09:03 |
| dimitern | fwereade__: i.e. I was wondering if there's a good reason not to just compare versions with version.Number.Compare() in the upgrader | 09:05 |
| fwereade__ | dimitern, thinking... but *mainly* thinking that if we're not supporting upgrades during beta it's somewhat moot | 09:06 |
| babbageclunk | fwereade__, dimitern: take another look at http://reviews.vapour.ws/r/5365? | 09:07 |
| dimitern | fwereade__: the issue I'm trying to fix is outlined in bug 1607749 | 09:07 |
| mup | Bug #1607749: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too) <bootstrap> <maas-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1607749> | 09:07 |
| dimitern | babbageclunk: will do in a bit | 09:07 |
| dimitern | fwereade__: weird case I agree, but it did still expose that wrinkle of the upgrading logic | 09:08 |
| dimitern | fwereade__: bootstrapping with --upload-tools from a released client binary triggers it | 09:08 |
| fwereade__ | dimitern, so I *think* what triggers it is just having a mismatch between the tools we bootstrap with and the tools we record ourselves as having bootstrapped with, right? | 09:10 |
| fwereade__ | dimitern, and so I guess --upload-tools from a released client will do that? but instant-upgrade-on-bootstrap is something we haven't done for years | 09:11 |
| dimitern | fwereade__: I think it's the difference between version.Current and having FORCE-VERSION | 09:12 |
| dimitern | even though --upgrade-tools adds the latter to fake it's .1, the binary version is still sans that .1 | 09:12 |
| fwereade__ | dimitern, well, maybe, but why aren't we recording the same tools version that we're eploying? | 09:12 |
| fwereade__ | dimitern, where does it think the binary version doesn't have the .1? it looks to me like the version we recorded in state doesn't have the .1 | 09:14 |
| dimitern | fwereade__: I don't know yet - still digging, but ISTM not considering versions with different patch and build number equal in the upgrader will fix the symptom | 09:14 |
| fwereade__ | dimitern, am super-confused: ISTM that the upgrader *is* quite reasonably and correctly considering the versions to be different | 09:15 |
| dimitern | fwereade__: and there's bootstrap --auto-upgrade as well (false by default), totally not taken into account AFAICS | 09:15 |
| dimitern | fwereade__: well: INFO juju.worker.upgrader upgrader.go:199 upgrade requested from 2.0-beta12.1 to 2.0-beta12 - doesn't that look weird to you? | 09:16 |
| fwereade__ | dimitern, looks like it's doing exactly the right thing | 09:16 |
| fwereade__ | dimitern, saw local version, server said it should run a different version, trying to do that | 09:17 |
| fwereade__ | dimitern, the problem there is the server asking us to change in the first place | 09:17 |
| dimitern | fwereade__: ok, then I'll keep digging - wanted to confirm that's the correct behavior in the upgrader | 09:17 |
| fwereade__ | dimitern, fwiw, don't have a strong position on --auto-upgrade -- if we make sure we have the proxy settings inited from agent config, I don't see why that wouldn't work | 09:19 |
| dimitern | fwereade__: I've verified the proxy settings are populated (into ~/.juju-proxy) on agents | 09:19 |
| fwereade__ | dimitern, ok... does that mean that the agent always uses them? | 09:21 |
| dimitern | fwereade__: that's what I'm trying to figure out now :) | 09:22 |
| anastasiamac | dimitern: fwereade__: in beta14, there was a fix for --upload-tools and build version mismatches... seee https://bugs.launchpad.net/juju-core/+bug/1605050 | 09:22 |
| fwereade__ | dimitern, I don't see why it would | 09:22 |
| mup | Bug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools <sts> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1605050> | 09:22 |
| dimitern | fwereade__: btw the origAgentVersion in the upgrader comes as PreviousAgentVersion, via agentconfig.UpgradedToVersion() | 09:22 |
| dimitern | anastasiamac: cheers - i'll look there as well | 09:23 |
| anastasiamac | dimitern: \o/ | 09:23 |
| dimitern | anastasiamac: I see you've been on fire closing 1.25 bugs :) | 09:23 |
| anastasiamac | not closing....just brooming the house a bit.. | 09:23 |
| anastasiamac | :) | 09:23 |
| dimitern | anastasiamac: ;) nice to see the count going down though! | 09:25 |
| fwereade__ | dimitern, AFAICS the heart of the problem is that the *server* is asking us to upgrade | 09:30 |
| fwereade__ | dimitern, it looks like we have the right binary and the right config on the agent | 09:30 |
| dimitern | fwereade__: I think anastasiamac nailed it - the discrepancy seems to be fixed with tim's PR https://github.com/juju/juju/pull/5879/files | 09:31 |
| dimitern | to confirm that I'll try the same scenario, but with the next beta | 09:31 |
| fwereade__ | dimitern, sweet | 09:32 |
| dimitern | \o/ | 09:41 |
| dimitern | fwereade__, anastasiamac: it works in beta14, so indeed a dup of bug 1605050! thanks for the help ;) | 09:42 |
| mup | Bug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools <sts> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1605050> | 09:42 |
| anastasiamac | dimitern: :) m glad! | 09:42 |
| macgreagoir | win 17 | 09:45 |
| macgreagoir | bah | 09:45 |
| mup | Bug #1607749 changed: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too) <bootstrap> <maas-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1607749> | 09:53 |
| dimitern | sorry babbageclunk I'm on to your PR now | 09:53 |
| babbageclunk | dimitern: thanks, no worries | 09:54 |
| menn0 | fwereade: reviews done | 09:56 |
| fwereade | menn0, tyvm | 10:03 |
| fwereade | menn0, re unit tests -- I'm basically seeing this as a pure internal refactor that doesn't really want new tests because it doesn't change behaviour | 10:08 |
| fwereade | menn0, what tests would you write that aren't just this-input-produces-this-output, who-knows-what-it-means-or-does? | 10:09 |
| menn0 | fwereade: ok fair enough. | 10:09 |
| menn0 | fwereade: some of those methods /are/ conditional ... but I see your point | 10:09 |
| fwereade | menn0, restate conditional please? | 10:11 |
| menn0 | fwereade: sorry, they have conditional logic which could perhaps warrant a test | 10:12 |
| menn0 | fwereade: doing different things depending on what's in the DB | 10:12 |
| fwereade | menn0, yeah | 10:13 |
| fwereade | menn0, how about if I do a pass for the externally-visible impact of same and make sure we have suitable hooks tests? | 10:13 |
| menn0 | fwereade: sgtm | 10:14 |
| fwereade | menn0, cheers | 10:14 |
| dimitern | babbageclunk: reviewed | 10:31 |
| babbageclunk | dimitern: Thanks! | 10:31 |
| rick_h_ | morning | 11:17 |
| anastasiamac | rick_h_: \o/ | 11:24 |
| mup | Bug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390> | 11:29 |
| mup | Bug #1598390 opened: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390> | 11:35 |
| mup | Bug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390> | 11:38 |
| fwereade | babbageclunk, dimitern: sorry, I had a couple of comments on the review but I didn't hit post | 11:54 |
| babbageclunk | fwereade: cool, thanks | 12:25 |
| === petevg_vacation is now known as petevg | ||
| rick_h_ | macgreagoir: welcome back, good week? | 13:06 |
| macgreagoir | rick_h_: It was, thanks. Week of sun! | 13:07 |
| rick_h_ | macgreagoir: added some small "get back in the flow of things" bugs your way on the kanban board | 13:07 |
| rick_h_ | macgreagoir: please take a look when you're through email and looking for next task | 13:07 |
| macgreagoir | rick_h_: Noted :-) I have been trying to catch up. | 13:08 |
| rick_h_ | macgreagoir: all good, wheeeee | 13:08 |
| rick_h_ | natefinch: katco macgreagoir dimitern ping for standup | 14:00 |
| dimitern | omw | 14:01 |
| rogpeppe | hmm, git blame is becoming less useful. What is "Juju bot" doing as an author in apiserver/network.go ? | 14:15 |
| rick_h_ | katco: <3 I went to create a tracking card and it yelled at me that the id already existed | 14:24 |
| rick_h_ | dimitern: if can you please look at http://reviews.vapour.ws/r/4684/ and see if it still applies and if so work to get it landed? | 14:25 |
| dimitern | rick_h_: sure, added to my list | 14:26 |
| rick_h_ | ty dimitern | 14:26 |
| katco | rick_h_: np | 14:27 |
| rick_h_ | fwereade: and added the one you were reviewing from eric into the review land if you can peek at that please and see if it still applies at all. | 14:29 |
| rogpeppe | fwereade: ping | 14:48 |
| mup | Bug #1610990 opened: list-storage in aws contains non-created items <blocker> <ci> <regression> <storage> <juju-ci-tools:Incomplete> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1610990> | 14:51 |
| mup | Bug #1610993 opened: UnitSuite.TestWorkers timed out waiting for workers <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1610993> | 14:51 |
| === natefinch is now known as natefinch-afk | ||
| voidspace | rick_h_: a side effect of allowing a maas server url without a prefix (so that the port can be specified unambiguously) | 15:43 |
| voidspace | rick_h_: is that it's basically impossible to detect invalid maas server urls until we try to use them | 15:43 |
| voidspace | rick_h_: I think the failure error is still clear enough, it's just a bit later | 15:44 |
| voidspace | rick_h_: (for invalid urls we now add http:// prefix automatically - and according to url.Parse that makes anything a potentially valid url) | 15:44 |
| voidspace | just noting it | 15:45 |
| === frankban is now known as frankban|afk | ||
| rick_h_ | voidspace: yea, with the add-cloud work I think our goal is to ping and reach the server to validate it's real and there | 15:49 |
| voidspace | rick_h_: cool | 15:49 |
| rick_h_ | voidspace: so we'll just have to pick up that "try it" work where it makes sense to fail fast for the user | 15:49 |
| voidspace | rick_h_: I've pinged menno for an updated review | 15:51 |
| rick_h_ | voidspace: <3 ty | 15:51 |
| babbageclunk | dimitern: Is it reasonable for this machineundertaker worker to use something from the provisioner API, if it does what it needs? Or is that bad? | 16:05 |
| babbageclunk | fwereade: ^^ | 16:10 |
| babbageclunk | dimitern, fwereade: more specifically - ProvisionerAPI.GetContainerInterfaceInfo does pretty much exactly what I want. Is there any way to reuse that? | 16:11 |
| jose | rick_h_: hey. do you have a sec to chat? | 16:27 |
| rick_h_ | jose: sure thing | 16:28 |
| rick_h_ | jose: you up for a HO? | 16:28 |
| jose | rick_h_: sure, one sec | 16:29 |
| dimitern | babbageclunk: I don't think it's a good idea | 16:34 |
| dimitern | babbageclunk: we have cases where methods on different facades are shared via apiserver/common mixins | 16:34 |
| dimitern | babbageclunk: but why do you think you need the same API method? | 16:35 |
| babbageclunk | dimitern: Well, I need something that takes a set of machine ids and returns a set of networkconfigs for those machines. | 16:36 |
| babbageclunk | dimitern: I'm writing it at the moment, but making backend interfaces + shims for State -> Machine -> LinkLayerDevice -> Address is pretty annoying. | 16:38 |
| dimitern | babbageclunk: what shims? can I see at a diff? | 16:42 |
| dimitern | s/at// | 16:42 |
| babbageclunk | dimitern: Well, you can see the old version of it at http://reviews.vapour.ws/r/5366/diff/ | 16:42 |
| babbageclunk | dimitern: There it's State -> MachineRemoval -> LinkLayerDevice | 16:43 |
| dimitern | babbageclunk: have you seen apiserver/common/networkingcommon ? | 16:43 |
| babbageclunk | dimitern: Ooh, no - checking now | 16:44 |
| dimitern | babbageclunk: there are useful helpers for converting configs | 16:44 |
| dimitern | might save you some of that | 16:44 |
| babbageclunk | dimitern: Oops, killed this buffer. | 16:47 |
| dimitern | babbageclunk: :) I noticed | 16:47 |
| babbageclunk | dimitern: Unfortunately none of that seems to cover the types I need. :( | 16:47 |
| dimitern | babbageclunk: I think the shim based approach for apiserver facades didn't work quite well | 16:48 |
| dimitern | babbageclunk: why not have a look at other examples - e.g. storage-related facades might be better designed | 16:49 |
| babbageclunk | dimitern: ok - any one specifically? | 16:49 |
| dimitern | babbageclunk: storageprovisioner comes to mind | 16:49 |
| babbageclunk | dimitern: Hmm. | 16:55 |
| babbageclunk | dimitern: That kind of does what I'm doing. The main difference is that it can get away without shims because all of the methods return either interfaces or publically constructable types. | 16:56 |
| babbageclunk | dimitern: Without many shims, I mean. | 16:56 |
| babbageclunk | dimitern: But Machine, LinkLayerDevice and Address all have private constructors and embed a *State, so I need to cover them with interfaces to test. | 16:58 |
| dimitern | babbageclunk: let's discuss it tomorrow? I need to go soon.. | 16:59 |
| babbageclunk | dimitern: Oops, it's late for you! I'll bug you and Will about it tomorrow. | 16:59 |
| babbageclunk | Ha ha snap | 16:59 |
| babbageclunk | dimitern: Bye! | 17:00 |
| dimitern | ok ;) | 17:01 |
| * rick_h_ grabs lunchables | 17:07 | |
| === natefinch-afk is now known as natefinch | ||
| natefinch | wow uh, juju credentials <cloud> is completely useless | 17:41 |
| natefinch | how is the first step of setting up juju with azure "install node" ? | 17:47 |
| sinzui | natefinch: bug 1611067 is a recent regression that related to bug 1418139 that is assigned to you. | 17:48 |
| mup | Bug #1611067: kill-controller of manual failed to clean up models <blocker> <ci> <kill-controller> <manual-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1611067> | 17:48 |
| mup | Bug #1418139: Can't reprovision a machine with manual provider <bootstrap> <destroy-environment> <manual-provider> <manual-story> <juju-core:In Progress by natefinch> <juju-core 1.25:Fix Committed by natefinch> <https://launchpad.net/bugs/1418139> | 17:48 |
| rick_h_ | natefinch: there's WIP around that node azure stuff | 17:50 |
| natefinch | rick_h_: oh good | 17:50 |
| mup | Bug #1611067 opened: kill-controller of manual failed to clean up models <blocker> <ci> <kill-controller> <manual-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1611067> | 17:51 |
| rick_h_ | natefinch: yea, https://github.com/Azure/azure-sdk-for-go/issues/360 | 17:52 |
| natefinch | rick_h_: nice | 17:53 |
| natefinch | sinzui: those two bugs are definitely different, even though they may have similar external behavior. The previous bug left a very obvious panic at the end of the controller's machine log, and this one does not. | 18:08 |
| mup | Bug #1611076 opened: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076> | 18:48 |
| mup | Bug #1611076 changed: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076> | 18:54 |
| mup | Bug #1611076 opened: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076> | 18:57 |
| natefinch | katco: responded. I need to review the tests (didn't get a chance last time) and then pretty sure I can just LGTM it. | 19:24 |
| katco | natefinch: cool ty | 19:24 |
| katco | natefinch: your point about logging the retries at a different level is interesting. i'm not sure where i come down on that yet... i like the idea of being able to look at the log while it's happening to understand what's going on, but not sure if i would expect to flip into trace mode to do that | 19:28 |
| * katco wonders if anyone else has opinions on that | 19:28 | |
| natefinch | katco: my opinion - there's errors and there's non-errors. This is not an error, because it's being retried. Once it fails forever, then it's an error. until then, it's just info (or debug). | 19:56 |
| katco | natefinch: there are warnings too | 19:57 |
| mup | Bug #1611093 opened: "juju models" hangs <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1611093> | 19:57 |
| natefinch | katco: I'm with Dave on warnings. Warnings, IMO, don't have a good use case. Warning is basically "we didn't know if we should make this an error or not, so we put it at warning"... except that the code definitely has to treat it as an error or not, and usually it's treated as not an error. | 19:59 |
| natefinch | sinzui, mgz: have you seen this azure error? Provisioning failed. Shrinking a disk from 136367309312 bytes to 34359738880 bytes is not supported.. ResizeDiskError | 20:00 |
| katco | natefinch: warnings are definitely not an error (i.e. the system is not in an errored state), but i disagree that one only arrives at utilizing warnings because they cannot decide between info and error. | 20:00 |
| katco | natefinch: e.g., this code. juju is warning you that something is going wrong, but it may recover. | 20:01 |
| natefinch | katco: it's a bit of a simplification, for sure. | 20:01 |
| natefinch | katco: I guess, if it works in the end, then I feel like it's not super noteworthy. Like dropped tcp packets. | 20:01 |
| katco | natefinch: except dropped tcp packets can forewarn of a failure and are often logged :) | 20:02 |
| natefinch | katco: sure, and I'm not saying we shouldn't log retries at all. They definitely 100% should be recorded somewhere. I'm just arguing to make them less in your face. | 20:03 |
| katco | natefinch: yes, that is the part i'm on the fence about | 20:03 |
| sinzui | natefinch: We have not see ResizeDiskError before | 20:03 |
| katco | natefinch: it seems like a normal part of the system's operation, and not super-detailed tracing information | 20:04 |
| natefinch | katco: it's a matter of degrees. The problem is, I think whether it's info or warning is very much dependent on exactly what caused the retry... so do we err on the side of visibility or the side of keeping noise low? | 20:04 |
| katco | natefinch: i don't think you should be worrying about noise at the raw log data level. that is a problem for log views | 20:05 |
| natefinch | sinzui: it's unfortunate - Juju seems not to realize that this instance will never come up. It still says the agent is allocating | 20:06 |
| natefinch | katco: we should definitely worry about noise in the log. Most of our interactions with the log are at the raw text level. There have been bugs filed and work done to remove spam from the logs. I think that's worth the effort. | 20:07 |
| katco | natefinch: good point; we do seem to come down on that side of the argument (although i disagree with it) | 20:09 |
| katco | natefinch: still, these messages a) won't always be there, b) will happen at most 3 times | 20:10 |
| natefinch | sinzui: crap, I seem to be getting that consistently now (well, 2 out of 2 tries) | 20:10 |
| mgz | natefinch: hm, are you doing anything differently from the runs that worked? | 20:11 |
| natefinch | mgz: ¯\_(ツ)_/¯ | 20:12 |
| natefinch | mgz: using 2.0-beta14 | 20:13 |
| natefinch | mgz: forgot to use upload-tools, so I presume it's using whatever is in streams | 20:13 |
| natefinch | also, interstingly: | 20:14 |
| natefinch | $ juju add-machine --series win2012 | 20:14 |
| natefinch | ERROR empty apt-https-proxy in model configuration | 20:14 |
| mgz | hmph | 20:15 |
| mgz | that seems like a bug | 20:16 |
| natefinch | yeah, I'm going to rebuild and make sure I'm running master with upload tools and see what happens then | 20:16 |
| sinzui | natefinch: in azure I think you need to use series win2012r2 | 20:25 |
| natefinch | sinzui: ahh, maybe that's the problem | 20:25 |
| natefinch | sinzui: hmm... getting the same error if I use win2012r2 | 20:31 |
| sinzui | :/ | 20:31 |
| sinzui | natefinch: Our tests from this morngin get farther http://reports.vapour.ws/releases/4221/job/azure-arm-deploy-windows-amd64/attempt/45 | 20:32 |
| mup | Bug #1611097 opened: model already exists but can't be destroyed because it's not found <oil> <oil-2.0> <juju-core:Incomplete> <https://launchpad.net/bugs/1611097> | 20:34 |
| sinzui | natefinch: We never use upload-tools since it doesn't worth with multiple os/arch. we used streams. We also deployed a charge from lp:juju-ci-tools/repository | 20:34 |
| sinzui | juju --show-log deploy -m azure-arm-deploy-windows-amd64:azure-arm-deploy-windows-amd64 /var/lib/jenkins/repository/charms-win/dummy-source --series win2012r2 | 20:34 |
| natefinch | man, our pedantry for credential vs credentials is really annoying | 20:43 |
| natefinch | mgz: fwiw, that "no apt-proxy set" error went away with a rebuild, so probably I was just in some weird bad state in my local code (hopefully). | 20:53 |
| mgz | hm | 20:54 |
| mgz | yeah, hopefully just a version incompat | 20:55 |
| natefinch | wow, juju add-model takes a heck of a long time for something that should be almost a noop | 20:56 |
| natefinch | h$ juju kill-controller azure -y | 21:00 |
| natefinch | panic: empty value for "firewall-mode" found in configuration (type <nil>, val <nil>) | 21:00 |
| natefinch | woo | 21:00 |
| rick_h_ | natefinch: did destroy-controller not work? | 21:00 |
| natefinch | rick_h_: I never use destroy controller | 21:00 |
| rick_h_ | natefinch: :( | 21:00 |
| rick_h_ | natefinch: that's the official way for users to perform that operation | 21:00 |
| natefinch | rick_h_: kill-controller is shorter and doesn't make me type out that extra flag about killing models too | 21:01 |
| natefinch | rick_h_: FWIW destroy gives that error too :0 | 21:02 |
| natefinch | rick_h_: I gotta run to make dinner, but will be back in a few hours | 21:02 |
| === natefinch is now known as natefinch-afk | ||
| mup | Bug #1611110 opened: Need remove-{space,subnet} commands <juju-core:New> <https://launchpad.net/bugs/1611110> | 21:04 |
| mup | Bug #1611111 opened: Model still exists for a while after running destroy-model <oil> <oil-2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1611111> | 21:04 |
| thumper | :( | 21:16 |
| bdx | other then specifying `--upload-tools`, should there be anything else to keep in mind when bootstrapping/deploying from a build of master ? | 21:44 |
| thumper | bdx: I don't think so | 21:46 |
| bdx | thumper: thx | 21:47 |
| tvansteenburgh | any one have an example of deploying a local charm via the api? | 22:19 |
| tvansteenburgh | with juju 2, specifically | 22:24 |
| tvansteenburgh | i have and example from juju1 that uploads a charm archive and then deploys it with the local:series/charm nomenclature | 22:25 |
| tvansteenburgh | does that still work? | 22:25 |
| tvansteenburgh | and if so, what would the charm-url passed to the api be? | 22:28 |
| menn0 | wallyworld: I've updated my snap. Could you have another go at those instructions again please when/if you have a chance? | 22:44 |
| menn0 | wallyworld: the weird directory hierarchy under ~/snap was being caused by the setup script calling another binary in /snap/bin | 22:45 |
| menn0 | wallyworld: the setup script now calls $SNAP/bin/juju directly instead and that fixes the issue | 22:45 |
| menn0 | wallyworld: not sure exactly what was going on but the environment variables seen by juju weren't right due to the nested invocation | 22:46 |
| wallyworld | menn0: sure. yeah that was weird. seems like a bug to me. i'll try after standup | 22:47 |
| redir | brb reboot | 22:47 |
| redir | wallyworld! | 23:01 |
| wallyworld | yo | 23:01 |
| redir | wallyworld: axw wanted a test (see RB), I am curious if there's already a related test for other inherited config and if so where it lives. | 23:02 |
| redir | wallyworld: he suggested cloudconfig, but at a glance I don't see anything similar. | 23:03 |
| wallyworld | there's no feature test yet (still todo). but there are other tests, i'll look at rb and see what's been requested | 23:04 |
| alexisb | redir, welcome back | 23:05 |
| alexisb | hope you had a lovely holiday | 23:05 |
| redir | alexisb: tx | 23:05 |
| * redir nods | 23:05 | |
| redir | very relaxing:) | 23:05 |
| redir | and more sun than is probably healthy | 23:05 |
| alexisb | :) sun and relaxation both sound great | 23:07 |
| redir | Highly recommended:) | 23:08 |
| alexisb | thumper, wallyworld ping | 23:16 |
| mup | Bug #1605008 changed: juju2beta12 and maas2rc2: juju status shows 'failed deployment' for node that was 'deployed' in maas <oil> <oil-2.0> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1605008> | 23:25 |
| mgz | alexisb: I think we need to have a plan over bug 1570650 - what happens if we get a security bug reported against 1.25/db in the trusty support lifespan | 23:26 |
| mup | Bug #1570650: Use juju-mongodb2.6 for 1.25 on xenial <local-provider> <packaging> <juju-core:Fix Released> <juju-core 1.25:Won't Fix> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1570650> | 23:26 |
| mup | Bug #1610990 changed: list-storage in aws contains non-created items <ci> <regression> <storage> <juju-ci-tools:Incomplete> <juju-core:Won't Fix by axwalk> <https://launchpad.net/bugs/1610990> | 23:46 |
| perrito666 | redir: what is the bug? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!