| babbageclunk | externalreality: what thumper said - if you call the API with the right creds (tag and password), you shouldn't get permission denied, no matter whether the agent's been removed from init. | 02:17 |
|---|---|---|
| externalreality | babbageclunk, thumper I am calling the endpoint once (no problem), then I call it again after killing the init system service, after that I get permission denied errors. | 02:19 |
| thumper | I don't understand how you are killing it and calling the endpoint at the same time | 02:20 |
| thumper | whom are you killing? | 02:20 |
| babbageclunk | externalreality: you're definitely killing the unit agent and not the machine agent? | 02:20 |
| externalreality | babbageclunk: I am killing the unit agent's service directly | 02:20 |
| externalreality | Then I am trying to update a record based by calling a service with its tag | 02:21 |
| babbageclunk | I'm not clear what you mean by "calling a service with it's tag". | 02:22 |
| babbageclunk | What facade/method are you calling? How are you connecting? | 02:22 |
| babbageclunk | externalreality: (not trying to be pedantic, just want to understand what you're seeing) | 02:24 |
| externalreality | babbageclunk, no worries, gathering logs to make things clear | 02:24 |
| externalreality | babbageclunk, endpoint calls `canAccess(tag)` | 02:25 |
| externalreality | babbageclunk, in the case before I call the service all is fine | 02:26 |
| externalreality | babbageclunk, after killing the service - I get: | 02:26 |
| externalreality | babbageclunk, `juju.worker.dependency "upgrade-series" manifold worker stopped: Access permission denied for string unit-ubuntu-0` | 02:26 |
| externalreality | Indicating the I no longer can call `canAccess(tag)` where the tag is `unit-ubuntu-0` the tag of the service for whom I have killed their systemd/upstart service | 02:27 |
| externalreality | Admittedly, I find it hard to follow the Auth code. Which is why I just thought I'd ask | 02:27 |
| externalreality | I'll do more testing tomorrow to ensure that I am seein what I think I'm seeing before digging through Auth code. | 02:28 |
| babbageclunk | I'm fairly sure canAccess isn't looking at services. I can help you track through the auth code if you want? | 02:28 |
| externalreality | babbageclunk, I'll take a look in the morning. I am 5:28 minutes past EOD. | 02:29 |
| babbageclunk | externalreality: Ok, ping me tomorrow if you want help then! (Where are you at the mmoment?) | 02:29 |
| externalreality | babbageclunk, ack | 02:29 |
| externalreality | babbageclunk, I am EST -1 | 02:31 |
| babbageclunk | Oh right - so pretty late for you then! | 02:32 |
| rick_h_ | kelvinliu_: ping, just a heads up taht if those changes work for the snap we need to update https://git.launchpad.net/~juju-qa-bot/+git/juju-edge-snap/tree/snap/snapcraft.yaml#n17 and the other git branches there as well. | 02:32 |
| rick_h_ | kelvinliu_: veebers might be able to get you the full links. I don't have my phone on me to 2fa into LP atm | 02:33 |
| veebers | rick_h_: I'm on it :-) Just pulled myself to make sure I could | 02:34 |
| rick_h_ | veebers: gotcha cool. you all rock! :) | 02:35 |
| veebers | kelvinliu_: so the sep packaging branch uses source-type, as it's source it pointing to a repo. This may trip us up | 02:35 |
| kelvinliu_ | rick_h_, yeah, i will need veebers help me understand how everything is setup. thx | 02:38 |
| veebers | kelvinliu_: remind me the command to cleanup after dep? | 03:18 |
| kelvinliu_ | veebers, clean up what? | 03:18 |
| veebers | kelvinliu_: ah sorry, i.e. when I'm switching between 2.4 and develop i need to remove vendor I think (I'm pretty sure this is covered in the discourse post and I should just RTM) | 03:19 |
| veebers | ah right, just remove it :-) | 03:19 |
| kelvinliu_ | ah make godeps | 03:20 |
| veebers | kelvinliu_: if you remove vendor from your working dir and try a snap build it'll fail | 03:24 |
| kelvinliu_ | veebers, develop branch? | 03:24 |
| veebers | I'm not 100% sure why yet, but snapcraft will do a go get, then some sort of check/build before it's finished that and does the prepare (or now override-build) | 03:25 |
| veebers | kelvinliu_: yes | 03:25 |
| veebers | kelvinliu_: it only worked because we had that dir pre-populated and use a source of ./ | 03:25 |
| veebers | wallyworld, thumper FYI the win unit test job is running again. It has a build failure, seems to be due the the length of a filename or extension. That rings a bell from previously | 03:26 |
| wallyworld | ty | 03:26 |
| thumper | hmm... | 03:26 |
| thumper | is it in the vendor directory? | 03:26 |
| veebers | thumper: http://10.125.0.203:8080/job/RunUnittests-win2012/666/console | 03:27 |
| thumper | ooohh... 666 | 03:27 |
| veebers | thumper: hah yeah ^_^ Aye, it looks like it is | 03:27 |
| veebers | kelvinliu_: I've got a 'going to fail' run with --debug so hopefully will get some more info | 03:28 |
| kelvinliu_ | veebers, yes, we need to inject `make dep` after git clone immediately | 03:29 |
| thumper | wallyworld: this switches the default https://github.com/juju/juju/pull/9061 | 03:29 |
| thumper | wallyworld: I'll add another later to deal with not starting the pingers | 03:30 |
| veebers | kelvinliu_: aye, indeed. Just digging in to try figure that out | 03:30 |
| kelvinliu_ | veebers, either write dep plugin or ensure dep before plugin | 03:30 |
| veebers | am I being blind or is there no search for https://docs.snapcraft.io/build-snaps/ | 03:31 |
| veebers | kelvinliu_: much like the override-build, there might be an override-pull | 03:34 |
| veebers | FYI https://docs.snapcraft.io/build-snaps/scriptlets looks like it's possible (read the 1st paragraph so far) | 03:35 |
| * veebers tries something out | 03:36 | |
| veebers | kelvinliu_, wallyworld: I'm failing to see a way around this. I tried override-pull, but the pull does a go get and tries to do some build (as it chokes on the deps), if I override to not do the pull then we don't have the source there to do anything with. | 03:51 |
| wallyworld | veebers: i'm not up on the current core issue | 03:52 |
| veebers | I also tried changing back to the godeps plugin and doing an override-pull: snapcraftctl pull || true; make dep. But the pull still fails | 03:52 |
| kelvinliu_ | veebers, im looking to write dep plugin | 03:53 |
| veebers | wallyworld: essentially we fail at the pull stage, as the goplugin and godeps plugin does a go get ... + something else that fails so we have no chance to inject the make based dep handling | 03:53 |
| veebers | kelvinliu_: ack, I think that's the only way forward | 03:53 |
| veebers | kelvinliu_: I imagine it'll be a big ol' cribbing of the godep one | 03:53 |
| veebers | hah you could potentially subclass the godep one and change pull(). | 03:54 |
| wallyworld | hmm, sad that it's this hard | 03:54 |
| veebers | I see babbageclunk has a flying spaghetti monster WIP he's working on^_^ | 03:56 |
| veebers | #dadkjokes | 03:56 |
| babbageclunk | ha | 03:56 |
| wallyworld | thumper: lgtm | 03:58 |
| veebers | thumper: if you have a moment could you sanity eyeball https://github.com/CanonicalLtd/juju-qa-jenkins/pull/71 please? It's adding a caas image build step after a edge snap build trigger | 04:04 |
| veebers | then I'll merge that and deploy a handful of jobs that have changed recently | 04:04 |
| kelvinliu_ | veebers, im looking to see if we can put the dep.py to ./snap/plugins/ | 04:11 |
| veebers | kelvinliu_: intersting | 04:12 |
| veebers | kelvinliu_: I take it you saw: https://docs.snapcraft.io/build-snaps/plugins | 04:12 |
| veebers | (it outlines what you're trying to do I think) | 04:13 |
| kelvinliu_ | veebers, yes, | 04:14 |
| veebers | sweet ^_^ | 04:14 |
| vinodhini | wallyworld: I am waiting for ur approval have pushed commits in both. | 05:57 |
| wallyworld | ok, will look | 05:57 |
| wallyworld | best to ping me when you need a re-review | 05:58 |
| wallyworld | vinodhini: looks like there's still confusion about errors. let me know if you need a HO to clarify | 06:18 |
| vinodhini | wallyworld: are u around | 08:14 |
| wallyworld | i am | 08:14 |
| vinodhini | I reverted whatever u have mentioned in the review | 08:15 |
| vinodhini | pushed the commit | 08:15 |
| vinodhini | I have made the previous chnages wheever the cause wasnt captured i changed all to fmt.Errorf that was my fault. | 08:16 |
| vinodhini | i reverted back all. | 08:17 |
| wallyworld | ok, looking | 08:17 |
| wallyworld | vinodhini: almost there, main thing is a missing test still | 08:28 |
| === alephnull_ is now known as alephnull | ||
| wallyworld | the reason for wanting the test is that we have shown that auth will fail if there's a mistake in the code in that area | 08:30 |
| wallyworld | we need to also guard against future code breakages | 08:30 |
| vinodhini | wallyworld | 08:34 |
| vinodhini | I was going thru ur comments | 08:34 |
| === salmankhan1 is now known as salmankhan | ||
| parlos | Howdy; i messed up. I've killed the host running the juju controller. :( Its not a big problem, its a testing environment. But; what would be the suitable path to start a new controller on the same cloud. | 09:21 |
| parlos | would destroy-controller (or kill-controller), and the just bootstrap the new one be suitable, or would it potentially have some side effects on the running models? | 09:23 |
| parlos | My guess, it would not, as the device running the controller is dead, hence the destroy command would have no way to talk to the models..Which also were hosted on that device.. | 09:24 |
| magicaltrout | https://github.com/juju/layer-index/pull/39 anyone around to give me a merge? | 09:38 |
| vinodhini | wallyworld: are u around | 09:39 |
| vinodhini | I have left comments for the test u have requested. | 09:40 |
| vinodhini | Its already there without TenantName and TenantID | 09:40 |
| vinodhini | wallyworld I have added the same comment in PR. Please let me know your input. | 09:42 |
| wallyworld | parlos: you can juju unregister the existing controller (to clear it from the local juju cache). if the controller machine also hosted the model worker machines via containers or whatever, then they are all gone anyway and you can start again | 09:46 |
| wallyworld | vinodhini: there's still no test | 09:49 |
| wallyworld | for the v3auth scope | 09:50 |
| parlos | wallyworld; thanks. The controller was just controller, the models/applications are fully functioning. But, I will redeploy them as to have them under control. I'll also start doing controller backups.. | 09:52 |
| wallyworld | parlos: if you want to redeploy, you should also manually kill the machines running the workloads | 09:53 |
| wallyworld | juju unregister is the command you want to clear the controller away from juju's cache | 09:53 |
| parlos | wallyworld; eventually; but one of the workloads is an openstack deployment, and its in use....( for another couple of weeks). | 09:54 |
| wallyworld | ah ok | 09:54 |
| wallyworld | if you had a juju backup you could have recreated the controller | 09:55 |
| parlos | I'm reading on the backup, does this only apply to a specific model? | 09:56 |
| magicaltrout | thanks | 09:56 |
| wallyworld | magicaltrout: done | 09:57 |
| wallyworld | parlos: if backs up the entire controller database; all models | 09:57 |
| parlos | Ok, and if the controller has gone to /dev/null, then you need the downloaded backup file. Correct? This will basically bootstrap a new controller when the information in the backupfile.. | 10:01 |
| wallyworld | vinodhini: the test that's there isn't testing what I'm asking for. the code that was changed in the PR was to change how auth.Auth.Scope is set according to what cred values we have. I can't see a test for that | 10:43 |
| wallyworld | the tests you are referring to appear to be testing other aspects | 10:43 |
| wallyworld | we specifically need to ensure that what is passed to the identity endpoint is what we need | 10:44 |
| wallyworld | it's very much a whitebox test. we need it because if the code is wrong, auth will fail | 10:45 |
| npochet | I just had an issue with SCP (https://github.com/juju/python-libjuju/issues/259) and raised a PR fixing it: https://github.com/juju/python-libjuju/pull/260 | 11:48 |
| npochet | Thanks beforehand for the review! | 11:49 |
| jamespage | tinwood, cory_fu: what's the reactive way of handling the 'stop' hook | 12:38 |
| jamespage | ? | 12:38 |
| tinwood | jamespage, good question. Probably @hook for the moment, unless @hook has been removed now | 13:10 |
| * tinwood goes off to check | 13:10 | |
| cory_fu | tinwood: It hasn't been removed. | 13:11 |
| cory_fu | jamespage: Yeah, I think @hook, I guess | 13:11 |
| tinwood | thanks cory_fu | 13:11 |
| jamespage | ok good | 13:11 |
| jamespage | I was not wrong then - someone asked me | 13:11 |
| cory_fu | jamespage: Ideally I'd like to add a framework-driven flag for it, just for consistency, but stop is always going to be a bit of a special case | 13:27 |
| stickupkid | rick_h_: with this mutliple credentials, so this issue is that when using lxc to auto detect credentials, localhost breaks, as there are always multiple credentials - i wonder if we just never return locally discovered credentials? | 15:35 |
| rick_h_ | stickupkid: processing ... | 15:35 |
| stickupkid | i.e. we can discover the remote, but you have to add the credential manually? | 15:36 |
| stickupkid | so it will show in "add-clouds", but you can't bootstrap to it | 15:36 |
| rick_h_ | stickupkid: k works for now to move forward | 15:36 |
| stickupkid | although you're likely to get a cryptic message about localhost not the right credentials for nuc5 | 15:37 |
| rick_h_ | and puts the right priority on what's easier vs more akward | 15:37 |
| rick_h_ | stickupkid: ? | 15:37 |
| stickupkid | i think it's both akward | 15:38 |
| stickupkid | maybe we should back out autodectection of local lxc configurations | 15:38 |
| rick_h_ | stickupkid: when would you get that message? | 15:38 |
| stickupkid | bootstrap | 15:38 |
| rick_h_ | stickupkid: but if I bootstrap a remote I added as a cloud with a credential why would I get that error? | 15:39 |
| stickupkid | so say you have some lxc remotes in your lxc client, you forget to add a credential for that lxc remote, and then do bootstrap | 15:40 |
| stickupkid | it will try and use localhost, because LXD is special provider and always returns localhost creds :| | 15:40 |
| stickupkid | as we've conflated local vs remote for LXD we can't differentiate when you want which | 15:41 |
| rick_h_ | stickupkid: I thought we were looking into stopping that. What came of auto creating the localhost cloud credential automatically? | 15:42 |
| stickupkid | hmmm... i'm thinking when we could do that | 15:43 |
| stickupkid | during bootstrap? | 15:43 |
| rick_h_ | stickupkid: HO? | 15:44 |
| stickupkid | if so, we would need something like "providers.RegisterCloudCredentials()" <- tbh that would solve a lot of issues :| | 15:44 |
| stickupkid | sure please | 15:44 |
| magicaltrout | https://discourse.jujucharms.com/t/connectivity-issues/163/3 | 15:57 |
| magicaltrout | if anyones bored | 15:57 |
| rick_h_ | magicaltrout: ping'd the charmstore folks to see what's up. none of them in here :( | 16:00 |
| magicaltrout | thanks rick_h_ | 16:01 |
| zeestrat | Yeah, charmstore is having a bad day here as well. | 16:18 |
| stickupkid | rick_h_: this is looking and feeling good - i'm going to play with it more... | 16:47 |
| stickupkid | rick_h_: at least I'm on the right track \o/ | 16:48 |
| rick_h_ | stickupkid: good to hear | 17:32 |
| veebers | Morning all o/ | 20:24 |
| babbageclunk | externalreality_: You're working on something to do with update-series, is that right? | 22:07 |
| externalreality_ | babbageclunk, the owner of the connection to the api was the machine agent, it was trying to auth as its units. | 22:07 |
| babbageclunk | Ah, right. | 22:07 |
| externalreality_ | babbageclunk, instead we now auth as the machine and collects its units apiserver side | 22:08 |
| externalreality_ | babbageclunk, do you think that sounds more correct... I kind of think it does | 22:08 |
| babbageclunk | Ok, that sounds like exactly what I'd have suggested, awesome. | 22:08 |
| externalreality_ | babbageclunk, ack, thank you for the ear sir | 22:09 |
| veebers | kelvinliu_, thumper, rick_h_: Note: with the snap changes being made for the dep change we'll have to add some extra smarts to the release job so we can release either a 2.4.* or a 2.5.* in the future) | 22:09 |
| babbageclunk | externalreality_: no worries, it sounds like you sorted it out independently anyway! | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!