| * thumper is leaching free cbd wifi | 00:38 | |
| thumper | wallyworld: ping | 00:38 |
|---|---|---|
| wallyworld | thumper: hey | 00:43 |
| axw | wallyworld: https://github.com/juju/juju/pull/8141 adds the initial caasoperator API | 02:10 |
| axw | wallyworld: I'm going to tack on another commit to move the caasprovisioner facade from facades/agent to facades/controller, OK? | 02:11 |
| babbageclunk | dear wallyworld: I want to bootstrap a 2.3-rc1 controller with old audit logging turned on so I can test the upgrade step, but even though I'm specifying --config "auditing-enabled=true" at bootstrap, when I look at controller-config for the running controller it says auditing is off. What am I doing wrong? Is there some trick? Yours &c, Wondering in Whitby | 02:42 |
| wallyworld | axw: sgtm. do you have a dockerhub user id? | 02:42 |
| wallyworld | babbageclunk: it's pulling down the released tarball | 02:42 |
| wallyworld | as that is in streams | 02:43 |
| wallyworld | you need --build-agent | 02:43 |
| wallyworld | to force it to upload a local jujud and override the published version | 02:43 |
| wallyworld | in general, try not to develop on the same version as is released | 02:43 |
| babbageclunk | sure - I want a controller with the old behaviour so I can upgrade to mine. | 02:43 |
| axw | wallyworld: nope, I'll create one | 02:44 |
| wallyworld | in that case upgrade-juju --build-agent | 02:44 |
| wallyworld | axw: i have a jujud image pushed - i'll give access to we can hard code that one into juju for now | 02:44 |
| babbageclunk | No, the bootstrapped controller (before upgrade) doesn't have the old audit logging running. | 02:44 |
| babbageclunk | But I want it to. | 02:44 |
| axw | wallyworld: docker ID: axwalk | 02:45 |
| wallyworld | ok | 02:45 |
| wallyworld | babbageclunk: rc1 controller will have old logging. and you want to upgarde to tip of develop right? | 02:45 |
| axw | brb, restarting | 02:46 |
| babbageclunk | Yes, but first I want to have a controller with the old logging, but the one I've got has auditing off. | 02:46 |
| wallyworld | sure, i don't get the issue though - just bootstrap an rc1 controller | 02:47 |
| babbageclunk | I have | 02:47 |
| wallyworld | and upgrade with a local jujud | 02:47 |
| wallyworld | so what isn't working? | 02:47 |
| babbageclunk | The one I have doesn't have audit logging turned on, even though it's the old version and I specified --config "auditing-enabled=true" | 02:48 |
| babbageclunk | Can we do a hangout? | 02:48 |
| wallyworld | sure | 02:49 |
| babbageclunk | 1:1 | 02:49 |
| axw | wallyworld: did you share the image with me? I didn't get a notification or anything | 05:40 |
| wallyworld | axw: i added you as a collaborator; there was no option i could see to set anything else | 05:41 |
| axw | wallyworld: what's the docker hub url to the image? maybe I need to navigate there directly. doesn't show up on my proifle anywhere I can see | 05:41 |
| wallyworld | axw: wallyworld/caas-jujud-operator | 05:43 |
| axw | ta | 05:43 |
| axw | wallyworld: have you pushed the Dockerfile somewhere? doesn't appear to be viewable there | 05:47 |
| wallyworld | i have pushed it | 05:47 |
| wallyworld | hmmmm | 05:47 |
| axw | wallyworld: I can see https://hub.docker.com/r/wallyworld/caas-jujud-operator/, but no details. just a docker pull command | 05:48 |
| wallyworld | https://hub.docker.com/r/wallyworld/caas-jujud-operator/ | 05:48 |
| axw | wallyworld: I might be able to push an image there... but I can't see the Dockerfile | 05:48 |
| wallyworld | i can't see the dockerfile either, i just pushed the image | 05:49 |
| wallyworld | i'm about to put up a PR with the dockerfile in it | 05:49 |
| axw | wallyworld: OK, ta | 05:50 |
| wallyworld | axw: https://github.com/juju/juju/pull/8142 | 05:56 |
| axw | wallyworld: thanks, looking. ICYMI, please take a look at https://github.com/juju/juju/pull/8141 | 05:56 |
| wallyworld | yeah, looking now | 05:57 |
| wallyworld | looks great, thanks for picking up the rename | 06:03 |
| axw | wallyworld: https://github.com/juju/juju/pull/8143 - small one, gets things working iwht minikube | 06:23 |
| wallyworld | axw: did you run minikube from the snap? | 06:53 |
| axw | wallyworld: no, I don't recall how I installed it, but it's not a snap | 07:01 |
| wallyworld | axw: i tried it - getting errors dialling address. someone else also had same issue using snap | 07:02 |
| axw | wallyworld: minikube itself has issues, or juju has issues using k8s set up with snapped minikube? | 07:03 |
| wallyworld | minikube itself | 07:03 |
| wallyworld | damn same without snap | 07:04 |
| === frankban|afk is now known as frankban | ||
| thumper | jam: https://github.com/juju/juju/pull/8144 and now I'm off to bed :) | 09:01 |
| thumper | night | 09:01 |
| jam | thumper: night, | 09:01 |
| thumper | jam: if it's good, ask the bot to merge, if it needs fixing, it can wait until 2.3.1 | 09:01 |
| thumper | thanks | 09:01 |
| wallyworld | axw: just tested latest feature branch code - using image i just pushed to dockehub - it hangs together nicely :-) need to check python libs in the image etc but good start | 09:16 |
| axw | wallyworld: sweet :) | 09:17 |
| === freyes__ is now known as freyes | ||
| balloons | wpk, can you review https://github.com/juju/juju/pull/8086? | 15:23 |
| wpk | balloons: one suggestion, LGTM | 15:27 |
| === frankban is now known as frankban|afk | ||
| babbageclunk | wallyworld: I've revved the Admin API version, but I haven't made the v3 API do anything different with the CLI args - if they're passed in they'll get stored in the same way as they will for v4. | 21:34 |
| wallyworld | babbageclunk: righto, i think that's ok | 21:35 |
| babbageclunk | wallyworld: On the client, do I need to start checking for API versions before the Login request? | 21:35 |
| wallyworld | i don't think so since things won't break | 21:36 |
| babbageclunk | wallyworld: So an old controller would be ok with a client sending a v4 Login request? | 21:36 |
| wallyworld | if it doesn't have a params struct that knows about cli args, it will just drop them | 21:37 |
| babbageclunk | But we explicitly say version 4 in the API call - will that cause a problem? | 21:37 |
| babbageclunk | I guess I can try that... | 21:37 |
| wallyworld | otp, can't think, give me a few | 21:38 |
| babbageclunk | ok, I'll do an experiment | 21:38 |
| wallyworld | babbageclunk: IIANM the request doesn't include any version - it just connects to whatever facade is there. it's up to the client to determine if that version is fit for purpose | 21:51 |
| babbageclunk | wallyworld: but the call includes the API version: st.APICall("Admin", 4, "", "Login", request, &result) | 21:54 |
| babbageclunk | wallyworld: and the LoginResult is where we get the facade versions to work out which version we should send. | 21:55 |
| babbageclunk | wallyworld: so if I bump the version in the client login call then it can't talk to a controller that only supports v3. | 21:56 |
| wallyworld | babbageclunk: hmm, normally that version is set to BestAPIVersion() so i think Login is different | 21:56 |
| babbageclunk | I guess we could try 4 then fallback to 3? Seems like a lot of work for this backwards compatible case though. | 21:57 |
| wallyworld | we could just set it to BestAPIVersion() like other api calls | 21:57 |
| babbageclunk | But doesn't BestAPIVersion rely on having the API versions from the loging result? | 21:57 |
| babbageclunk | login | 21:57 |
| wallyworld | oh yeah | 21:58 |
| wallyworld | chicken and egg | 21:58 |
| wallyworld | we used to handle login 1, 2 and 3 | 21:59 |
| wallyworld | but all that code was deleted | 21:59 |
| wallyworld | not sure how it used to work | 21:59 |
| babbageclunk | How'd we do the negotiation? Just trying again? | 21:59 |
| babbageclunk | I'll have a look | 21:59 |
| wallyworld | all that was in the 1.25 branch | 21:59 |
| babbageclunk | wallyworld: yeah, it looks like it was just "try this version, no, try this one, no, try this one - ok". | 22:03 |
| babbageclunk | wallyworld: If it's ok with you, I'm not going to put that in for this. | 22:04 |
| wallyworld | ok i think | 22:04 |
| wallyworld | just stick with v3 | 22:04 |
| babbageclunk | wallyworld: cool, thanks. | 22:07 |
| babbageclunk | wallyworld: can you put a tick on https://github.com/juju/juju/pull/8130 please/thankyou? | 22:26 |
| wallyworld | sure | 22:26 |
| babbageclunk | cheers! | 22:26 |
| babbageclunk | wallyworld: ooh, thanks for the comments on the other PR. | 22:28 |
| wallyworld | babbageclunk: no worries - i am a little confused about the subtle? differences between Call and Request | 22:28 |
| wallyworld | we can discuss at standup perhaps | 22:29 |
| babbageclunk | wallyworld: yeah, you're right they're confusing. Call represents a top-level juju command (which will produce multiple requests/responses) | 22:30 |
| babbageclunk | Maybe command or connection? | 22:30 |
| wallyworld | babbageclunk: is in, in the cmd/juju package, the CLI creates one or more facades and then makes various api calls on those facades | 22:31 |
| babbageclunk | Yup | 22:31 |
| wallyworld | yeah, Call not so good then. let's brainstorm in standup | 22:31 |
| babbageclunk | ok | 22:31 |
| babbageclunk | I'll go through your other comments. | 22:32 |
| axw | wallyworld: need to run QA still, but please take a look at https://github.com/juju/juju/pull/8149 later? | 23:58 |
| axw | test failures have been driving my crazy | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!