[00:38]  * thumper is leaching free cbd wifi
[00:38] <thumper> wallyworld: ping
[00:43] <wallyworld> thumper: hey
[02:10] <axw> wallyworld: https://github.com/juju/juju/pull/8141 adds the initial caasoperator API
[02:11] <axw> wallyworld: I'm going to tack on another commit to move the caasprovisioner facade from facades/agent to facades/controller, OK?
[02:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <wallyworld> sure
[02:49] <babbageclunk> 1:1
[05:40] <axw> wallyworld: did you share the image with me? I didn't get a notification or anything
[05:41] <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:43] <wallyworld> axw: wallyworld/caas-jujud-operator
[05:43] <axw> ta
[05:47] <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:48] <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:49] <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:50] <axw> wallyworld: OK, ta
[05:56] <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:57] <wallyworld> yeah, looking now
[06:03] <wallyworld> looks great, thanks for picking up the rename
[06:23] <axw> wallyworld: https://github.com/juju/juju/pull/8143  - small one, gets things working iwht minikube
[06:53] <wallyworld> axw: did you run minikube from the snap?
[07:01] <axw> wallyworld: no, I don't recall how I installed it, but it's not a snap
[07:02] <wallyworld> axw: i tried it - getting errors dialling address. someone else also had same issue using snap
[07:03] <axw> wallyworld: minikube itself has issues, or juju has issues using k8s set up with snapped minikube?
[07:03] <wallyworld> minikube itself
[07:04] <wallyworld> damn same without snap
=== frankban|afk is now known as frankban
[09:01] <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:16] <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:17] <axw> wallyworld: sweet :)
=== freyes__ is now known as freyes
[15:23] <balloons> wpk, can you review https://github.com/juju/juju/pull/8086?
[15:27] <wpk> balloons: one suggestion, LGTM
=== frankban is now known as frankban|afk
[21:34] <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:35] <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:36] <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:37] <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:38] <wallyworld> otp, can't think, give me a few
[21:38] <babbageclunk> ok, I'll do an experiment
[21:51] <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:54] <babbageclunk> wallyworld: but the call includes the API version: st.APICall("Admin", 4, "", "Login", request, &result)
[21:55] <babbageclunk> wallyworld: and the LoginResult is where we get the facade versions to work out which version we should send.
[21:56] <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:57] <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:58] <wallyworld> oh yeah
[21:58] <wallyworld> chicken and egg
[21:59] <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
[22:03] <babbageclunk> wallyworld: yeah, it looks like it was just "try this version, no, try this one, no, try this one - ok".
[22:04] <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:07] <babbageclunk> wallyworld: cool, thanks.
[22:26] <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:28] <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:29] <wallyworld> we can discuss at standup perhaps
[22:30] <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:31] <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:32] <babbageclunk> I'll go through your other comments.
[23:58] <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