| mup | Bug #1613487 opened: Fails to build tools when no matching tools found. <bootstrap> <ci> <regression> <juju-core:New> <https://launchpad.net/bugs/1613487> | 00:42 |
|---|---|---|
| mup | Bug #1613491 opened: juju service names limited to 66 characters <juju-core:New> <https://launchpad.net/bugs/1613491> | 00:57 |
| menn0 | wallyworld: i've spent a bit of time looking into this environs/sync issue and nothing jumps out | 01:05 |
| menn0 | wallyworld: I don't see any cases of a gc.C being stored inappropriately or even goroutines being used | 01:05 |
| wallyworld | yeah, i had a brief look earlier and am in the same boat | 01:05 |
| wallyworld | we really need there to be more info logged | 01:06 |
| menn0 | wallyworld: ha! I had it running with dave's stress script while I was having lunch and managed to have it fail like that once out of ~100 times | 01:07 |
| menn0 | wallyworld: so it is somewhat reproducible | 01:07 |
| wallyworld | and yet CI fails more regularly | 01:08 |
| wallyworld | hard to know where to target though with no errors | 01:08 |
| menn0 | wallyworld: i'm going to try running it again with -check.vv | 01:09 |
| menn0 | wallyworld: ok it failed quite quickly that time | 01:11 |
| menn0 | just checking the output | 01:11 |
| menn0 | wallyworld: got it | 01:12 |
| * menn0 pastebins | 01:12 | |
| menn0 | wallyworld: here's the 3 failures I just got: http://paste.ubuntu.com/23060118/ | 01:14 |
| wallyworld | menn0: intersting, wtf isn't that deterministic | 01:15 |
| wallyworld | i can look into it | 01:15 |
| menn0 | wallyworld: I see it | 01:17 |
| menn0 | wallyworld: GetMockBundleTools is patched in during SetupTest and it keeps a reference to the gc.C that was passed to SetUpTest | 01:18 |
| menn0 | wallyworld: when it fails during the test that gc.C is no longer the current one | 01:18 |
| menn0 | (i.e. the one that gets passed to the test) | 01:19 |
| menn0 | that's what causes these tests that both pass and fail | 01:19 |
| menn0 | wallyworld: moving the GetMockBundleTools patching into the tests themselves makes them fail consistently (due to typed nil) | 01:22 |
| axw | wallyworld: if you don't mind, PTAL at http://reviews.vapour.ws/r/5441/ | 01:23 |
| wallyworld | menn0: ah, i hate that multiple gc.C thing | 01:25 |
| wallyworld | menn0: i have a branch i need to start, i can fix in that | 01:25 |
| menn0 | wallyworld: I'll push what i've done so far | 01:26 |
| wallyworld | menn0: ok, np. i haven't had any time so far today to dive in, keep getting pulled left and right | 01:26 |
| menn0 | wallyworld: understood. this one got my attention because a) it's odd and 2) it's bitten me several times in the last day | 01:27 |
| wallyworld | yeah, it will be fixed... today! | 01:27 |
| wallyworld | axw: lgtm. we'll need to address the @local suffic at some point because I think it was going to be removed | 01:29 |
| axw | wallyworld: okey dokey. I'd love it if we just had one canonical form always | 01:29 |
| wallyworld | agreed, i think that's where the push is coming from, need to touch base on that again | 01:30 |
| menn0 | wallyworld: pushing now. all the tests pass again except one and I'm not sure if the test is wrong or the implementation. | 01:31 |
| menn0 | wallyworld: the tests were only passing by luck before it seems. | 01:31 |
| menn0 | (due to the typed nil comparison | 01:31 |
| wallyworld | menn0: ok, ta, will merge into mine | 01:31 |
| menn0 | wallyworld: https://github.com/mjs/juju/tree/environ-sync-tests | 01:32 |
| wallyworld | ty | 01:32 |
| === menn0 is now known as menn0-afk | ||
| === natefinch-afk is now known as natefinch | ||
| natefinch | could really use a review: http://reviews.vapour.ws/r/5440/ axw or anyone else | 02:13 |
| axw | wallyworld: FYI, possibly not going to have these changes done today. I'm going to have to change a bunch of code in state, API, etc. to use credential tags instead of names | 02:18 |
| wallyworld | not surprised | 02:18 |
| axw | so probably won't get to LXD till tomorrow | 02:18 |
| natefinch | wallyworld: the auto-upload-tools thing still seems dangerous to me. What if you have 2.0 deployed, have a 2.0.1.1 client/server built locally, but 2.2 is available in streams. What does juju upgrade-juju do? | 02:20 |
| wallyworld | upgrade to 2.2 | 02:21 |
| wallyworld | well, actually,i need to check the urgrade rules | 02:21 |
| wallyworld | if you have a 2.0.1.1, then you have built it and so are expected to know what you are doing | 02:22 |
| natefinch | wallyworld: expected to know what you're doing is a lot different than understand exactly what fine details of the code are going to do | 02:22 |
| wallyworld | i can't recall off hand how we select the allowed upgarde version when searching | 02:22 |
| natefinch | wallyworld: it seems like any time both streams and your local are valid upgrade paths, there' | 02:22 |
| wallyworld | upgrades have always been like that | 02:22 |
| natefinch | there's no way to know which one the user intends to use | 02:23 |
| wallyworld | it searches for packaged tools first | 02:23 |
| wallyworld | if it finds them, it will use them in preference | 02:23 |
| natefinch | ok | 02:23 |
| wallyworld | so whatever upgrade rules we have for selecting will be used | 02:23 |
| wallyworld | i think we look for major.minor | 02:24 |
| wallyworld | it only uploads automatically if no packaged tools are there, and only if what you have is different and only if jujud matches the client being used | 02:24 |
| natefinch | I guess my point is - I want to make sure we never automatically upgrade someone from a released version to a development version with some explicit flag or confirmation | 02:25 |
| natefinch | s/with/without/ | 02:26 |
| wallyworld | right now, there's not confirmation - it will use a jujud mactching juju | 02:31 |
| natefinch | that seems undesirable | 02:31 |
| wallyworld | so if juju is 2.1-beta1 it will upgrade a 2.0 (if the upgrade rules select such a version) | 02:32 |
| wallyworld | i'l need to check that | 02:32 |
| natefinch | I just don't want someone to get screwed who happens to build juju from source to test out the latest and greatest... forgets for a week, then upgrades their production server and boom, now they're on devel | 02:39 |
| mup | Bug #1611097 changed: cannot add/destroy a model if done too fast <oil> <oil-2.0> <juju-core:Invalid> <https://launchpad.net/bugs/1611097> | 02:40 |
| wallyworld | menn0-afk: when you are back, here's a PR to fix that test and a CI issue http://reviews.vapour.ws/r/5442/ | 02:46 |
| === menn0-afk is now known as menn0 | ||
| menn0 | wallyworld: I am back.... forgot to update nick | 02:47 |
| menn0 | looking | 02:47 |
| wallyworld | menn0: ah, i see a mistake, a wrong test suite name, fixing | 02:48 |
| wallyworld | hmm, scrap that, it can stay as is | 02:49 |
| anastasiamac | axw: wallyworld: bug 1582021 was addressed, right? | 02:54 |
| mup | Bug #1582021: Juju loses track of current controller when destroying model <2.0> <bitesize> <destroy-model> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1582021> | 02:54 |
| wallyworld | think so? | 02:54 |
| axw | don't recall exactly | 02:55 |
| anastasiamac | i'll mark as fixed committed \o/ would have been sooo very lovely to have a functional test that would just tell us :) mayb even have a link to a passing ci test in the bug :) | 02:55 |
| anastasiamac | veebers: ^^ | 02:56 |
| menn0 | wallyworld: done! | 03:04 |
| wallyworld | ta | 03:04 |
| menn0 | wallyworld, thumper: do you think I moved the notification about an available upgrade into the new NOTES status column too? | 03:08 |
| thumper | axw: why do we store the charm url on the storage instance when you can get it from the owner? | 03:08 |
| thumper | menn0: +1 | 03:09 |
| menn0 | thumper: that's what I was thinking too | 03:09 |
| thumper | menn0: showing the most relevant info | 03:09 |
| thumper | migration > upgrade available > nothing | 03:09 |
| wallyworld | menn0: yeah, good idea | 03:09 |
| axw | thumper: it's not necessarily the same. it's the charm URL that was in use when the storage instance was created, not the current one | 03:10 |
| menn0 | thumper: yep that's exactly what I was thinking | 03:10 |
| thumper | axw: but why do we care? | 03:10 |
| axw | thumper: I forget why we have it at all. we don't use it AFAIK | 03:10 |
| axw | wallyworld: do you recall? | 03:10 |
| wallyworld | um | 03:10 |
| thumper | we could just drop it, yeah? | 03:11 |
| axw | thumper: if we haven't needed it thus far, probably safe to drop it | 03:12 |
| wallyworld | thumper: axw: i can't even see where it's used | 03:12 |
| thumper | axw: you ok if I do that as part of the migration branch I'm doing? | 03:12 |
| axw | thumper: SGTM | 03:12 |
| thumper | ok, cool | 03:12 |
| axw | thanks | 03:13 |
| * thumper is looking how to add storage to the model to test exports | 03:13 | |
| wallyworld | menn0: thumper: it seems to me that in the multi-model world, stuff is not getting removed when a model is destroyed. it never used to matter in the single model case. but now for example, i can see where we are creating model settings and constraints in modelSetupOps but i can't see where this data is ever removed via calls to removeConstraintsOps etc. I can see where constraints and what not are removed for applications, units, | 03:36 |
| wallyworld | machines, but not models. am i on crack? | 03:36 |
| menn0 | wallyworld: I didn't write this stuff but RemoveAllModelDocs catches everything | 03:37 |
| menn0 | wallyworld: very brute force | 03:37 |
| * wallyworld looks at that method | 03:37 | |
| menn0 | wallyworld: not sure when/how it gets called when models are destroyed normally | 03:37 |
| menn0 | wallyworld: until yesterday it was missing user perms but I fixed that | 03:38 |
| menn0 | wallyworld: looks like the undertaker worker ends up calling it, so everything should be getting removed | 03:39 |
| wallyworld | menn0: awesome thanks | 03:39 |
| * natefinch tries for like the millionth time to use custom streams with the CI tests | 03:42 | |
| mup | Bug #1474291 changed: juju called unexpected config-change hooks after read tcp 127.0.0.1:37017: i/o timeout <bug-squad> <docs> <hooks> <openstack> <uosci> <juju-core:Invalid> <https://launchpad.net/bugs/1474291> | 03:49 |
| mup | Bug #1613516 opened: AWS instance types should be detected <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1613516> | 03:49 |
| natefinch | it's really a shame we can't just upload tools to the controller and tell it what series they're for. | 03:50 |
| thumper | OMG, state.AddApplication is 230 lines... | 03:50 |
| natefinch | at my first job out of college, the main entry function was 1000 lines long | 03:52 |
| thumper | over 100 lines of that is arg validation | 03:52 |
| thumper | natefinch: I worked at a bank where the CreateInstrument function was 10000 lines | 03:52 |
| natefinch | OMG | 03:52 |
| thumper | it was horrible | 03:52 |
| thumper | and noone wanted to fix it | 03:53 |
| natefinch | that's beyond horrible | 03:53 |
| thumper | because "what if it broke" | 03:53 |
| natefinch | yes.. what IF it broke? :/ | 03:53 |
| thumper | :) | 03:53 |
| thumper | no unit tests, just overnight regression tests | 03:53 |
| natefinch | my last job, we barely had tests. I'm sure it was like 5% coverage.... and many developers openly criticized the idea of writing tests. | 03:54 |
| natefinch | it's a damn miracle anything worked. We did have like 8 full time QA people doing manual tests, I guess. | 03:56 |
| menn0 | wallyworld: so can you show me your clouds.yaml? | 03:56 |
| wallyworld | only if you show me yours :-D | 03:56 |
| wallyworld | i'll pastrebin | 03:56 |
| wallyworld | menn0: http://paste.ubuntu.com/23060299/ | 03:57 |
| thumper | axw: able to save me some time and point me at the simplest test code that adds a storage instance to the db? | 03:57 |
| menn0 | wallyworld: I see the problem. I had my config at the wrong level... no "config" section. | 03:58 |
| thumper | axw: factory.MakeApplication? | 03:58 |
| menn0 | wallyworld: I wonder if juju add-cloud should complain if you mess this up? | 03:58 |
| menn0 | (like I did) | 03:58 |
| wallyworld | probably | 03:58 |
| veebers | wallyworld, axw: re: a test for 1582021 as mentioned by anastasiamac, does this sound reasonable for a testplan? test would bootstrap, add a new model, switch to it, (ensure status works) destroy that model then ensure that it could both "list-models" and "status" successfully? | 03:58 |
| wallyworld | veebers: if you just destroy a model and don't switch to another one, you will get an error | 04:00 |
| wallyworld | it will be interesting to repro the race condiiton | 04:00 |
| veebers | wallyworld: is that the error that is shown in the bug? Perhaps I'm not sure what the test behaviour should be | 04:05 |
| wallyworld | it depends if the bug has been fixed. the bug refers to a not found which is the original symptom. if the current model is cleared out, then there will be a different error refering to no current model selected | 04:07 |
| anastasiamac | wallyworld: veebers is writting the test to detemrine whether the bug has been fixed. he just needs to confirm if his scenario will veriffy the fix | 04:08 |
| wallyworld | right, understood. as i said, there's 2 aspects. the resetting of current model and the race | 04:08 |
| wallyworld | the error wrt the resetting of current model will depend on if the bug has been fixed. and you need to switch models if you want to avoid an error of either kind | 04:09 |
| wallyworld | if the bug has been fixed, you get the not found, if not you'll get the no current model as stated above | 04:10 |
| wallyworld | assuming you don't switch models | 04:10 |
| anastasiamac | wallyworld: the bug specifically deals with no-explicit-switch situation.. it's covered in bug description | 04:11 |
| anastasiamac | wallyworld: mark is not happy with "not found"... did u read the bug? :D | 04:11 |
| wallyworld | right, but the test also needs to cover the switch case | 04:11 |
| wallyworld | yes | 04:11 |
| veebers | wallyworld: Ok, so I want to confirm the mention bug is fixed, so I destroy and don't switch, doing a list-models or status should give me . . .something? better asked what should the expected result be | 04:11 |
| wallyworld | and as i said, if the bug has been fixed (ie current model reset), you will not get the not found | 04:11 |
| wallyworld | but you will get a different error | 04:12 |
| wallyworld | until you switch to a different model | 04:12 |
| wallyworld | i thought i explain it! you will get a different error | 04:12 |
| wallyworld | not a not found error but an error saying there is not current model | 04:13 |
| wallyworld | and if you switch everything will be ok again | 04:13 |
| veebers | ok cool, I'll run with that. Cheers | 04:14 |
| wallyworld | if you get stuck, let me know; sorry if i was unclear | 04:14 |
| axw | thumper: sorry, was having lunch. if you just add a unit whose charm has non-optional storage, it'll add a storage instance automatically | 04:15 |
| thumper | axw: is there an example of that anywhere? | 04:16 |
| thumper | do we have a testing charm that has non-optional storage? | 04:16 |
| axw | thumper: state/storage_test.go, StorageStateSuiteBase.setupSingleStorage (actually that one's non-optional, but that code sets up the storage constraints) | 04:17 |
| axw | thumper: err sorry, that one's *optional* | 04:17 |
| thumper | that'll do... | 04:18 |
| thumper | I'll crib from that | 04:18 |
| veebers | wallyworld: fyi I get the error message "..no model in focus" which seems like the bugfix is in place for that part at least | 04:24 |
| wallyworld | veebers: awesome, that means that it is fixed, yeah | 04:24 |
| wallyworld | so now the test should switch | 04:24 |
| wallyworld | and confirm that everything is ok | 04:24 |
| veebers | sweet | 04:24 |
| wallyworld | i would have thought list-models could still work though | 04:24 |
| wallyworld | even with no model in focus | 04:24 |
| wallyworld | if it doesn't that's a bug IMO | 04:25 |
| wallyworld | how do you know what to switch to | 04:25 |
| wallyworld | if you can't list models | 04:25 |
| anastasiamac | veebers: would be awesome if commented on the bug with your findings. we can change status of the bug based on ur test \o/ | 04:27 |
| veebers | wallyworld: 'models' and 'list-models' seem to work, although switching to a model doesn't seem to work, although I could be doing something off in my test code. I'll re-pro manually | 04:29 |
| wallyworld | list-models works even without a current model? cool | 04:29 |
| wallyworld | i think we set current model with a * | 04:29 |
| wallyworld | so list-models should not have the * without a current model selected | 04:30 |
| natefinch | wallyworld: I'm trying to use my own streams to run a test. if I bootstrap with --metadata-source ... where is that stored? I don't see that config val in get-model-config or get-controller config | 04:38 |
| wallyworld | it's not stored | 04:38 |
| wallyworld | what streams? tools or images? | 04:39 |
| natefinch | wallyworld: tools | 04:39 |
| wallyworld | tools are stored in blobstore | 04:39 |
| wallyworld | metadata-source is only used to tell bootstrap where to find tools to upload and store | 04:40 |
| natefinch | wallyworld: I'm trying to test something on windows, so I need a secondary machine to be able to get the windows binary that I have built. how do I do that? | 04:41 |
| wallyworld | it's not trivial | 04:42 |
| wallyworld | one way is to use agent-metadata-url pointing to an apache http server | 04:42 |
| natefinch | well, so I have tools & streams generated and sitting in S3 | 04:42 |
| wallyworld | if it's a public bucket you could use that url as agent-metadata-url | 04:43 |
| natefinch | wallyworld: ok, I thought metadata-source would have done that, but I can set metadata-url, that's fine | 04:43 |
| natefinch | er agent-metadata-url | 04:43 |
| wallyworld | metadataa-source -s just fpr bootstrap | 04:44 |
| wallyworld | to tell it where to find a local (as in dir) source of tools/image metadata | 04:44 |
| wallyworld | generated using the plugins | 04:44 |
| wallyworld | which is then sent to controller suring bootstrap and stored in state | 04:44 |
| natefinch | ahh... then maybe it should complain if I give it a URL :/ | 04:45 |
| wallyworld | file:// is a url | 04:45 |
| wallyworld | which it uses | 04:45 |
| wallyworld | i guess it could complain if not file:// | 04:45 |
| wallyworld | or a dir | 04:45 |
| natefinch | but --metadata-source https://s3.amazonaws.com/24b99da448314945835933a0c8edffb3 just fails silently | 04:45 |
| natefinch | not fails... is ignored | 04:45 |
| wallyworld | yeah, there's not been much polish on dev only tools | 04:45 |
| wallyworld | i didn't think it failed, that must be a new bug | 04:46 |
| natefinch | bootstrap doesn't fail, which is kind of the problem | 04:47 |
| menn0 | thumper or wallyworld or anastasiamac: MM status in tabular output http://reviews.vapour.ws/r/5444/ | 04:48 |
| wallyworld | ok | 04:49 |
| wallyworld | menn0: i asked for one more test | 04:55 |
| menn0 | wallyworld: I thought of that one but was being lazy. done now :)_ | 05:14 |
| wallyworld | :-) | 05:14 |
| wallyworld | we've all been there | 05:15 |
| wallyworld | you have a shipit anyway | 05:15 |
| mup | Bug #1613537 opened: metadata-source doesn't sanity check the value you give it <juju-core:New> <https://launchpad.net/bugs/1613537> | 05:19 |
| wallyworld | axw: if you had a moment at any time, this is a mechanical change to the model defaults api to accommodate cloud/region. not used yet but will be when reed's stuff gets further along http://reviews.vapour.ws/r/5445/ | 05:44 |
| axw | wallyworld: ok, in a little while | 05:46 |
| wallyworld | sure, no hurry | 05:46 |
| axw | wallyworld: one fundamental thing: we have cloud tags now, should be using that instead of just a cloud name | 05:48 |
| wallyworld | ah, yeah | 05:48 |
| wallyworld | doh | 05:49 |
| wallyworld | fixing | 05:49 |
| wallyworld | axw: updated for when you get to look later | 05:58 |
| wallyworld | thans axw | 06:09 |
| axw | np | 06:09 |
| mup | Bug #1551959 changed: juju-tools 1.25.0 with juju-agent 1.25.3 has networking issues <juju-core:Won't Fix> <https://launchpad.net/bugs/1551959> | 06:19 |
| anastasiamac | wallyworld: axw: just to confirm - i believe this bug has been fixed with new model naming convention that includes user name, non? :D bug 1576359 | 06:22 |
| mup | Bug #1576359: Cannot talk to a new model with a reused name <juju-release-support> <switch> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1576359> | 06:22 |
| wallyworld | not sure off hand | 06:23 |
| wallyworld | i wasn't familar with that bug | 06:23 |
| anastasiamac | axw: ? :D | 06:23 |
| axw | anastasiamac: not sure that that one is fixed | 06:23 |
| axw | anastasiamac: I don't think I did anything specifically that would have fixed that | 06:23 |
| anastasiamac | axw: wallyworld: k. thnx | 06:24 |
| axw | wallyworld: https://github.com/juju/names/pull/72 - sorry, third time's the charm perhaps? | 06:31 |
| mup | Bug #1100560 changed: Support method of removing a subordinate charm <canonical-is> <canonical-webops-juju> <remove-relation> <subordinate> <pyjuju:Won't Fix> <juju-core:Invalid> <https://launchpad.net/bugs/1100560> | 06:31 |
| mup | Bug #1432759 changed: Transient error on status while running deployments via quickstart <api> <quickstart> <race-condition> <status> <juju-core:Invalid> <https://launchpad.net/bugs/1432759> | 06:31 |
| wallyworld | axw: just gotta race out to school pickup, will look when i get back | 06:31 |
| axw | np | 06:31 |
| wallyworld | am running really late | 06:31 |
| === rogpeppe is now known as rogpeppe1 | ||
| miken | anastasiamac: Hey there. Just to be clear, bug 1613491 is not critical for me - we're working around it easily enough. | 06:52 |
| mup | Bug #1613491: juju service names limited to 66 characters <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1613491> | 06:52 |
| anastasiamac | miken: awesome \o/ thank you - i've updated the bug | 06:53 |
| mup | Bug # changed: 862422, 1228355, 1301255, 1340756, 1468223 | 07:01 |
| === frankban|afk is now known as frankban | ||
| mup | Bug # changed: 1217814, 1283866, 1398589, 1401358, 1403460, 1417149, 1420996 | 07:28 |
| axw | wallyworld rogpeppe: this PR should address concerns about the cloud API, and also updates other bits to use the new cloud credential tag: http://reviews.vapour.ws/r/5447/ | 07:29 |
| rogpeppe | axw: i'll swap ya :) http://reviews.vapour.ws/r/5439/ | 07:29 |
| axw | rogpeppe: sure, looking | 07:29 |
| axw | rogpeppe: hmm, I think it was intentional to leave them there, so old clients can get a useful error message | 07:31 |
| rogpeppe | axw: won't they still get the same error message?> | 07:31 |
| rogpeppe | axw: i think i tried to leave the behaviour unchanged. perhaps i didn't though... | 07:32 |
| axw | rogpeppe: maybe? I just saw a test that removed a check for the error message, so assumed it didn't any more | 07:32 |
| * axw looks deeper | 07:32 | |
| rogpeppe | axw: ah, yes, maybe i removed that test when i shouldn't have | 07:32 |
| wallyworld | the idea is that older 1.25 clients should get a nice message | 07:32 |
| wallyworld | not sure of the details though | 07:33 |
| rogpeppe | wallyworld: yes, they still should, but yeah, i removed some of the infrastructure that supported the test | 07:33 |
| wallyworld | if it works with the proposed changes, then that's ok | 07:33 |
| wallyworld | +1 to deleting code if it makes sense :-) | 07:34 |
| rogpeppe | wallyworld: i think we could keep the test but make it manually call Login with version 2; no need for OpenWithVersion, I think. | 07:35 |
| wallyworld | sgtm, keep as little as possible | 07:35 |
| mup | Bug #1494936 changed: imageSuite.TestDownloadEnvironmentPath <bug-squad> <ci> <intermittent-failure> <panic> <simplestreams> <unit-tests> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1494936> | 07:40 |
| mup | Bug #1494936 opened: imageSuite.TestDownloadEnvironmentPath <bug-squad> <ci> <intermittent-failure> <panic> <simplestreams> <unit-tests> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1494936> | 07:49 |
| mup | Bug #1494936 changed: imageSuite.TestDownloadEnvironmentPath <bug-squad> <ci> <intermittent-failure> <panic> <simplestreams> <unit-tests> <wily> <juju-core:Invalid> <https://launchpad.net/bugs/1494936> | 07:58 |
| rogpeppe | axw: reviewed | 08:09 |
| axw | rogpeppe: ta | 08:13 |
| axw | rogpeppe: I'd prefer to leave mention of user/cred syntax in the help docs until we have a means to share | 08:26 |
| rogpeppe | axw: "a means to share" ? | 08:27 |
| axw | rogpeppe: share credentials - ACLs | 08:27 |
| axw | rogpeppe: i.e. you may be able to use the syntax user/cred, but it won't work unless user == you | 08:28 |
| rogpeppe | axw: the problem is that historically that means we'll forget to add it to the help docs | 08:28 |
| axw | rogpeppe: I'd rather that than confuse people by having them think they can do something they can't | 08:28 |
| rogpeppe | axw: i'd add it to the help docs and add a caveat that currently the user must be the same as the model user | 08:28 |
| rogpeppe | axw: or, tbh, since it'll just fail, that's probably fine | 08:29 |
| rogpeppe | axw: it'll fail with "permission denied" presumably | 08:29 |
| rogpeppe | axw: which is exactly how it would fail if the permissions hadn't been shared | 08:29 |
| axw | rogpeppe: "not found" at the moment I think | 08:29 |
| rogpeppe | axw: even if the other user's creds actually exist? | 08:30 |
| rogpeppe | axw: oh yes, because that's what we always do for perm denied i guess | 08:30 |
| axw | rogpeppe: yeah. generally we do that so you can't sniff out info | 08:30 |
| rogpeppe | axw: so, i think it's fine to document the syntacx | 08:30 |
| rogpeppe | axw: then when we implement sharing, people will find a use for it | 08:31 |
| axw | rogpeppe: ok | 08:32 |
| rogpeppe | axw: also, describing it in the help docs is often a good indicator as to whether it's a decent feature or not | 08:32 |
| rogpeppe | axw: i.e. can it be described nicely | 08:32 |
| rogpeppe | ? | 08:32 |
| rogpeppe | axw: tell me about CreateLocalLoginMacaroon | 08:54 |
| axw | rogpeppe: it's how you get a macaroon that you can log into a controller as a local user | 08:56 |
| axw | rogpeppe: what do you want to know about it in particular...? | 08:56 |
| rogpeppe | axw: i'm just wondering if it should be part of the controller-only API or not | 08:57 |
| axw | rogpeppe: yes, it is a controller level thing | 08:57 |
| rogpeppe | axw: i'm getting a test failure where login fails | 08:58 |
| rogpeppe | axw: because it's using the model-level connection (that it's using to log in) but then uses that to create a local login macaroon | 08:58 |
| rogpeppe | axw: and that fails because UserManager is controller-only | 08:59 |
| axw | rogpeppe: what's the test? | 08:59 |
| rogpeppe | axw: featuretests.cmdLoginSuite.TestLoginCommand | 08:59 |
| rogpeppe | axw: it seems like a legit failure to me | 08:59 |
| axw | rogpeppe: ah, it's actually being used in change-user-password | 09:00 |
| axw | which should be controller-only.. | 09:00 |
| rogpeppe | axw: it is | 09:01 |
| rogpeppe | axw: changePasswordCommand embeds ControllerCommandBase | 09:01 |
| rogpeppe | axw: hmm, so is login actually | 09:01 |
| rogpeppe | axw: so now i'm confused :) | 09:02 |
| axw | rogpeppe: that should mean they're getting controller API connections | 09:02 |
| rogpeppe | axw: yup | 09:02 |
| rogpeppe | axw: so it should work, but i'm getting | 09:02 |
| rogpeppe | [LOG] 0:00.242 ERROR cmd failed to create a temporary credential: permission denied (unauthorized access) | 09:02 |
| axw | rogpeppe: sorry, nothing's jumping out from the code... login is passing "" for the model name to get the API connection | 09:04 |
| rogpeppe | axw: yeah, there's something odd going on. thanks. | 09:05 |
| rogpeppe | axw: now i just have to work out how to get the featuretests to show trace-level debug logs of the api server | 09:06 |
| axw | rogpeppe: loggo.GetLogger("juju.apiserver").SetLogLevel(loggo.TRACE) | 09:07 |
| axw | I think | 09:07 |
| rogpeppe | axw: i'll try that | 09:07 |
| rogpeppe | axw: still not seeing any api server traffic (i also tried GetLogger with "" and "<root>") | 09:11 |
| rogpeppe | axw: ISTR working out a way to do this before, but it's gone from my memory now unfortunately | 09:12 |
| babbageclunk | rogpeppe: I've never managed to set the root logger level using GetLogger("<root>") - try using ConfigureLoggers instead. | 09:20 |
| rogpeppe | babbageclunk: ha, thanks | 09:20 |
| rogpeppe | babbageclunk: the loggo code thinks that it should be "" | 09:21 |
| babbageclunk | rogpeppe: ah, that might be what I got wrong | 09:22 |
| rogpeppe | babbageclunk: but i suspect that all the logging is being lost | 09:22 |
| rogpeppe | babbageclunk: GetLogger should really have a comment | 09:22 |
| rogpeppe | babbageclunk: or better, all loggers should start with "." so you wouldn't need a special case for <root>; "." would always be the root logger. | 09:22 |
| rogpeppe | babbageclunk: too late for that now though | 09:23 |
| babbageclunk | dimitern: do you know if Will's out all week? | 09:26 |
| dimitern | babbageclunk: I don't know - yesterday was a public holiday in Malta IIRC | 09:27 |
| babbageclunk | dimitern: Ah, ok. | 09:27 |
| babbageclunk | dimitern: Although he might have piggybacked a holiday on that. | 09:28 |
| babbageclunk | dimitern: Do you have any more comments other than the model tag checking stuff in http://reviews.vapour.ws/r/5366/? | 09:29 |
| dimitern | babbageclunk: let me have a look.. | 09:29 |
| babbageclunk | dimitern: Thanks! I made the other changes you suggested. | 09:30 |
| babbageclunk | dimitern: I've finished (for some value of finished :) the api client as well. | 09:31 |
| rogpeppe | axw: ok, i just about succeeded. the problem is that juju/cmd.Log.Start tries to make the logs go to ctx.Stderr; it tries to replace the default loggo writer, but there isn't one. we should make it so you can just see the logs when desired, i think. maybe add another writer or something. | 09:32 |
| macgreagoir | wallyworld axw: I have that AddController change merged, much thanks. | 09:34 |
| dimitern | babbageclunk: machineundertaker will be running once per model, right? | 09:35 |
| axw | macgreagoir: thank you :) | 09:35 |
| dimitern | babbageclunk: i.e. it will be configured inside cmd/jujud/agent/model/manifolds.go ? | 09:37 |
| dimitern | like the space importer, etc. | 09:37 |
| babbageclunk | dimitern: I think so? Where's environ-tracker? | 09:38 |
| babbageclunk | dimitern: Yes, in cmd/jujud/agent/model/manifolds.go | 09:38 |
| dimitern | babbageclunk: yeah, it's there as well | 09:39 |
| babbageclunk | dimitern: I think you're right that the model tag is unnecessary. | 09:39 |
| dimitern | babbageclunk: yeah, that's what I'm getting at :) | 09:39 |
| rogpeppe | axw: ah! i've discovered what the problem is. CreateLocalLoginMacaroon isn't considered a read-only call | 09:39 |
| babbageclunk | dimitern: But I'm reluctant to pull it out and then have Will explain a sensible reason why it's needed and then have to put it back in. | 09:39 |
| dimitern | babbageclunk: as long as you're a model manager, there's no need to check or take a model tag (uuid) to work on - you'll only every work on one model anyway | 09:40 |
| axw | rogpeppe: why is that a problem? | 09:40 |
| dimitern | babbageclunk: I'm interested to learn Will's reasoning for having ConnectedModel() ? | 09:40 |
| rogpeppe | axw: because in that test i'm guessing the user is read-only | 09:40 |
| rogpeppe | axw: (i haven't checked) | 09:41 |
| babbageclunk | dimitern: But you mentioned in your review that there were some other things you were thinking about as well? | 09:41 |
| rogpeppe | axw: but in general, i think it's probably OK for even read-only users to be able to create a login macaroon | 09:41 |
| babbageclunk | dimitern: ConnectedModel is only needed for the model checking. | 09:41 |
| axw | rogpeppe: yeah probably. it's not writing anything to the model | 09:41 |
| rogpeppe | axw: yup | 09:41 |
| rogpeppe | axw: i haven't yet worked out why this has changed in my branch though | 09:42 |
| dimitern | babbageclunk: so AuthModelManager() being true means you've logged in as a machine agent with jobmanagermodel | 09:43 |
| dimitern | babbageclunk: it's true authorizer.GetAuthTag() does not give you the model uuid, just that machine tag you logged in as | 09:44 |
| dimitern | babbageclunk: but then again, the model manager engine runs per model | 09:44 |
| dimitern | babbageclunk: in startModelWorkers (cmd/jujud/agent/machine.go) | 09:46 |
| babbageclunk | dimitern: ok (reading) | 09:47 |
| dimitern | babbageclunk: so, if checking whether the model uuid matches was an issue, it should've been done for at least some of the other workers+facades part of the model manager manifold | 09:47 |
| dimitern | unless I'm missing something.. | 09:48 |
| babbageclunk | dimitern: Yeah, in which case we'd have needed ConnectedModel ages ago. | 09:48 |
| babbageclunk | Ok, I'm convinced. It's easy to rip it out, and I'll keep the commit around so that it should be easy to put it back in if Will convinces us the other way. | 09:49 |
| dimitern | babbageclunk: only if we need to test impossible cases :) | 09:49 |
| dimitern | babbageclunk: but Will might have another good reason | 09:50 |
| dimitern | babbageclunk: i.e. being explicit about which uuid you should allow in the facade | 09:50 |
| dimitern | babbageclunk: but if that's the case, then it's much easier to take modelTag as argument to machineundertaker.NewAPI(), store it and check it internally | 09:50 |
| babbageclunk | dimitern: I think it might have been something like that. Hang on, I'll find the conversation in the logs. | 09:51 |
| dimitern | babbageclunk: I'm happy to be proven wrong :) | 09:51 |
| dimitern | babbageclunk: perhaps the intent is to call AllMachineRemovals() with multiple model uuids as args, say if we're tearing down more than 1 model | 09:53 |
| dimitern | babbageclunk: but this means we're designing the facade with the intent to make it global, not per-model, and to allow 1 instance of machineundertaker to run for all models - then it makes sense | 09:54 |
| babbageclunk | dimitern: No, I don't think so. As you say, we'll be connected to one model. | 09:54 |
| dimitern | babbageclunk: I'll add some comments | 09:55 |
| dimitern | if we had JobManageController, implying "can manage all hosted models", then fine.. | 09:57 |
| babbageclunk | dimitern: For some more background (but nothing conclusive as far as I can tell) search for ConnectedModel in here: https://irclogs.ubuntu.com/2016/08/09/%23juju-dev.txt | 09:58 |
| dimitern | babbageclunk: cheers, will do | 09:58 |
| babbageclunk | dimitern: But yeah, if you've got any other suggestions for changes, I'll make those before ripping out the model checking so that it should still be easy to put it back. | 09:59 |
| dimitern | babbageclunk: do you have a link to Will's previous review about AllMachineRemovals() taking a list of model tags? | 10:01 |
| babbageclunk | dimitern: It's in comments on katco's review - not much detail I'm afraid. | 10:02 |
| dimitern | ah ok | 10:04 |
| babbageclunk | fwereade: Hey! Speak of the devil! | 10:10 |
| fwereade | babbageclunk, hey, sorry | 10:11 |
| fwereade | babbageclunk, was signed into canonical but not here for some reason | 10:11 |
| fwereade | babbageclunk, what can I do for you? | 10:11 |
| babbageclunk | dimitern and I are trying to understand why AllMachineRemovals needs to take the model uuid? | 10:13 |
| babbageclunk | fwereade: (as seen in http://reviews.vapour.ws/r/5366/) | 10:13 |
| fwereade | babbageclunk, the api method? | 10:18 |
| babbageclunk | fwereade: yeah | 10:19 |
| rogpeppe | axw: ok, i've found out what's happening. prior to my change, all the controller-only facades were accessible to read-only users, but now the read-only layer always applies | 10:19 |
| fwereade | babbageclunk, because depending on the connection state is generally unhelpful, and silently ties the implementation down so it can't be moved to other contexts | 10:19 |
| rogpeppe | axw: i have a problem with apiserver.admin.doLogin - it's too big and hard to understand for such a security-crucial method | 10:20 |
| babbageclunk | dimitern: ^^ | 10:20 |
| fwereade | babbageclunk, we have multi-model controllers -- even if all our connections right now have an implicit model, that's not fundamental to the problem space | 10:20 |
| fwereade | babbageclunk, when you're talking to a controller directly, for example, there are going to be at least some things you can rationally do to all-your-known-models | 10:21 |
| fwereade | babbageclunk, and so just making sure we name our targets from the beginning makes it trivial to extend that code out, differing only in auth concerns, as we grow | 10:22 |
| fwereade | babbageclunk, sane? | 10:22 |
| babbageclunk | fwereade: yeah, that makes sense to me. dimitern? | 10:22 |
| dimitern | babbageclunk, fwereade: catching up now | 10:23 |
| fwereade | babbageclunk, note, tangentially, that controllers make an additional api connection per hosted model, and this is kinda silly -- the fact that implicit-model is baked in all over the place makes it necessary for the moment, but it's not a Good Thing, and writing our code *without* assuming that context will help us if/when we actually address that | 10:24 |
| dimitern | fwereade: so you're saying AllMachineRemovals(modelTags ...) is a good method to have on a facade that's only going to work against a single model? | 10:24 |
| fwereade | dimitern, yes | 10:24 |
| fwereade | dimitern, this shoudl not even be a question in your mind | 10:24 |
| fwereade | dimitern, because I don't want it to be a question in consumers' minds either | 10:25 |
| fwereade | dimitern, facade methods accept bulk args, full stop :) | 10:25 |
| dimitern | fwereade: I'm trying to see why - if in the future that same facade is used by a controllerManager worker of sorts, that can deal with multiple hosted models, that's fine | 10:25 |
| dimitern | fwereade: but which model you're working on seems to align well with the SRP | 10:26 |
| fwereade | dimitern, well, no, because you can't share the implementation without a rewrriate that takes implicit state into account | 10:26 |
| fwereade | dimitern, it's really just another special case of "explicit is better than implicit" | 10:27 |
| dimitern | fwereade: are we going to change all the other modelmanager manifold workers to use that approach? | 10:27 |
| fwereade | dimitern, which ones are not? | 10:27 |
| fwereade | dimitern, this is not even remotely in question | 10:27 |
| dimitern | fwereade: I see how this is good, but it irked me as inconsistent w.r.t current code examples | 10:27 |
| fwereade | dimitern, it has been How You Write An API from the very beginning | 10:27 |
| dimitern | fwereade: well, not so much for models | 10:27 |
| dimitern | fwereade: but I guess why not | 10:28 |
| fwereade | dimitern, we didn't even have models | 10:28 |
| fwereade | dimitern, name your targets | 10:28 |
| dimitern | fwereade: well, different models are likely to have different cloud creds | 10:28 |
| fwereade | dimitern, and? | 10:28 |
| dimitern | fwereade: it seems to me we need a new JobManageController or something | 10:29 |
| fwereade | dimitern, we just need a JobFlag in the machine agent, I think | 10:29 |
| dimitern | fwereade: I'm not that familiar with the flags yet | 10:30 |
| dimitern | fwereade: but fair enough | 10:30 |
| fwereade | dimitern, the whole flag implementation is in jujud/agent/engine, it's pretty comprehensible | 10:30 |
| dimitern | fwereade: how about machineundertaker.NewAPI() taking a modelUUID / tag to work on | 10:30 |
| fwereade | dimitern, the two workers that implement engine.Flag are pretty trivial | 10:30 |
| fwereade | dimitern, is that apiserver-side? | 10:31 |
| fwereade | dimitern, then, no | 10:31 |
| dimitern | fwereade: yeah | 10:31 |
| dimitern | fwereade: isn't that more explicit than going through the authorizer each time? | 10:31 |
| fwereade | dimitern, what you are saying is "I have a special case that I can imagine a different implementation, please may I throw consistency to the winds and take on secret technical debt?" | 10:32 |
| fwereade | dimitern, just accept your Entities like every other method should | 10:32 |
| dimitern | fwereade: I'm just saying we can change the NewAPI constructor if we need later, keep the AllMachineRemovals() as-is (taking model tags), and have a slightly simpler initial implementation | 10:33 |
| fwereade | dimitern, api-side, sure, create the type with a single ModelUUID and call .AllMachineRemovals() -- but we want the data we send over the wire to make sense in isolation | 10:33 |
| fwereade | dimitern, how do we change the NewAPI constructor? isn't that essentially constrained by the facade package? | 10:34 |
| fwereade | dimitern, as it is we have the implicit model known because we have the *State, and yes, unpicking that will be tedious | 10:34 |
| dimitern | fwereade: it is, but it's not visible to api clients, and can change without breaking the wire format of the facede | 10:35 |
| rogpeppe | [11:21:24] <fwereade> babbageclunk, when you're talking to a controller directly, for example, there are going to be at least some things you can rationally do to all-your-known-models | 10:35 |
| rogpeppe | fwereade: FWIW controller-only APIs exist in a separate space | 10:35 |
| rogpeppe | fwereade: so it will of necessity be a different facade in that case | 10:35 |
| dimitern | fwereade: ok, I just wanted to clarify your reasons for asking to add ConnectedModel() | 10:35 |
| fwereade | rogpeppe, ofc | 10:35 |
| dimitern | fwereade: I don't mind it otherwise | 10:36 |
| fwereade | rogpeppe, facades should basically be thin and just contain auth handling, and hand over to shared backend implementations | 10:36 |
| rogpeppe | fwereade: so (assuming I've understood the gist correctly) I have no objection to a connection on a model-only API not taking the model tag as parameters | 10:36 |
| fwereade | rogpeppe, right, but I do | 10:37 |
| rogpeppe | fwereade: i don't get it | 10:37 |
| rogpeppe | fwereade: we don't pass the model tag when, say, adding a service | 10:37 |
| fwereade | rogpeppe, right, and that is also unhelpful | 10:40 |
| rogpeppe | fwereade: i really don't understand. what's the purpose in passing redundant information over the API other than to add more possible error paths and code bloat generally? | 10:40 |
| fwereade | rogpeppe, because it expands the scope of places you need to know and understand to comprehend the meaning and effect of a given api call | 10:42 |
| fwereade | rogpeppe, tell me more about how extra magic reduces error paths | 10:42 |
| rogpeppe | fwereade: i don't consider denormalisation "less magic". it's just more code. | 10:42 |
| rogpeppe | fwereade: understanding that an API connection is per-model is fundamental currently | 10:43 |
| rogpeppe | fwereade: i think it actually makes the code *harder* to understand | 10:44 |
| fwereade | rogpeppe, except for the connection ones, which are a bit more interesting in how they interact with one-or-maybe-many models | 10:44 |
| rogpeppe | fwereade: because someone that starts to understand it will think "but why is this necessary?" and there's no good answer | 10:44 |
| rogpeppe | fwereade: "the connection ones"? | 10:44 |
| fwereade | rogpeppe, s/connection/controller/ sorry | 10:45 |
| rogpeppe | fwereade: sure, the controller ones are indeed not model-specific, and that's also fundamental currently. | 10:45 |
| rogpeppe | fwereade: and to work on the API you need to have a good understanding of that | 10:46 |
| rogpeppe | fwereade: and adding unnecessary parameters just confuses matters | 10:46 |
| fwereade | rogpeppe, it's not fundamental at all, it's a consequence of trying to enforce conn<->model in the first place | 10:46 |
| rogpeppe | fwereade: we already have hideous amounts of code bloat and it seems like you *like* that | 10:47 |
| rogpeppe | fwereade: the conn<->model thing is fundamental to our architecture | 10:47 |
| fwereade | rogpeppe, I am surprised that you would pick such a fight on the battleground of "the one approach that actually gets us reused code in apiserver" | 10:47 |
| fwereade | rogpeppe, no, it's just a lazy mistake | 10:47 |
| rogpeppe | fwereade: it's actually not | 10:47 |
| rogpeppe | fwereade: anyway, as i've said far too many times before, bulk calls are an expensive red herring | 10:51 |
| rogpeppe | fwereade: not that that specifically applies in this case other than the requirement to watch several models at once. | 10:51 |
| rick_h_ | dimitern: ping for sync? | 11:03 |
| dimitern | rick_h_: oops, omw | 11:03 |
| rick_h_ | fwereade: ping when you get a sec please. Would like to sync up in https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1 | 11:21 |
| mup | Bug #1613672 opened: Nothing prevents ModelManager.DestroyModels from destroying the controller model <juju-core:New> <https://launchpad.net/bugs/1613672> | 11:47 |
| mup | Bug #1613672 changed: Nothing prevents ModelManager.DestroyModels from destroying the controller model <juju-core:New> <https://launchpad.net/bugs/1613672> | 11:53 |
| rogpeppe | it's always nice when you start to create a new bug and find that not only is there an existing bug report but the fix went in a couple of hours ago :) https://bugs.launchpad.net/juju-core/+bug/1593350 | 11:54 |
| mup | Bug #1593350: Juju register allows users to register alternatively named controllers of the same UUID <juju-core:Fix Committed by macgreagoir> <https://launchpad.net/bugs/1593350> | 11:54 |
| mup | Bug #1613672 opened: Nothing prevents ModelManager.DestroyModels from destroying the controller model <juju-core:New> <https://launchpad.net/bugs/1613672> | 11:59 |
| mup | Bug #1613688 opened: adding a controller user gives user read-write access to all models <juju-core:New> <https://launchpad.net/bugs/1613688> | 12:17 |
| wallyworld | dimitern: please has review of small test fix? http://reviews.vapour.ws/r/5448/ | 13:00 |
| wallyworld | or perrito666 ? ^^^^ | 13:19 |
| perrito666 | wallyworld: checking | 13:20 |
| perrito666 | wallyworld: shipit | 13:21 |
| wallyworld | yay | 13:21 |
| wallyworld | ty | 13:21 |
| perrito666 | now go to sleep | 13:22 |
| anastasiamac | wallyworld: perrito666 sadi it ^^ | 13:24 |
| anastasiamac | said* | 13:24 |
| wallyworld | soon | 13:24 |
| * rick_h_ goes for a coffee run | 13:27 | |
| voidspace | frobware: ping | 14:00 |
| frobware | voidspace: pong | 14:00 |
| voidspace | frobware: what's the best ppa for maas 1.9? | 14:00 |
| voidspace | frobware: for trusty | 14:00 |
| rick_h_ | natefinch: dimitern ping for standup | 14:00 |
| frobware | voidspace: pretty sure that ppa:maas/stable | 14:01 |
| voidspace | frobware: sounds good - thanks | 14:01 |
| dimitern | omw | 14:02 |
| perrito666 | dimitern: around? | 14:23 |
| dimitern | perrito666: o/ | 14:24 |
| natefinch | mgz: was it juju.environs.simplestreams that I needed at TRACE? Don't want to run an 8 minute bootstrap to figure it out :/ | 14:36 |
| mgz | natefinch: yeah, but let me just double check | 14:40 |
| mgz | natefinch: yeah, that's what I did last time, probably doesn't hurt to do juju.environs as a whole, as some things have likely changed since then | 14:43 |
| natefinch | ahh yes, the trickle down effect | 14:45 |
| mgz | natefinch: remember to do --show-log or --log-file global options as well | 14:45 |
| natefinch | there's tools-metadata-url and agent-metadata-url.... what's the difference? | 14:45 |
| mgz | tools- is the old name | 14:46 |
| mgz | they end up at the same place | 14:46 |
| natefinch | ok | 14:46 |
| voidspace | frobware: does maas 1.9 have vlans? | 14:48 |
| frobware | voidspace: yes | 14:48 |
| frobware | voidspace: but much easier to set them up in /e/n/i before installation of maas | 14:48 |
| voidspace | frobware: ah yes, they need to be in /e/n/i of the rack controller | 14:49 |
| voidspace | I forgot, thanks | 14:49 |
| voidspace | I've already installed maas unfortunately | 14:49 |
| voidspace | I'll add it and restart maas and see if it picks it up | 14:49 |
| frobware | voidspace: it won't :( | 14:50 |
| voidspace | frobware: bl**dy fecking bunghole | 14:51 |
| voidspace | frobware: thanks | 14:51 |
| katco | /names | 15:15 |
| katco | [12:35] <katco> rick_h_: ok | 15:15 |
| katco | <rick_h_> katco: ty | 15:15 |
| katco | [12:38] <mup> Bug #1612744 opened: MachinerSuite.TestMachinerMachineAssignedUnits agent should be terminated <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612744> | 15:15 |
| katco | <mup> Bug #1612745 opened: rackerSuite.TestGainLeadership number of ClaimLeadership is wrong <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612745> | 15:15 |
| mup | Bug #1612744: MachinerSuite.TestMachinerMachineAssignedUnits agent should be terminated <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612744> | 15:15 |
| mup | Bug #1612745: rackerSuite.TestGainLeadership number of ClaimLeadership is wrong <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612745> | 15:15 |
| katco | <mup> Bug #1612747 opened: DebugHooksServerSuite.TestRunHook signal: killed <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612747> | 15:15 |
| mup | Bug #1612747: DebugHooksServerSuite.TestRunHook signal: killed <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1612747> | 15:15 |
| katco | [12:46] * rick_h_ gets some lunch with that done | 15:15 |
| katco | [13:09] <kwmonroe> ejat: i use juju/azure | 15:15 |
| katco | [13:10] <ejat> kwmonroe: okie .. its working now .. thanks | 15:15 |
| katco | [14:11] <redir> bbiab | 15:15 |
| katco | [14:19] * rick_h_ runs to get my truck and the boy from summer camp. have a good weekend folks | 15:15 |
| katco | [14:30] <mup> Bug #1612775 opened: resource get fails, resource already staged <juju-core:New> <https://launchpad.net/bugs/1612775> | 15:15 |
| katco | [15:02] <perrito666> it would be extremely nice of us to name the same thing in the same way across facades | 15:15 |
| mup | Bug #1612775: resource get fails, resource already staged <juju-core:Triaged> <https://launchpad.net/bugs/1612775> | 15:15 |
| katco | <redir> perrito666: novel idea | 15:15 |
| katco | [15:03] <perrito666> authorizer and state are called something different across all facades | 15:15 |
| katco | [15:04] <perrito666> and just found one without authorizer | 15:15 |
| katco | [15:13] <natefinch> sinzui: are you still having problems with that windows deploy CI test? I seem to be able to deploy a windows charm just fine on azure | 15:15 |
| katco | <sinzui> natefinch: I think not. I am still wating for one to complete to say all is well | 15:15 |
| katco | <sinzui> natefinch: once juju broke the reate limit. azure locked our for many hours | 15:15 |
| katco | <natefinch> sinzui: great :) | 15:15 |
| katco | [15:14] <natefinch> oops | 15:15 |
| katco | [15:19] <sinzui> natefinch: I see some azure successes. most failed though.I suspect the failure were at the tail end of the lockout. I will retest. | 15:15 |
| katco | [15:27] <katco> sinzui: hey does qa have any plans to release the qa tools as a snap? | 15:16 |
| katco | <sinzui> katco: we expect to do dailies | 15:16 |
| katco | <katco> sinzui: daily releases of the qa tools? | 15:16 |
| rick_h_ | katco: ummm, howdy? | 15:16 |
| katco | [15:28] <sinzui> katco: oh, no. no plans to snape jujuc-ci-tools or juju-release-tools | 15:16 |
| katco | <katco> sinzui: sorry, jujuc-ci-tools | 15:16 |
| perrito666 | gotta love emacs | 15:16 |
| katco | <katco> sinzui: having just gone through the setup process, it would be awesome to just download a snap | 15:16 |
| katco | [15:29] <sinzui> maybe balloons will want try it. Since snap doesn't work with windows, centos, or osx, we are dedicated to working with a common solution. | 15:16 |
| katco | [15:30] <katco> sinzui: ah good point | 15:16 |
| katco | <mup> Bug #1612793 opened: bootstrap azure/southcentralus is failing in 2.0-betaX <juju-core:New> <https://launchpad.net/bugs/1612793> | 15:16 |
| mup | Bug #1612793: bootstrap azure/southcentralus is failing in 2.0-betaX <azure-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1612793> | 15:16 |
| rick_h_ | perrito666: heh, is this the equiv of a emacs core-dump? | 15:16 |
| katco | [15:39] <perrito666> ... obtained int = 2 | 15:16 |
| perrito666 | mgz: | 15:16 |
| katco | <perrito666> ... expected int = 2 | 15:16 |
| katco | <perrito666> evidently | 15:16 |
| natefinch | lol | 15:16 |
| katco | [15:44] <katco> yay my recator compiles for the 1st time | 15:16 |
| katco | <katco> refactor | 15:16 |
| katco | [16:39] <mup> Bug #1612335 changed: Azure rate limit leads to catastrophic failure for subscription <azure-provider> <bootstrap> <ci> <destroy-controller> <kill-controller> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1612335> | 15:16 |
| mup | Bug #1612335: Azure rate limit leads to catastrophic failure for subscription <azure-provider> <bootstrap> <ci> <destroy-controller> <kill-controller> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1612335> | 15:16 |
| natefinch | someone pasted the wrong thing into their IRC window | 15:16 |
| katco | <mup> Bug #1612722 changed: Juju cannot destroy models/machine, all testing substrates are exhausted <blocker> <ci> <destroy-controller> <kill-controller> <regression> <juju-core:Fix Released by rharding> <https://launchpad.net/bugs/1612722> | 15:16 |
| katco | [16:48] <mup> Bug #1612836 opened: Cannot bring up hosted model machines in azure <azure-provider> <ci> <deploy> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1612836> | 15:16 |
| mup | Bug #1612722: Juju cannot destroy models/machine, all testing substrates are exhausted <blocker> <ci> <destroy-controller> <kill-controller> <regression> <juju-core:Fix Released by rharding> <https://launchpad.net/bugs/1612722> | 15:16 |
| mup | Bug #1612836: Cannot bring up hosted model machines in azure <azure-provider> <ci> <deploy> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1612836> | 15:16 |
| katco | [17:14] <katco> rick_h_: ping, don't suppose you're on | 15:16 |
| katco | [17:34] <perrito666> mmm, ppas dont work nicely with my deb proxy | 15:16 |
| katco | [20:15] <redir> EoW. LALters | 15:16 |
| katco | <redir> laters even | 15:17 |
| katco | ERC> | 15:17 |
| natefinch | last time on juju-dev.... | 15:17 |
| perrito666 | looool | 15:17 |
| * balloons hears natefinch in a cool annoucer's voice | 15:17 | |
| perrito666 | I read him with the bsg font | 15:17 |
| sinzui | katco: Since the azure provider is broken by bug 1612836 we cannot see if the windows deployment is still broken | 15:17 |
| mup | Bug #1612836: Cannot bring up hosted model machines in azure <azure-provider> <ci> <deploy> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1612836> | 15:17 |
| perrito666 | sinzui: katco left the channel | 15:18 |
| * perrito666 pastes the last 100 lines to show sinzui | 15:18 | |
| natefinch | lol | 15:18 |
| natefinch | she must have hit the wrong thing in emacs | 15:18 |
| perrito666 | it all started with a /names so she most likely hit the combination for paste instead of enter | 15:19 |
| * redir has flashback and blinks | 15:20 | |
| mgz | it wasn't even a flood kick... | 15:22 |
| perrito666 | katco: are you ok? | 15:22 |
| katco | wow i have no clue what happened | 15:22 |
| perrito666 | need an exsorcism? | 15:22 |
| perrito666 | lol, I have no clue how to write that in english I just noticed | 15:23 |
| katco | i don't even know what it ended up posting to the channel... did i spam everyone or something? | 15:23 |
| rick_h_ | katco: :) a bit | 15:23 |
| perrito666 | katco: it was a nice recap of friday | 15:23 |
| katco | ... | 15:23 |
| rick_h_ | katco: we had a rerun episode of #juju-dev, not a bad one though. | 15:23 |
| katco | did it send the buffer from friday? | 15:23 |
| perrito666 | katco: you did | 15:24 |
| katco | weird... | 15:24 |
| perrito666 | katco: where you trying to send the buffer from a different day? | 15:24 |
| katco | i was trying to ask mgz and sinzui a question lol... let me try to paste this error message again | 15:24 |
| * perrito666 cringes | 15:24 | |
| katco | mgz: sinzui: have you seen this error before? value *errors.Err = &errors.Err{message:"", cause:(*errors.Err)(0xc82395c5f0), previous:(*errors.Err)(0xc82395c640), file:"github.com/juju/juju/cmd/juju/application/deploy.go", line:691} ("the provided bundle has the following errors:\ncharm path in application \"dummy\" does not exist: dummy") | 15:25 |
| katco | (sorry for the weird spam earlier all) | 15:25 |
| katco | mgz: sinzui: trying to figure out if this is a spurious error, i.e. a timing issue in CI where the dummy path doesn't exist before the bundle is deployed, or...? | 15:26 |
| mgz | katco: new to me. looks like more local charm/deploy syntax confusion? | 15:26 |
| sinzui | katco: no. do you have juju-ci-tools/repository checked out and do you gave JUJU_REPOSITORY seto the path so that the path to the charm is correct | 15:27 |
| katco | mgz: hm, ok. i didn't get this locally when running through the test suite. i'll try the ci suite next | 15:27 |
| dimitern | rick_h_: whew.. bug 1603473 updated | 15:27 |
| mup | Bug #1603473: Relation fails as units/machines are on different subnet on a multi NIC setup, juju 2.0 beta11 <11> <2.0> <beta> <juju> <juju-core:Incomplete by dimitern> <https://launchpad.net/bugs/1603473> | 15:27 |
| katco | sinzui: this is from an official ci run, not me running ci locally | 15:27 |
| rick_h_ | dimitern: ty, let's see how that goes | 15:28 |
| dimitern | rick_h_: can you have a look and perhaps comment, if needed? | 15:28 |
| rick_h_ | dimitern: /me goes to look | 15:28 |
| sinzui | katco: good, my thoughts remain the same. | 15:28 |
| mgz | katco: github-merge-juju/8788 ? looks like a real issue with your branch I think | 15:28 |
| dimitern | rick_h_: cheers! | 15:28 |
| natefinch | mgz: thanks for the help with the logging... that helped get me past my problem (the code was expecting to be pointed one directory deeper than I realized.... if only we had documentation for this sort of thing. | 15:29 |
| mgz | natefinch: ace, glad it helped | 15:29 |
| katco | mgz: i was looking at 8785, but i'm sure that one is the same | 15:29 |
| mup | Bug #1613476 changed: juju cli commands should be logged by juju <oil> <oil-2.0> <juju-core:Invalid> <https://launchpad.net/bugs/1613476> | 15:29 |
| natefinch | mgz: it's not *working* but at least I get better output and fixed that one problem | 15:32 |
| admcleod | babbageclunk: hello | 15:33 |
| babbageclunk | admcleod: hey! | 15:33 |
| * natefinch lunches | 15:33 | |
| admcleod | babbageclunk: hows it going? | 15:33 |
| === natefinch is now known as natefinch-afk | ||
| babbageclunk | admcleod: yeah, good thanks - how are you? Still in Spain? | 15:33 |
| admcleod | babbageclunk: not bad, yeah im still in spain but im in barcelona now... | 15:34 |
| * rick_h_ grabs lunchables | 15:35 | |
| admcleod | babbageclunk: i think i said i was going to live in valencia. im not sure now :) | 15:36 |
| babbageclunk | admcleod: who can be sure in this mad world? | 15:37 |
| beisner | hi all. ? re: manual provider. by default, lxc units get placed behind nat on the bridge, meaning lxc units are in a bit of a bubble in terms of directly communicating with lxc units on another manual unit. is there a juju-ism to specify transparent bridge? | 15:37 |
| admcleod | babbageclunk: i just dont know. which is a great segue into my question about juju lxc networking with manual provider | 15:37 |
| admcleod | babbageclunk: which is also beisers question | 15:37 |
| * beisner yields the floor :) | 15:37 | |
| katco | mgz: sinzui: thanks, i can reproduce locally | 15:40 |
| admcleod | beisner: was it something i said? | 15:45 |
| beisner | admcleod, ha! | 15:46 |
| rick_h_ | admcleod: beisner i'm not aware of one atm. file a bug and i'll see if the network experts have any thoughts. it might requure some juju-run-fu | 15:48 |
| rick_h_ | admcleod: beisner more complicated setups require the provider worm (such as maas has gotten) so the manual provider hasn't gotten complex network love | 15:50 |
| rick_h_ | admcleod: beisner there's a todo for using the fan on public clouds for container coms, worth adding manual to that list it seems. | 15:51 |
| admcleod | rick_h_: ah right, thanks | 15:54 |
| beisner | rick_h_, thanks, we'll push on with a few ideas and raise a bug if it looks like something outside the expected behavior. | 15:55 |
| frobware | voidspace: ping - do you still have problems at the commissioning stage with my scripts? | 16:03 |
| frobware | so it turns out my first snap is never going to work... :( | 16:21 |
| * frobware one square to back... | 16:22 | |
| mup | Bug #1613782 opened: windows cannot bootstrap trusty <bootstrap> <ci> <jujuqa> <regression> <windows> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613782> | 16:26 |
| * frobware has exactly this problem, but for accessing .maascli.db: https://www.mail-archive.com/snapcraft@lists.ubuntu.com/msg00345.html | 16:26 | |
| === natefinch-afk is now known as natefinch | ||
| natefinch | anyone know what this means? sinzui, mgz: 2016-08-16 15:25:49 DEBUG juju.environs.simplestreams simplestreams.go:454 skipping index "https://s3.amazonaws.com/24b99da448314945835933a0c8edffb3/tools/streams/v1/index2.json" because of missing information: "content-download" data not found | 16:56 |
| mup | Bug #1613804 opened: mongod sigabrt <intermittent-failure> <test-failure> <windows> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613804> | 16:56 |
| mgz | abentley: ^any ideas on natefinch's message? | 17:04 |
| natefinch | I see "datatype": "content-download" under index": { "com.ubuntu.juju:released:tools": { | 17:06 |
| abentley | natefinch: I can tell you that LXD and MAAS use "content-download" and AWS uses "image-id". | 17:06 |
| natefinch | abentley: what does azure use? Because that's where I'm trying to deploy | 17:07 |
| natefinch | note this is streams for tools, not images | 17:07 |
| abentley | natefinch: Oh, sorry. For tools, everything uses content-download. | 17:08 |
| abentley | natefinch: I see that this index has only the released streams. Are you testing a beta? | 17:11 |
| natefinch | abentley: I'm testing my own code | 17:11 |
| sinzui | natefinch: abentley is suggesting that you need to decale the agents to be devel | 17:12 |
| natefinch | man, I really wish I could just juju upload-tools win2012hvr=/home/nate/bin/jujud.exe | 17:13 |
| abentley | natefinch: What sinzui said. You'll need devel streams or to set agent-stream=released for this to work. | 17:13 |
| sinzui | natefinch: I think the call to juju metdata generate-agents needs an arg to make agent stanzas | 17:13 |
| * sinzui though juju refused to honour agent-stream=released when the version has letters in it | 17:13 | |
| natefinch | lol | 17:14 |
| * natefinch is gonna have to document the crap outta this | 17:17 | |
| sinzui | natefinch: I think the command is | 17:17 |
| sinzui | uju metadata generate-tools -d <workingdir> --stream | 17:17 |
| sinzui | natefinch: and we can detect a letter in the version to switch from released to devel. I can fix that now | 17:17 |
| mup | Bug #1613823 opened: Google App Engine IP is ephemeral by default <juju-core:New> <https://launchpad.net/bugs/1613823> | 17:17 |
| mup | Bug #1613824 opened: cmdSubnetSuite teardown fails: unexpected message <ci> <intermittent-failure> <jujuqa> <unit-tests> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613824> | 17:17 |
| natefinch | sinzui: I was just using the streams-from-local script | 17:18 |
| sinzui | natefinch: yeah, that is the script I ma going to change | 17:18 |
| natefinch | sinzui: ok. yes, it would be nice if what it output worked by default with the ci scripts that it is right next to. | 17:18 |
| sinzui | natefinch: the script is checking for alpha or beta in the version and setting devel. What version is yoru juju? | 17:24 |
| natefinch | sinzui: beta.. whatever master is | 17:24 |
| sinzui | natefinch: in your stream directory, do you have a sir named "tools/evel" | 17:25 |
| sinzui | natefinch: in your stream directory, do you have a sir named "tools/devel" | 17:26 |
| natefinch | sinzui: no, just released. I'm currently rerunning with agent-stream=released | 17:27 |
| sinzui | natefinch: is your system juju 1.25.6? | 17:28 |
| sinzui | natefinch: well that wouldn't matter becuase the script runs jujud --version | 17:28 |
| sinzui | natefinch: found the problem. | 17:29 |
| mup | Bug #1613829 opened: TargetDiskBlobAlreadyExists on deploy (Azure) <azure-provider> <ci> <deploy> <intermittent-failure> <jujuqa> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613829> | 17:32 |
| mgz | rick_h_: got a slot for a pre-imp call some point in the next few hours? | 17:34 |
| rick_h_ | mgz: sure thing, getting off the phone shortly | 17:35 |
| rick_h_ | mgz: free when you are | 17:35 |
| dimitern | anybody up for a short review ? http://reviews.vapour.ws/r/5449/ - fixes bug 1612624 | 17:41 |
| mup | Bug #1612624: Bootstrap fail on MAAS if ipv6 is disabled <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1612624> | 17:41 |
| mup | Bug #1613829 changed: TargetDiskBlobAlreadyExists on deploy (Azure) <azure-provider> <ci> <deploy> <intermittent-failure> <jujuqa> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613829> | 17:41 |
| * dimitern eod-s | 17:42 | |
| natefinch | sinzui: does --agent-stream work? It seems like it's being ignored: http://pastebin.ubuntu.com/23062301/ | 17:45 |
| sinzui | natefinch: that is what I muttered about above. wallyworld told me he added a rule that a devel version would never use released streams. in CI tests, we create devel streams | 17:46 |
| natefinch | sinzui: I guess I can just edit my tools to s/released/devel | 17:46 |
| mup | Bug #1613829 opened: TargetDiskBlobAlreadyExists on deploy (Azure) <azure-provider> <ci> <deploy> <intermittent-failure> <jujuqa> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613829> | 17:47 |
| sinzui | natefinch: you. can. my change to parse the "juju version" does pass the riight args, but juju then flips out because it seems to alway require a released stream too | 17:48 |
| === redelmann_ is now known as redelmann | ||
| sinzui | natefinch: generate-tools refuse to make devel streams :( you only need to change "released" ot "devel" in index2.json to move forward. I am going to explore this approach for the script | 17:58 |
| natefinch | sinzui: this is like some greek tragedy | 17:58 |
| natefinch | sinzui: I can edit easily enough, will retry once I fix it in s3 | 17:59 |
| natefinch | gah, this stuff is a wall of text | 18:08 |
| natefinch | http://pastebin.com/raw/RAYY12i8 | 18:10 |
| mup | Bug #1613838 opened: TestBootstrap on arm/ppc64el/s390 cannot build agent binary <arm64> <bootstrap> <ci> <jujuqa> <ppc64el> <regression> <s390x> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613838> | 18:18 |
| mup | Bug #1613838 changed: TestBootstrap on arm/ppc64el/s390 cannot build agent binary <arm64> <bootstrap> <ci> <jujuqa> <ppc64el> <regression> <s390x> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613838> | 18:21 |
| natefinch | sinzui: do you understand what's wrong here? ^ I don't know what the streams logging is supposed to look like, so it's hard for me to understand what's wrong | 18:22 |
| natefinch | it looks like one of the products is com.ubuntu.juju:win2012r2:amd64 and one of the candidates is the same | 18:23 |
| natefinch | unfortunately someone printed out with %v not %#v so it's hard to map the textual output to the fields in the struct that it's printing | 18:24 |
| sinzui | natefinch: streams/v1/com.ubuntu.juju-devel-tools.json is listing agents we didn't even include in streams. this is crazy | 18:25 |
| natefinch | what's weird is that this log line is after the code has supposedly stripped out all non-matching candidates, yet clearly there are still non-matching ones, like com.ubuntu.juju:12.04:amd64 | 18:26 |
| natefinch | and in fact, the next line just chooses the first matching one, which means it is choosing com.ubuntu.juju:12.04:amd64 | 18:27 |
| natefinch | not that it tells us that... | 18:27 |
| natefinch | in the logs | 18:27 |
| mup | Bug #1613838 opened: TestBootstrap on arm/ppc64el/s390 cannot build agent binary <arm64> <bootstrap> <ci> <jujuqa> <ppc64el> <regression> <s390x> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1613838> | 18:33 |
| mup | Bug #1613839 opened: bundle deployment does not accept "1.0" as valid float <juju-core:New> <https://launchpad.net/bugs/1613839> | 18:33 |
| sinzui | natefinch: generate-tools is completely busted. It never includes the agents we asked to be added. this proabbly because 1.x is not allowed to know about 2.x. I amd going to switch system jujus and see if 2.x can make streams for 2.x | 18:33 |
| natefinch | sinzui: k | 18:34 |
| bleepbloop | I did a reboot of my juju state nodes and when they restarted I lost the ability to run `juju --debug status` and now get an error `health ping failed: connection is shut down` and in my `juju debug-log` I am getting ` cannot publish API server addresses: cannot set API addresses: state changing too quickly; try again soon`. I installed the version that came | 18:36 |
| bleepbloop | with xenial which is 2.0 beta12, what is weird is everything else seems to still be working, it is just freaking out when juju status is run | 18:36 |
| bleepbloop | Hopefully this is the right place to ask since the issue is with the beta version | 18:36 |
| mup | Bug #1613839 changed: bundle deployment does not accept "1.0" as valid float <juju-core:New> <https://launchpad.net/bugs/1613839> | 18:39 |
| natefinch | bleepbloop: we encountered something like this.. I think it's been fixed since that beta | 18:44 |
| natefinch | bleepbloop: hmm.. the one I'm thinking of was fixed before beta 12 | 18:47 |
| mup | Bug #1613839 opened: bundle deployment does not accept "1.0" as valid float <juju-core:New> <https://launchpad.net/bugs/1613839> | 18:48 |
| bleepbloop | @natefinch Hmm okay, I'm also seeing a `pinger failed: E11000 duplicate key error collection: presence.presence.pings`, could that be related to the `health ping failed` error? | 18:51 |
| meetingology | bleepbloop: Error: "natefinch" is not a valid command. | 18:51 |
| bleepbloop | Oops meant natefinch:, been using slack too much :P | 18:51 |
| natefinch | haha | 18:51 |
| natefinch | bleepbloop: I think it's very similar to the other bug that we fixed, maybe this is another instance of it nearby in the code. It's an error from juju's mongo driver. Basically, mongo is changing stuff out from under us because ¯\_(ツ)_/¯ it's mongo | 18:53 |
| mup | Bug #1613842 opened: [Feature] Juju Resources should also support fingerprint checking <juju-core:New> <https://launchpad.net/bugs/1613842> | 18:57 |
| natefinch | bleepbloop: the pinger thing I'm guessing is a different problem... but not 100% sure. | 18:57 |
| bleepbloop | Hmm okay, is there a good way to workaround it for now? I just tried to upgrade to beta15 to see if that would help and ended up with a "ERROR unknown object type "ModelConfig" (not implemented)" so that seems to not be the way to go :/ | 18:58 |
| natefinch | sinzui: we don't officially support upgrading from beta to beta, do we? | 18:59 |
| sinzui | natefinch: no we don't | 19:00 |
| natefinch | bleepbloop: I understand this is the version that comes with Xenial... it's unfortunately still in beta due to, well, a bunch of reasons. | 19:00 |
| natefinch | bleepbloop: rebooting may help. It generally only happens then the machine is under load | 19:03 |
| natefinch | bleepbloop: it may help to simply not reboot and leave it alone for a while, too. Upgrade sometimes can work and sometimes doesn't... seems like you're hitting one of the "it doesn't" | 19:03 |
| natefinch | bleepbloop: I filed a bug for it - https://bugs.launchpad.net/juju-core/+bug/1613855 It'll get adressed soon, but that won't help fix your current environment, unfortunately. | 19:08 |
| mup | Bug #1613855: SetAPIHostPorts runs afoul of "state changing too quickly" <juju-core:New> <https://launchpad.net/bugs/1613855> | 19:08 |
| bleepbloop | natefinch: Okay, no problem I rolled back from the ppa, it seems to have not made things any worse so thats good at least, would it help if I included the full logs for the error? | 19:14 |
| mup | Bug #1613855 opened: SetAPIHostPorts runs afoul of "state changing too quickly" <juju-core:New> <https://launchpad.net/bugs/1613855> | 19:18 |
| bleepbloop | Also just found some more fun `panic: runtime error: index out of range` seems to be happening on all of the nodes (servers are running in HA) | 19:19 |
| natefinch | bleepbloop: ew | 19:20 |
| natefinch | bleepbloop: you may be in a bad state if you tried to upgrade and it failed halfway through. Still, I wouldn't expect to see a panic like that. | 19:22 |
| bleepbloop | natefinch: I don't think the panics are due to my upgrade attempt, the panics all happened 2-3 hours ago where all I'd done is rebooted the machines | 19:23 |
| natefinch | ahh hmm | 19:23 |
| natefinch | can you pastebin me one of them? | 19:23 |
| bleepbloop | sure no problem, one second | 19:25 |
| bleepbloop | natefinch: http://pastebin.com/UKeD4msg it happens 3 times in the included log | 19:36 |
| bleepbloop | natefinch: if you search for "panic: runtime error" you'll find it | 19:37 |
| mup | Bug #1613858 opened: generate-tools ignores 2.x agents and creates bad path <jujuqa> <metadata> <regression> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1613858> | 19:42 |
| natefinch | bleepbloop: looks like you stumbled on another bug | 19:44 |
| natefinch | bleepbloop: yet another notch on your belt - https://bugs.launchpad.net/juju-core/+bug/1613866 Sorry you're running into these problems. Not really sure why we haven't seen this one more often... maybe something special in the timing in your system. | 19:51 |
| mup | Bug #1613866: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 19:51 |
| mup | Bug #1613864 opened: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864> | 19:51 |
| mup | Bug #1613866 opened: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 19:51 |
| natefinch | rick_h_: this whole streams debacle is just crazy | 19:53 |
| mup | Bug #1613864 changed: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864> | 19:54 |
| mup | Bug #1613866 changed: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 19:54 |
| natefinch | rick_h_: it's very obvious that we need much better UX around setting custom streams URLs if we actually expect anyone to ever do it, not to mention much better facilities for debugging problems with it. And that's not to mention the fact that we have a showstopped bug with it. | 19:55 |
| mup | Bug #1613864 opened: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864> | 19:57 |
| mup | Bug #1613866 opened: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 19:57 |
| mup | Bug #1613864 changed: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864> | 20:03 |
| mup | Bug #1613866 changed: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 20:03 |
| natefinch | thumper: Let me know what you think of my assessment of this bug: https://launchpad.net/bugs/1613855 | 20:04 |
| mup | Bug #1613855: SetAPIHostPorts runs afoul of "state changing too quickly" <juju-core:New> <https://launchpad.net/bugs/1613855> | 20:04 |
| natefinch | (sorry to jump on you :) | 20:04 |
| thumper | morning | 20:04 |
| natefinch | morning :D | 20:05 |
| thumper | natefinch: yep, agree with your analysis | 20:05 |
| natefinch | yay | 20:05 |
| thumper | needs to be fixed asap | 20:05 |
| thumper | natefinch: I've marked it critical | 20:07 |
| rick_h_ | natefinch: don't disagree. It's why wallyworld's spent time and things trying to find ways to work w/o streams | 20:08 |
| mup | Bug #1613864 opened: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864> | 20:12 |
| mup | Bug #1613866 opened: server panic during juju status if no status history for a unit <juju-core:New> <https://launchpad.net/bugs/1613866> | 20:12 |
| * natefinch writes his own streams data by hand | 20:22 | |
| bleepbloop | So as a last ditch effort and to curb my own curiousity, are there more up to date instructions with exactly how to connect to the mongodb database directly? | 20:24 |
| rick_h_ | natefinch: what happened with kicking off a CI run, pausing it, and investigating that? I know you were trying to do that the other day and didn't hear why that fell over? | 20:24 |
| rick_h_ | bleepbloop: hmm, someone had a tool for helping with that. katco? | 20:24 |
| katco | rick_h_: a tool for pausing ci? | 20:25 |
| natefinch | rick_h_: there was some problem where the new code was not available yet. but maybe that's no longer the case. sinzui? | 20:25 |
| rick_h_ | katco: no, for connecting to mongodb | 20:25 |
| rick_h_ | katco: maybe I was wrong it wasn't you. /me is trying to search email for it | 20:25 |
| katco | rick_h_: oh, right... i sent a script out to the email list | 20:25 |
| katco | natefinch: rick_h_: check juju-dev | 20:25 |
| rick_h_ | katco: right, that's what I was thinking of. bleepbloop is asking about that and maybe the list email would be a useful start for bleepbloop | 20:25 |
| katco | bleepbloop: ok, one sec | 20:26 |
| rick_h_ | katco: july 27th, found the email | 20:26 |
| katco | bleepbloop: https://lists.ubuntu.com/archives/juju-dev/2016-July/005772.html | 20:26 |
| katco | bleepbloop: give that a try. fairly easy to understand | 20:26 |
| rick_h_ | ty katco | 20:27 |
| katco | rick_h_: hth | 20:27 |
| bleepbloop | Thanks! | 20:28 |
| natefinch | sinzui: is CI able to run that windows test I've been trying to run, and if so, could we run it with --keep-env so I can investigate it? | 20:29 |
| === mup_ is now known as mup | ||
| cmars | are there docs, on how to test with clocks ? | 20:41 |
| katco | what's the testing suite that allows me to create temporary files/directories? | 20:42 |
| natefinch | katco: c.Mkdir() | 20:42 |
| natefinch | katco: not a suite | 20:42 |
| katco | natefinch: ta | 20:43 |
| === natefinch is now known as natefinch-afk | ||
| mup | Bug #1587644 changed: jujud and mongo cpu/ram usage spike <canonical-bootstack> <canonical-is> <juju-core:Fix Released> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1587644> | 21:04 |
| mup | Bug #1612653 changed: lxd fails in beta15 when installing via snap <juju-core:Triaged> <https://launchpad.net/bugs/1612653> | 21:04 |
| mup | Bug #1613882 opened: stateSuite.SetUpTest mongo is unreachable <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1613882> | 21:04 |
| bleepbloop | Thank you all for your help! Last question, how well does 1.25 work on xenial? Are there any compatibility issues or should it be fully compatible? | 21:15 |
| perrito666 | bleepbloop: I don't think 1.25 works on xenial | 21:17 |
| rick_h_ | natefinch-afk: this has your name on it, can you update/create a card/etc please? https://bugs.launchpad.net/juju-core/+bug/1552274 | 21:18 |
| mup | Bug #1552274: juju list-credentials inconsistencies between format output <2.0-count> <bitesize> <conjure> <juju-release-support> <rc1> <usability> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1552274> | 21:18 |
| bleepbloop | I see there are xenial packages for 1.25, is there anything specific that doesn't work? | 21:25 |
| perrito666 | bleepbloop: it was an educated guess, I am not sure the right mongo package is built for xenial | 21:30 |
| perrito666 | but then again, I might be wrong | 21:30 |
| perrito666 | rick_h_: do you know? | 21:30 |
| rick_h_ | bleepbloop: perrito666 nothing that I'm aware of? I mean it works? | 21:33 |
| perrito666 | rick_h_: it means it works | 21:33 |
| mup | Bug #1613888 opened: Cannot destroy application (contention) shortly after unblocking it <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1613888> | 21:49 |
| * rick_h_ runs for the night | 21:59 | |
| * redir hopes rick_h_ catches the night. | 22:26 | |
| mup | Bug #1613892 opened: juju "show" flags are inconsistent <juju-core:New> <https://launchpad.net/bugs/1613892> | 22:28 |
| perrito666 | Will be 5 late to standup | 23:09 |
| axw | wallyworld: this needs another review if you would later: http://reviews.vapour.ws/r/5447/ | 23:36 |
| perrito666 | wallyworld: you just dropped | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!