| ericsnow | anyone know if we are going to drop the legacy HTTP endpoints for 2.0? | 00:00 |
|---|---|---|
| ericsnow | see https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L432 | 00:00 |
| davecheney | perrito666: thanks, fingers crossed this time | 00:09 |
| perrito666 | axw: quick question about cloud credentials schema, have a sec? | 00:09 |
| axw | perrito666: in 1:1, sorry | 00:10 |
| perrito666 | no worrries | 00:10 |
| axw | perrito666: had to do school drop off, I'm back now if you're still around | 00:51 |
| perrito666 | axw: solved it :) | 00:52 |
| perrito666 | tx anyway | 00:52 |
| axw | perrito666: glad to be of service ;) | 00:52 |
| perrito666 | autoload-credentials was ignoring my ~/.novarc but it works with my env variables, will file a bug later | 00:52 |
| wallyworld | perrito666: i did test it with ~/.novarc | 01:19 |
| wallyworld | i wonder what went wrong | 01:19 |
| perrito666 | wallyworld: perhaps my novarc lacks the expected format? | 01:20 |
| wallyworld | you sure the contents are correct? | 01:20 |
| wallyworld | it looks for the same things as env vars | 01:20 |
| perrito666 | is a bash file full of exports | 01:21 |
| perrito666 | odd | 01:21 |
| wallyworld | maybe be a problem, not sure | 01:21 |
| wallyworld | weill have to retest | 01:21 |
| wallyworld | axw: i'm about to propose the interactive add-credentials with the CredentialSchema ordering fix. but i'm wondering if the password entry should echo * as characters are typed or pasted | 01:21 |
| perrito666 | wallyworld: are you sure your env was clean when you tested? | 01:21 |
| wallyworld | prtetty sure | 01:22 |
| wallyworld | i'll have a look ina bit | 01:22 |
| * perrito666 finally gets a k3 bootstrap | 01:22 | |
| perrito666 | with magic auth_url auto discovery :) | 01:22 |
| wallyworld | yay | 01:22 |
| axw | wallyworld: no, I don't think so. knowing the length of the password isn't great | 01:23 |
| axw | wallyworld: you're using readpass, right? | 01:23 |
| wallyworld | axw: yep | 01:23 |
| wallyworld | is just a personal preference | 01:23 |
| wallyworld | i want feedback that i'm typing something | 01:23 |
| axw | wallyworld: it's nice for visual feedback, but it is a security flaw | 01:23 |
| wallyworld | a small one | 01:24 |
| wallyworld | hard to count * :-) | 01:24 |
| axw | wallyworld: not if it's a short password | 01:24 |
| wallyworld | and who uses short passwords? | 01:24 |
| wallyworld | surely everyone uses a pw manager | 01:24 |
| axw | wallyworld: lol :) | 01:24 |
| wallyworld | if not they deserve wgat they get | 01:24 |
| wallyworld | (half joking) | 01:25 |
| mup | Bug #1558333 opened: juju's logging the literal "$cmd" instead of value of $cmd <juju-log> <logging> <juju-core:New> <https://launchpad.net/bugs/1558333> | 01:37 |
| wallyworld | perrito666: the issue with .novarc is that juju doesn't strip the export bit. my tests didn't have that | 01:45 |
| perrito666 | so the export bit is not valid? it sure seems | 01:45 |
| wallyworld | the export bit should be supported by juju | 01:46 |
| anastasiamac_ | axw: since u r OCR, could u PTAL http://reviews.vapour.ws/r/4193/ | 01:46 |
| wallyworld | ie juju should strip it out | 01:46 |
| anastasiamac_ | axw: it's a critical for 1.25 | 01:46 |
| axw | anastasiamac_: sure, looking | 01:46 |
| anastasiamac_ | axw: thanks :D | 01:46 |
| perrito666 | wallyworld: cant yout source the file into an env and read the env? sounds like you could save a lot of future pains with that | 01:47 |
| axw | anastasiamac_: were there any changes to the changes required? | 01:47 |
| wallyworld | perrito666: sourcing the file is a shellism | 01:48 |
| axw | anastasiamac_: (i.e. did you just cherry pick without having to modify?) | 01:48 |
| anastasiamac_ | axw: ? no cherry-pick was not possible | 01:48 |
| axw | anastasiamac_: I see, you said re-work | 01:48 |
| axw | nps | 01:48 |
| anastasiamac_ | axw: the commits have other stuff in them like lxd for eg.. | 01:48 |
| wallyworld | perrito666: i was hoping to avoid execing shell command | 01:48 |
| axw | right, of course | 01:49 |
| anastasiamac_ | axw: however, the related code is exactly as onmaster | 01:49 |
| axw | anastasiamac_: okey dokey | 01:49 |
| anastasiamac_ | axw: except for renaming model stuff :P | 01:49 |
| perrito666 | wallyworld: I would expect to be a way to wrap that into go by running a child env and do whatever that env supports as source (but then again, I am guessing, a lot) | 01:50 |
| wallyworld | i didn't see an obvious way, maybe there is | 01:50 |
| wallyworld | it's easy enough to tweaks what there already to work | 01:51 |
| axw | anastasiamac_: LGTM, thanks | 01:54 |
| anastasiamac_ | axw: \o/ | 01:54 |
| perrito666 | wallyworld: axw credentials schema fields cannot be made optionals? | 01:58 |
| wallyworld | perrito666: they can as of recently | 01:59 |
| perrito666 | wallyworld: is that on master? | 01:59 |
| wallyworld | Optional: true | 01:59 |
| wallyworld | yes | 01:59 |
| wallyworld | perrito666: i did it just for you | 01:59 |
| wallyworld | to support keystone 3 | 02:00 |
| perrito666 | you are wonderful, pint me to plz? | 02:00 |
| wallyworld | EPARSEERROR | 02:00 |
| wallyworld | if you grab master tip, you can use Optiona: true in credential schema | 02:01 |
| perrito666 | grrrreat | 02:01 |
| wallyworld | axw: fyi, ignore the charm-minvers feature branch pr, that's s merge into master i'm landing now | 02:19 |
| axw | wallyworld: ok, thanks | 02:19 |
| perrito666 | k I have it working and almost fixed the joyous openstack live tests to reflect that, my brain is out of order for the day, see you all tomorrow | 02:25 |
| perrito666 | wallyworld: axw anastasiamac_ I would love a review of https://github.com/go-goose/goose/pull/19 during the night | 02:26 |
| perrito666 | cheers | 02:26 |
| wallyworld | our night or yours? | 02:26 |
| axw | perrito666: will see how I go, got lots to review today | 02:27 |
| wallyworld | i can look | 02:27 |
| anastasiamac_ | perrito666: nite \o/ | 02:27 |
| perrito666 | wallyworld: yours I need to et all this merged tomorrow | 02:28 |
| perrito666 | no sorry mine | 02:28 |
| perrito666 | mybrain is dead | 02:28 |
| wallyworld | perrito666: i was being facecious :-) | 02:28 |
| wallyworld | i knew what you meant :-) | 02:29 |
| natefinch | axw: can I get one more quick review on the stringmap thing? realized I was missing handling an error case: https://github.com/juju/cmd/pull/32 | 03:38 |
| axw | natefinch: looking | 03:40 |
| natefinch | axw: thanks | 03:40 |
| axw | natefinch: done | 03:41 |
| natefinch | axw: thanks! | 03:42 |
| natefinch | and now to figure out how to finagle these full stack tests to succeed when the server doesn't actually support this endpoint... | 04:05 |
| davecheney | /win12 | 04:23 |
| menn0 | axw: this is pretty horrible but necessary: https://github.com/juju/juju/pull/4766 PTAL | 04:30 |
| * axw braces | 04:31 | |
| natefinch | menn0: is there a bug filed for that on go-yaml? | 04:33 |
| menn0 | natefinch: not yet, but I've just created a card for myself on our board to do that | 04:34 |
| anastasiamac_ | menn0: is it worthwhile back porting to 1.25... I think that the bug would be awesome too \o/ | 04:34 |
| natefinch | anastasiamac_: are we supporting go 1.6 for 1.25? | 04:34 |
| mup | Bug # changed: 1499781, 1504578, 1526926, 1529126 | 04:35 |
| menn0 | natefinch: it's an involved bug report to write up so I'll do it next week | 04:35 |
| menn0 | anastasiamac_: the code that was relying on private embedded types only exists in Juju 2.0 | 04:35 |
| menn0 | anastasiamac_: we'd know about it if we were relying on this elsewhere | 04:35 |
| anastasiamac_ | menn0: then no need for 1.25 :D | 04:35 |
| * menn0 has lost hours on this | 04:36 | |
| axw | menn0: what's the deal with all the trailing underscores? | 04:36 |
| anastasiamac_ | menn0: but for reference, I can see CI tests that run against 1.25 with go 1.6 | 04:36 |
| natefinch | axw: they give you a place to rest your mouse when your arm gets tired | 04:36 |
| axw | nani | 04:37 |
| menn0 | axw: Tim came up with that as a way to avoid collisions between field names and the method names he wanted to use | 04:37 |
| anastasiamac_ | natefinch: such small mouse tho :D | 04:37 |
| axw | menn0: ah, right, ok | 04:37 |
| menn0 | axw: i've continued with the trend | 04:38 |
| axw | menn0: reviewed | 04:39 |
| menn0 | axw: thanks | 04:39 |
| menn0 | axw: I clearly didn't re-run the tests after removing that debugging Dump method :) | 04:40 |
| axw | :) | 04:40 |
| jam | axw: davecheney: I pushed a small update because of a case I found in Juju (we were calling AddCleanup during SetUpSuite()), can you give it one more quick look? | 05:59 |
| axw | jam: LGTM. there's a bug somewhere (I think rogpeppe filed it) suggesting that we should just have AddCleanup, and DTRT whether we're in SetUpSuite or in/after SetUpTest | 06:02 |
| axw | jam: probably need to change tests to do that tho | 06:02 |
| jam | axw: I could do that here, with just checking if s.testSuite is nil | 06:02 |
| jam | axw: does that sound sane? | 06:03 |
| axw | jam: yeah, I'm just not sure if anything is relying on current behaviour | 06:03 |
| jam | axw: if it is, its broken | 06:03 |
| jam | assuming AddCleanup during a Suite level operation will be cleaned up after the first test run... | 06:03 |
| jam | we could keep AddSuiteCleanup as an explicit thing | 06:03 |
| jam | but calling it in a Test context and assuming it will last the rest of the Suite is also broken behavior | 06:04 |
| jam | One test should not set global state for another test to expect | 06:04 |
| jam | axw: then again, if the Juju test suite *does* have those bugs, I don't know how many I can fix :) | 06:04 |
| axw | jam: indeed :) | 06:04 |
| axw | jam: I'd be happy to drop AddSuiteCleanup and have AddCleanup add suite-level things when called in SetUpSuite, and test-level things otherwise | 06:05 |
| axw | it's just a sed command to rename AddSuiteCleanup to AddCleanup after that | 06:05 |
| axw | jam: if you want to defer removing/renaming, that's fine though. we can do that later | 06:06 |
| jam | axw: trying to think how to write the tests for it. | 06:06 |
| jam | I think making it safe and easy to use is best | 06:06 |
| jam | so users don't have to think "Can I call it now"? | 06:07 |
| jam | (heirarchy of good API, "make the obvious thing correct" vs "make the wrong thing hard to do" | 06:07 |
| jam | ) | 06:07 |
| jam | axw: it also leads to helpers like PatchValue where you can't control whether it is Suite level or Test level. | 06:07 |
| axw | jam: just read your latest email; the bug I was thinking of was actually about PatchValue. same sort of deal though | 06:07 |
| jam | axw: yeah, the fact that BaseSuite itself had this bug | 06:08 |
| jam | means we can *easily* have lots of tests that are actually doing Outbound tests | 06:08 |
| axw | :\ | 06:08 |
| jam | and we didn't notice because we thought we were protected by BaseSUite | 06:08 |
| axw | wallyworld: we're still using CompatSalt in cloudconfig/instancecfg, and I don't think there's any reason to. The hash is a temporary, derived password - we shouldn't need to use a fixed salt | 06:18 |
| wallyworld | axw: yeah, i figured that change was a separate pr | 06:19 |
| axw | wallyworld: ok | 06:19 |
| jam | axw: can you look at the pull? | 06:42 |
| jam | http://github.com/juju/testing/pull/92 | 06:42 |
| axw | jam: looking | 06:42 |
| jam | thx | 06:42 |
| jam | or davecheney^^ | 06:42 |
| jam | axw: interestingly "home_test" was a case where we were setting up another test suite, and calling SetUpTest but not SetUpSuite | 06:44 |
| axw | jam: LGTM, thanks. there's a couple of odd SetUpTest calls in home_test, but just style issues really | 06:50 |
| axw | and preexisting at that | 06:50 |
| jam | home_test is trying to test the test itself by creating another test object. | 06:51 |
| jam | but it is calling SetUpTest without ever calling SetUpSuite | 06:51 |
| axw | jam: ah, I see. | 06:51 |
| jam | and we're now at... a whole lot of failures in Juju proper... | 06:51 |
| axw | :/ | 06:51 |
| jam | FakeHomeSuite is doing something bad. | 06:52 |
| axw | jam: because they were swept under the rug? | 06:52 |
| jam | lots of tests use it | 06:52 |
| axw | lots of outbound connections? :) | 06:52 |
| axw | oh home suite | 06:52 |
| jam | investigating, because I don't see anything bad yet | 06:53 |
| jam | FakeJujuXDGDataHomeSuite calls SetUpTest during TearDownSuite ? | 06:53 |
| jam | axw: testing/environ.go line 107 | 06:54 |
| jam | why is TearDownSuite calling Suite.SetUpTest() ? | 06:54 |
| jam | I think that's just a copy&paste typo | 06:55 |
| axw | jam: heh, yep, I'd say so | 06:55 |
| axw | jam: since 2014 :) | 06:56 |
| jam | axw: love it when our base infrastructure has some weird bugs in it. | 06:56 |
| jam | axw: SetUpSuite is *also* calling SetUpTest instead of SetUpSuite | 06:57 |
| axw | lol | 06:58 |
| jam | and JujuOSSuite doesn't implement either SetUpSuite or TearDownSuite, so we don't need to write our own anymay | 06:58 |
| jam | anyway | 06:58 |
| jam | axw: or is it better to have one and just a line that says "this other one doesn't need to be called cause it doesn't exist" ? | 06:59 |
| axw | jam: I've not found one way or the other to be much better | 07:00 |
| axw | leaving it out is probably OK | 07:00 |
| axw | jam: I'd love to write a static analyser one of these days to check that they're all wired up correctly | 07:00 |
| jam | axw: yeah, the main problem is that once someone does introduce a SetUpSuite then we should call it, but neither way is going to catch that on its own | 07:00 |
| * axw nods | 07:01 | |
| jam | so it looks like we do have at least 1 failure in Provisioning suite | 07:19 |
| jam | where it is actually reading cloud-images somehow | 07:19 |
| jam | though it is failing in the opposite way I was expecting | 07:21 |
| jam | maybe FakeXDGHome was accidentally making it harder to get outside access by calling SetUpTest all the time? | 07:22 |
| wallyworld | axw: i'm off to soccer soonish, i've reposnded to some of the comments on the add credentials review. i'll finish the interactive prompt for replace when i get back | 07:32 |
| axw | wallyworld: thanks, I'm just responding now | 07:33 |
| axw | enjoy | 07:33 |
| wallyworld | leaving in 20 minutes r so | 07:33 |
| wallyworld | will do | 07:33 |
| jam | axw: ugh. we have test suites that want to call PatchValue before they call their Base type's SetUpTest because SetUp does work that they want to patch out | 07:34 |
| axw | jam: ugh indeed | 07:36 |
| axw | jam: example? | 07:36 |
| jam | provider/lxd/ | 07:36 |
| jam | testing_test.go | 07:37 |
| jam | there is a BaseSuiteUnpatched and a BaseSuite | 07:37 |
| jam | and BaseSuite embeds BaseSuiteUnpatched which embeds IsolationSuite | 07:37 |
| jam | so BaseSuite patches an object, then calls BaseSuiteUnpatched.SetUp | 07:37 |
| jam | line 277 | 07:38 |
| jam | axw: ^^ | 07:38 |
| jam | provider/joyent/joyent_test.go calls envtesting.PatchAttemptStrategies() before calling base .SetUpSiet() | 07:39 |
| jam | SetUpSuite() | 07:39 |
| axw | jam: yup. I think in the lxd case it could be moved to BaseSuite.SetUpSuite | 07:39 |
| axw | jam: that one's a bit different, it's not involving the suite | 07:40 |
| jam | axw: provider/joyent/local_test.go line 155 | 07:40 |
| jam | calls PatchValue for 2 things before calling providerSuite.SetUpSuite() | 07:40 |
| axw | jam: AFAICT, it doesn't need to | 07:42 |
| jam | that also looks like it was honestly broken because the lifetime of that PatchValue should be wrong | 07:42 |
| * axw digs | 07:42 | |
| axw | true | 07:42 |
| jam | my "go test ./...." is 5000 lines with this change to AddCleanup... | 07:42 |
| axw | jam: yeah, those 2 patches can come after SetUpSuite | 07:44 |
| axw | jam: 5000 lines? huh? | 07:44 |
| jam | panic tends to create a fair bit of traceback | 07:45 |
| jam | and SetUp failures fail on all the associated tests | 07:45 |
| jam | so it is bigger than probably it seems | 07:45 |
| jam | but its a fair bit to dig through | 07:45 |
| jam | axw: provider/joyent/local_test.go adds a *AddSuiteCleanup* that patches the attempt strategies to ShortAttempt | 07:47 |
| jam | I don't see it patch them to something longer first. | 07:47 |
| jam | my rabbit hole has gotten too deep, I think | 07:48 |
| axw | :) | 07:48 |
| axw | jam: probably just cruft, but I don't know for sure | 07:49 |
| jam | axw: I *did* finally hit tests that are going to cloud-images | 07:50 |
| jam | and failing now because they can't | 07:50 |
| jam | localLiveSuite.TestStartStop for provider/ec2 | 07:50 |
| jam | "signature made by unknown entity" | 07:51 |
| axw | jam: yep, SetUpSuite calls PatchOfficialDataSources which calls PatchValue | 07:52 |
| * axw has to go feed children | 07:53 | |
| jam | axw: have a good evening | 07:54 |
| jam | need to get out a swear jar... | 07:55 |
| * frobware wakes up to find maas-spaces2 has merged. \o/ | 08:57 | |
| frobware | dimitern: about to push your branch as upstream/maas-spaces-multi-nic-containers | 09:31 |
| dimitern | frobware, great! and I've seen maas-spaces2 get merged! cheers | 09:33 |
| frobware | dimitern: if we don't do lxc then CI tests will fail. How do we not do this for the moment is not clear (to me at least). | 09:33 |
| dimitern | frobware, well lxc-broker is still there, so .. | 09:34 |
| frobware | dimitern: we need to bung this branch (@ 07693b816c207bc6e3fa9d7dd3f76784a695908e) to the OS folks for testing... | 09:35 |
| frobware | dimitern, voidspace: upstream/maas-spaces-multi-nic-containers is now soliciting commits... :) | 09:36 |
| frobware | mgz, sinzui: please can we add upstream/maas-spaces-multi-nic-containers to the CI jobs (assuming something explicitly needs to be setup). thanks! | 09:38 |
| voidspace | frobware: cool | 09:40 |
| dimitern | frobware, I have some commits in mind to add :) | 09:40 |
| dimitern | voidspace, frobware, we should also delete maas-spaces2 from upstream soon | 09:41 |
| mgz | frobware: pushing it into the juju namespace is all that's needed | 09:45 |
| frobware | mgz: thanks | 09:46 |
| dimitern | frobware, about that fancycheck - it was temporary, now it can be dropped | 09:47 |
| dimitern | frobware, and we should do that before the CI run right? | 09:47 |
| frobware | dimitern: submit a PR, we can now review, commit in the usual way. ;) | 09:48 |
| dimitern | frobware, on it | 09:49 |
| voidspace | dimitern: frobware: is maas-spaces2 landing on master today then? | 09:52 |
| dimitern | voidspace, it already landed yesterday | 09:52 |
| voidspace | dimitern: hah, cool | 09:53 |
| TheMue | morning saphires o/ *yawn* | 09:58 |
| dimitern | TheMue, hey o/ morning | 09:58 |
| voidspace | TheMue: 0/ | 10:00 |
| dimitern | voidspace, frobware, http://reviews.vapour.ws/r/4210/ | 10:01 |
| natefinch | team meeting anyone? | 10:03 |
| * TheMue currently not *lol* | 10:04 | |
| voidspace | dimitern: frobware: I'm down to 11 failures on my branch (from 33 yesterday) - several of them about to be fixed by a change to gomaasapi | 10:10 |
| voidspace | (gomaasapi test server) | 10:11 |
| perrito666 | morning all | 10:13 |
| perrito666 | natefinch: is there anyone in the tm? | 10:14 |
| natefinch | perrito666: a efw people | 10:15 |
| natefinch | perrito666: me, william, michael, and dimiter | 10:16 |
| frobware | dimitern, voidspace: sorry, was otp. Want to do a quick standup? | 10:17 |
| voidspace | frobware: in team meeting | 10:17 |
| fwereade | jam, I would love to help you with IsolationSuite horrors, but... probably not today | 10:28 |
| voidspace | dimitern: want to drop back in for standup? | 10:29 |
| dimitern | voidspace, sure | 10:29 |
| dimitern | voidspace, frobware, I'm the only one there though | 10:30 |
| voidspace | dimitern: we stayed in the team meeting room... | 10:31 |
| voidspace | dimitern: as we were there already | 10:31 |
| dimitern | ah | 10:31 |
| voidspace | hence "drop back in" | 10:31 |
| TheMue | Btw, Happy St Patricks Day | 10:56 |
| voidspace | down to 7 failures and deleted more code | 11:20 |
| voidspace | some unused production code some unused test helpers | 11:21 |
| jam | thanks fwereade. I'm going to try and get some more of my LXD stuff done, but I did make a bit more progress on the Isolation stuff. Its actually closer than I was worried it would be. | 11:37 |
| fwereade | before I go spelunking... can anyone suggest a foolproof way of inducing a StartSync on... whatever *state.State in the background is *actually* driving events for a hosted model running under a jujud test? | 12:41 |
| fwereade | jam, dimitern, axw, wallyworld perhaps? ^^ | 12:42 |
| icey | juju's PPA needs to be updated, currently throwing warnings on Xenial due to https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1558331 | 12:42 |
| mup | Bug #1558331: After upgrading to apt 1.2.7 in Xenial, PPAs and most other third-party repositories become unusable with "The repository is insufficiently signed by key (weak digest)" <xenial> <apt (Ubuntu):Confirmed> <https://launchpad.net/bugs/1558331> | 12:42 |
| wallyworld | fwereade: isn't there a StartSync() method or something to trigger a sync? | 12:42 |
| fwereade | wallyworld, yeah... but you need to call it on the right *State | 12:44 |
| wallyworld | that is correct, it can be confusing | 12:44 |
| fwereade | wallyworld, we have access to .BackingState | 12:44 |
| fwereade | wallyworld, but I have a horrible feeling that the state that's backing the apiserver we talk to is hidden away in a statepool somewhere out of reach | 12:45 |
| wallyworld | i haven't looked at that stuff in ages. i do recall it being somewhat funky. i have not good answer for you | 12:45 |
| fwereade | wallyworld, (.BackingState is the one for the controller model, but it doesn't cause hosted models to get events | 12:45 |
| fwereade | ) | 12:45 |
| fwereade | wallyworld, no worries, looks like I need to go hunting | 12:46 |
| wallyworld | yeah, sorry | 12:46 |
| alexisb | frobware, ping | 13:30 |
| natefinch | I am sad that juju controllers is not an alias for juju show-controllers | 13:38 |
| rick_h__ | natefinch: list-controllers? | 13:38 |
| natefinch | ty | 13:38 |
| natefinch | it's show-controllers | 13:39 |
| natefinch | oh, I guess it's both | 13:39 |
| rick_h__ | show-controller is against once controller? | 13:39 |
| rick_h__ | it gives metadata for one, the other is the listing | 13:39 |
| natefinch | oh that is confusing | 13:39 |
| rick_h__ | show-X is "give me details of one" and list- "give me a table of them" | 13:40 |
| frobware | alexisb: pong | 13:40 |
| alexisb | heya frobware see private chat | 13:40 |
| natefinch | rick_h__: but then why is there a show-controllers (note plural)? | 13:40 |
| rick_h__ | natefinch: not sure on that one | 13:40 |
| alexisb | natefinch, it may be that the alias still exists on that one | 13:41 |
| alexisb | I owuld have to go look | 13:41 |
| natefinch | rick_h__: looks like you can pass in multiple controller names and it'll show you details for all | 13:41 |
| alexisb | at first we were doing both the single and plural case for everything | 13:41 |
| natefinch | s/all/each | 13:41 |
| natefinch | if you pass in 0 controller names, it shows you details for just the current | 13:42 |
| natefinch | show vs. list is very confusing IMO. | 13:42 |
| natefinch | but it looks like we have a lot of each | 13:42 |
| rick_h__ | yes, it's one of the base principles of it. Very common across all nouns can be shown or listed | 13:43 |
| dimitern | frobware, voidspace, http://reviews.vapour.ws/r/4212/ fixes an issue found with multi-nic support | 14:13 |
| natefinch | I swear I am never ever ever going to get used to bootstrap having the name first | 14:18 |
| rick_h__ | natefinch: don't get used to it, branch changing that lands soon hopefully | 14:18 |
| natefinch | rick_h__: oh thank goodness | 14:18 |
| rick_h__ | natefinch: oh, sorry you mean the cli | 14:19 |
| rick_h__ | that's not changing, though tyou meant the name of the first model | 14:19 |
| rick_h__ | lol, in which case sorry | 14:19 |
| natefinch | aww! | 14:19 |
| natefinch | how come when I juju bootstrap mylocal lxd ... it creates a juju controller named local.mylocal? | 14:20 |
| rick_h__ | the local is for multi-user situation. You might add controllers from other users that already have that name | 14:21 |
| natefinch | rick_h__: but if I don't... then you've just munged my namespace for no reason | 14:22 |
| rick_h__ | natefinch: you should be able to leave it off and we can visit ways of streamlining | 14:22 |
| rick_h__ | but had to design for the big case and work backwards | 14:22 |
| dimitern | voidspace, frobware, we should get it in to have a chance of a blessed ci run | 14:30 |
| dimitern | ^^ | 14:30 |
| frobware | dimitern: looking now | 14:30 |
| dimitern | frobware, cheers | 14:30 |
| frobware | dimitern: reviewed | 14:48 |
| dimitern | frobware, thanks - updated, pushed, and set to merge | 14:48 |
| frobware | dimitern: did you see the ci results of the first one? | 14:48 |
| * natefinch needs to make an auto-dependencies.tsv merge tool | 14:49 | |
| dimitern | frobware, yeah - as expected pretty much - the fancycheck | 14:49 |
| dimitern | frobware, and most of the other issues should be resolved by the last fix | 14:49 |
| dimitern | frobware, btw I managed to repro the empty mac address at setInstanceInfo for containers, looking into it | 14:50 |
| frobware | dimitern: I was in 2 minds about whether to push the branch this morning; I didn't think the CI run would happen that quickly given all the other feature branches that are being tested. | 14:50 |
| frobware | dimitern: oooh. And, btw, the reason the attach <pid> failed is I didn't start the remote end as root. | 14:50 |
| dimitern | frobware, they made some changes recently - there was a mail about it | 14:50 |
| dimitern | frobware, ah! :) | 14:51 |
| frobware | dimitern: what was the macaddr issue? | 14:51 |
| dimitern | frobware, I have a suspicion why it might be happening | 14:51 |
| frobware | dimitern: ok, going to ignore that and look at profiles again | 14:52 |
| dimitern | frobware, the MACAddress coming from PrepareContainerInterfaceInfo gets lost when trying to set the container devices in state | 14:52 |
| dimitern | frobware, +1 | 14:52 |
| mup | Bug #1558608 opened: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:Triaged> <https://launchpad.net/bugs/1558608> | 15:03 |
| mup | Bug #1558608 changed: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:Triaged> <https://launchpad.net/bugs/1558608> | 15:06 |
| mup | Bug #1558608 opened: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers:In Progress by dimitern> <https://launchpad.net/bugs/1558608> | 15:15 |
| mup | Bug #1558612 opened: creating hosted model config: maas-agent-name is already set; this should not be set by hand <bootstrap> <ci> <maas-provider> <test-failure> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558612> | 15:15 |
| mup | Bug #1558608 changed: maas-spaces-multi-nic-containers cannot bootstrap <block-ci-testing> <juju-core:Invalid> <juju-core maas-spaces-multi-nic-containers:Fix Released by dimitern> <https://launchpad.net/bugs/1558608> | 15:45 |
| mup | Bug #1558087 changed: TestInvalidFileFormat fails on windows because of / <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Fix Released by cmars> <juju-core model-acls:Fix Released by cmars> <https://launchpad.net/bugs/1558087> | 16:15 |
| dimitern | voidspace, btw I've found out the main reason why discoverspaces worker seems to make a lot of calls | 16:31 |
| dimitern | voidspace, it does call CreateSpaces and AddSubnets once for each space / subnet | 16:31 |
| dimitern | voidspace, I'm testing a patch now which takes advantage of the bulk nature of both api methods, so calls each of them once per handleSubnets() call | 16:32 |
| dimitern | should make the discovery much quicker hopefully, and resolve some issues where subnets might be missing when trying to use them (e.g. for machine devices' addresses) | 16:33 |
| voidspace | frobware: that test passes" | 16:38 |
| voidspace | I meant ! | 16:38 |
| voidspace | dimitern: I didn't know it seemed to make a lot of calls | 16:38 |
| voidspace | dimitern: but cool | 16:38 |
| voidspace | dimitern: I'm down to 1 failing test on drop-maas-1.8 | 16:39 |
| dimitern | voidspace, great! | 16:39 |
| frobware | dimitern: is that "resolve some issues where subnets might be missing" at all related to the mac address we were looking at earlier? (surprised if so, but...) | 16:42 |
| dimitern | frobware, not clear yet | 16:43 |
| dimitern | frobware, I did discover an issue with that fix though | 16:43 |
| frobware | dimitern: from the is not alive? | 16:43 |
| frobware | dimitern: might want to make sure that bulk method is in 2.0 before getting too far | 16:44 |
| dimitern | frobware, because the machiner starts before discoverspaces, it will not set the subnetID for yet-undiscovered subnets | 16:44 |
| voidspace | dimitern: will the bulk calls take into account that discovery might have already run and some of the spaces / subnets might already exist? (but some might not) | 16:44 |
| dimitern | frobware, it's already bulk | 16:44 |
| dimitern | voidspace, it does I think - at least it works idempotently | 16:44 |
| voidspace | frobware: the bulk api calls are our code | 16:44 |
| frobware | voidspace: ok | 16:44 |
| voidspace | dimitern: there were some tests for that | 16:44 |
| mup | Bug #1558657 opened: many workers still don't use clocks <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1558657> | 16:45 |
| dimitern | voidspace, I didn't have to change the tests after changing CreateSpaces and AddSubnets calls to be done once in bulk | 16:45 |
| mup | Bug #1558668 opened: api_undertaker_test is not a feature test <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1558668> | 16:45 |
| dimitern | they still passed ok | 16:45 |
| dimitern | and a quick live tests showed the difference: in a few seconds the discovery was done (a lot less log spam around "caching subnets.." and also 2 vs 3 messages at bootstrap saying Spaces discovert still in progress) | 16:46 |
| dimitern | that wasn't enough apparently - the machiner manages to call SetObservedNetworkConfig a couple of seconds before spaces discovery completes :/ | 17:01 |
| dimitern | so I'm thinking that we should block MA logins until discovery completes... testing this live now | 17:01 |
| fwereade | I'm pretty sure we shouldn't be blocking MA logins for anything, a huge amount of our functionality depends on it | 17:09 |
| fwereade | dimitern, ^^ | 17:09 |
| fwereade | dimitern, I think this is another reason to set space-discovery-completed in state persistently | 17:09 |
| fwereade | dimitern, and expose getter/watcher for whatever things need to wait on it? | 17:10 |
| dimitern | fwereade, I know it shouldn't, I'm just trying to see if it might help as an experiment | 17:10 |
| voidspace | dimitern: hah, the repeated building of the subnet cache is still a bug in the cache code though right? | 17:10 |
| dimitern | fwereade, I agree it needs to be recored in state once done | 17:10 |
| fwereade | dimitern, fair enough | 17:10 |
| dimitern | voidspace, it is, but the cache was done with the assumption it will be used for bulk-style calls | 17:11 |
| voidspace | dimitern: so it's cache once per call by design | 17:11 |
| voidspace | dimitern: fwereade: yeah, I can't think of another reliable way other than storing in state when discovery is completed | 17:11 |
| voidspace | not an alternative that meets all the use cases we have (HA, multiple models etc) | 17:12 |
| dimitern | voidspace, fwereade, and we have another case already - the peergrouper needs to know the spaces discovery is done before deciding the common space all controllers are in | 17:12 |
| voidspace | dimitern: right | 17:13 |
| dimitern | voidspace, why did we decide not to block until the discovery has started? in case the worker does not start at all? | 17:14 |
| voidspace | dimitern: because it blocks access for all models when you start discovery for one model | 17:14 |
| mgz | dimitern: should container networking on master work with kvm on maas? | 17:14 |
| fwereade | dimitern, voidspace: I think we probably should block, it's just that you can't do it safely without a persistent flag | 17:14 |
| dimitern | mgz, not really | 17:15 |
| voidspace | fwereade: dimitern: agreed, we need to do it right | 17:15 |
| mup | Bug #1558678 opened: manual bootstrap: PrepareForCreateEnvironment not implemented <bootstrap> <ci> <manual-provider> <regression> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558678> | 17:15 |
| dimitern | mgz, is the the addressable containers job? | 17:15 |
| voidspace | fwereade: dimitern: we disabled it because it was broken in several ways | 17:15 |
| mgz | dimitern: yeah | 17:15 |
| voidspace | dimitern: it also didn't block access *until* discovery started - which meant bootstrap could complete before the block was in place | 17:16 |
| fwereade | voidspace, dimitern: see RB4110 for how the discoverspaces worker will shortly be invoked | 17:16 |
| dimitern | mgz, I wouldn't care too much about it - addressable containers are dying, just haven't died yet | 17:16 |
| dimitern | fwereade, will check that | 17:16 |
| dimitern | fwereade, what I'm currently seeing is that the machiner is consistently starting 2 seconds before discoverspaces | 17:17 |
| fwereade | dimitern, I would expect the machiner to start beforehand usually, yeah, that's top-level whereas discoverspaces is only triggered once we've got a modelworkermanager looking for models to manage | 17:17 |
| dimitern | fwereade, which messes up setting the observed network config - I guess that must be done in a periodic worker instead of the machiner | 17:18 |
| fwereade | dimitern, I can well believe it wants to be split out of the machiner, yeah | 17:18 |
| mgz | dimitern: well, the problem is we don't have a good working spaces/new networking functional test | 17:18 |
| dimitern | as it currently does not retry / update the observed config later | 17:18 |
| fwereade | dimitern, yeah, and running a worker with multiple watchers is generally painful, even with catacomb | 17:18 |
| dimitern | mgz, how about the bundle-based one? | 17:19 |
| fwereade | dimitern, far better to separate the responsibilities completely | 17:19 |
| dimitern | fwereade, indeed, I'll look into that | 17:19 |
| mgz | dimitern: point me at it! | 17:20 |
| dimitern | mgz, let me have a look | 17:21 |
| dimitern | mgz, this one for example http://reports.vapour.ws/releases/3771/job/maas-1_9-OS-deployer/attempt/496 | 17:22 |
| mgz | right, we do exercise a bunch of stuff with that, but not kvm (or fancy subnet stuff) | 17:22 |
| perrito666 | dimitern: could you $$merge$$ -> https://github.com/go-goose/goose/pull/19 and tell me who else is in the merge team so I dont pick on you all the time? | 17:23 |
| dimitern | mgz, kvm won't work with multi-nic, but it should still work with a single nic | 17:23 |
| dimitern | perrito666, done | 17:24 |
| perrito666 | tx | 17:24 |
| * dimitern needs to step out for ~1h | 17:25 | |
| frobware | dimitern: you still there. | 17:36 |
| frobware | ah ^^ - nope | 17:36 |
| mgz | frobware: are you capturable atm? | 17:38 |
| mup | Bug #1558703 opened: PatchValue unsafe for SetUpSuite <testing> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1558703> | 17:45 |
| voidspace | frobware: dimitern: https://github.com/juju/gomaasapi/pull/10/files | 18:06 |
| voidspace | frobware: dimitern: all tests now pass on my branch | 18:13 |
| voidspace | all *maas* tests - need to do a full test run | 18:13 |
| voidspace | frobware: dimitern: I need that gomaasapi branch to land so I can update dependencies.tsv | 18:13 |
| frobware | voidspace: looking | 18:18 |
| dimitern | voidspace, looks good | 18:18 |
| dimitern | frobware, hey, I just got back, but I'm thinking of declaring EOD | 18:20 |
| frobware | dimitern: ok, me too. too many distractions since our lxd investigation earlier. | 18:20 |
| dimitern | frobware, I've found out that last fix I did was not sufficient | 18:21 |
| frobware | voidspace: I'll hang around for your branch and push that upstream so we can get a CI run | 18:21 |
| frobware | dimitern: fresh thinking comes in the morning. :) | 18:21 |
| dimitern | frobware, i.e. it will likely cause most failing jobs to pass, but it will break network-get | 18:21 |
| dimitern | frobware, but I have a fix in mind that will take care of that - but as you said - morning :) | 18:21 |
| frobware | dimitern: that's ok isn't it? (apart from unit test failures) | 18:21 |
| dimitern | frobware, it's ok for tonight I guess | 18:22 |
| frobware | dimitern: push it - we wake up to a CI run | 18:25 |
| dimitern | frobware, will do - it'll take a couple of hours to implement and test, so that's my plan for tomorrow first thing | 18:26 |
| frobware | dimitern: sounds good | 18:27 |
| voidspace | frobware: I have a provisioner unit test failure on wrong number of network.InterfaceInfo returned | 18:40 |
| voidspace | frobware: I'll look at it in the morning, should be able to get it done first thing | 18:40 |
| voidspace | frobware: oh wait | 18:41 |
| voidspace | frobware: that fails due to missing lxcbr0, that may fail on master for me as well | 18:41 |
| voidspace | frobware: and indeed it does fail in the same way | 18:42 |
| voidspace | frobware: my gomaasapi branch has landed, I'll fix dependencies.tsv and push | 18:43 |
| voidspace | frobware: right branch pushed | 18:47 |
| voidspace | frobware: ready for a CI run | 18:47 |
| arosales | hello juju core folks :-) | 18:47 |
| voidspace | frobware: *requires* maas 1.9 | 18:47 |
| voidspace | and that's me EOD | 18:47 |
| arosales | Need some help on a power8 stack trace | 18:47 |
| voidspace | g'night all | 18:47 |
| arosales | https://bugs.launchpad.net/juju-core/+bug/1558734 | 18:47 |
| mup | Bug #1558734: POWER8 agent stacktraces and refuses to boot <juju-core:New> <https://launchpad.net/bugs/1558734> | 18:47 |
| rick_h__ | natefinch: quick check, if I update my charm with a min-version, and I do attempt to deploy it on older Juju what happens? | 19:03 |
| natefinch | rick_h__: it deploys | 19:03 |
| rick_h__ | natefinch: ok, so Juju doesn't freak about the unknown attribute? | 19:03 |
| natefinch | rick_h__: nope... one of the nice things about the way we deserialize the data in there... anything we don't recognize we ignore | 19:04 |
| natefinch | rick_h__: in this particular case, it would kind of be nice if we got a "error, can't deploy, unrecogized data in metadata: min-juju-version" .... but, alas, it'll just ignore it and deploy. | 19:05 |
| rick_h__ | natefinch: ok | 19:05 |
| mup | Bug #1558734 opened: POWER8 agent stacktraces and refuses to boot <juju-core:New> <https://launchpad.net/bugs/1558734> | 19:09 |
| frobware | mgz: still about? | 19:28 |
| mup | Bug #1558769 opened: unable to create-model in azure <juju-core:New> <https://launchpad.net/bugs/1558769> | 20:30 |
| perrito666 | I broke restore? :( that is ironic | 21:52 |
| mup | Bug #1558803 opened: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <ppc64el> <regression> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1558803> | 21:55 |
| arosales | mwhudson: marcoceppi still seeing juju peg the cpu on power8, any suggestions? | 23:38 |
| mwhudson | arosales: is this a power8 where c programs like dpkg actually work? | 23:38 |
| mwhudson | because debugging firmware issues via juju seems insane | 23:38 |
| arosales | they have been working, I am not sure if they have tested lately | 23:39 |
| arosales | mwhudson: ack I am not asking you to debug firmware via Juju | 23:39 |
| arosales | mwhudson: I am dumb, but not that dumb | 23:39 |
| arosales | mwhudson: just asking if you had any suggestion for marcoceppi given juju was pegging the cpu | 23:40 |
| mwhudson | arosales: basically, no | 23:40 |
| mwhudson | if you can give me access, i can poke around | 23:40 |
| mwhudson | but as i said in other mail, testing something built with golang-go rather than gccgo would probably be more useful overall | 23:40 |
| menn0 | wallyworld: would you be able to look at http://reviews.vapour.ws/r/4218/ pls? | 23:41 |
| wallyworld | sure | 23:41 |
| arosales | mwhudson: marcoceppi may chime with access here in bit, but it is dinner time for him | 23:41 |
| arosales | mwhudson: juju 2.0 built any different than 1.25? | 23:42 |
| mwhudson | arosales: not entirely my department, but, gosh, i certainly hope so | 23:42 |
| mwhudson | arosales: you are testing trusty, i assume? | 23:42 |
| arosales | ok so perhaps we try juju 2.0 on that machine | 23:42 |
| arosales | mwhudson: yes trusty atm | 23:42 |
| wallyworld | arosales: we are moving to use golang 1.6 for building but afaik are not quite there yet | 23:43 |
| arosales | ah so testing 2.0 doesn't help there -- gotcha | 23:45 |
| arosales | mwhudson: fyi golang-go is indeed the problem and not recommended, and we build juju 2.0 GA with go-lang and we run into these issues we will be in a world of hurt | 23:46 |
| arosales | mwhudson: something to be aware of | 23:46 |
| arosales | wallyworld: thanks | 23:46 |
| mwhudson | arosales: i don't understand | 23:47 |
| arosales | mwhudson: there is no current juju (stable or dev) that is build with golang 1.6 | 23:48 |
| arosales | if 2.0 ends up being built wiwth gcc-go 4.9 it seems like we would be in world of hurt for juju 2.0 ga | 23:48 |
| mwhudson | arosales: juju for xenial for amd64 is built with go 1.6 | 23:48 |
| arosales | mwhudson: that is counter to wallyworld's statement | 23:50 |
| arosales | mwhudson: pehaps wallyworld was saying for ppc64el | 23:50 |
| wallyworld | arosales: mwhudson: the aim is we will be using golang 1.6 to build for all architectures for 2.0 is my understanding | 23:50 |
| arosales | mwhudson: which having amdb64 built with go 1.6 doesn't help much with the known issues on power8le | 23:50 |
| mwhudson | arosales: many axes of variation :/ | 23:52 |
| arosales | indeed, but in the end power8le seems broken on 1.25 built with gcc-go 4.9 | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!