[00:02] <veebers> Can I get a review on https://github.com/juju/juju/pull/8599 please :-)
[00:11] <wallyworld> looking
[00:13] <wallyworld> veebers: lgtm
[00:13] <wallyworld> kelvinliu: don't forget to $$merge$$ your PR once approved
[00:14] <veebers> wallyworld: cheers
[00:20] <kelvinliu_> yup, i am doing it now, thx Ian
[01:35] <thumper> anastasiamac: I just realised I have a clash around our 1:1, I have a physio appt
[01:35] <thumper> anastasiamac: can we do it an hour later?
[01:35] <anastasiamac> thumper: sounds good
[01:35] <thumper> thanks
[01:42] <wallyworld> kelvinliu: i am seeing a hook execution error in the mysql charm when adding a relation to gitlib. it's related to some python executed by the reactive framework and looks like an incorrect file path is being passed in. so something has changed which needs to be fixed
[01:44] <wallyworld> kelvinliu: this is the log from the mysql unit pod. you'll see the error in there https://pastebin.ubuntu.com/p/zmgH3Hxkvh/
[01:45] <wallyworld> would be good to know if you're seeing the same issue
[01:46] <anastasiamac> an easy review PTAL, adding bionic to utils - https://github.com/juju/utils/pull/299
[01:47] <kelvinliu_> i just recreated the k8s core controllers and models, but a install hook was failed in worker node and didnot retry. So I deleted whole models and controller and is doing it again. the cluster is stablizing now
[01:47] <wallyworld> kelvinliu: it's coming from this reactive helper def juju_version():
[01:48] <wallyworld> the path for jujud is different
[01:48] <wallyworld> so i need to make an upsteam change to account for that
[01:49] <wallyworld> for caas agents, it's /var/lib/juju/tools
[01:49] <wallyworld> not /var/lib/juju/tools/machine-*
[01:50] <wallyworld> anastasiamac: lgtm, ty
[01:51] <anastasiamac> wallyworld: \o/ phenomenal! thnx
[01:51] <kelvinliu_> u mean in charms.reactive ?
[01:52] <wallyworld> kelvinliu: yeah, in the core package
[01:54]  * thumper afk for a bit
[01:55] <kelvinliu_> https://github.com/juju/charm-helpers/blob/master/charmhelpers/core/hookenv.py#L1042
[01:55] <kelvinliu_> i can work on this
[02:06] <wallyworld> kelvinliu: that's upstream. the best way to test I think i to add a replacement function to the hookenv.py file in the reactive base layer for caas. that function in there *should* be used in preference to the upstream core one. we can get things working and then publish changes to the caas base layer. it will take a bit more then to get stuff upstream
[02:09] <kelvinliu_> sure, agreed
[03:35] <vino> what is the clean way to get the controller destroyed ? i started the bootstrap but then i gave sigkill :(
[03:38] <vino> destroy gives trouble
[03:41] <wallyworld_> kill-controller
[03:42] <wallyworld_> i normally do "juju kill-controller -t 0 -y <name>"
[03:43] <vino> ok. thx. i didnt know this and was trying some other froce option with destroy
[03:43] <vino> which doesnt exists
[03:43] <veebers> wallyworld_: d'oh, could have sworn I ran the whole suite, I updated https://github.com/juju/juju/pull/8599 with a unit test fix (I realise now I squashed it so it'll be harder to see the test changes :-\)
[03:51] <anastasiamac> wallyworld_: i replied but u seemed to have bowed out of Canonical channels.... so dunno if u saw...
[03:56] <wallyworld> vino: vpn messed with irc, did you see my reply above?
[03:56] <vino> kill-controller ?
[03:56] <vino> yes
[03:56] <wallyworld> great
[03:56] <vino> thx
[04:17] <thumper> babbageclunk: got a few minutes to talk about the engine worker dependency issues?
[04:21] <babbageclunk> thumper: yup yup! Would welcome more ideas
[04:21] <babbageclunk> in 1:1?
[04:24] <babbageclunk> thumper: ?
[04:32] <babbageclunk> I guess he went away
[04:42] <wallyworld> babbageclunk: 12 line PR?
[04:42] <wallyworld> https://github.com/juju/juju/pull/8601
[04:42] <wallyworld> kelvinliu: the above fixes the mysql/gitlab issue ^^^^^
[04:42] <babbageclunk> wallyworld: with pleasure!
[04:42] <wallyworld> yay!
[04:42] <wallyworld> until we get upstrean charmhelpers fixed
[04:42]  * wallyworld afk for a meeting for a bit
[05:28]  * thumper takes a deep breath
[05:29]  * thumper gets back to tests for migrationmaster facade
[05:35] <jam> wallyworld: thumper: /wave. I don't think I have anything pressing to bring up, though I'm curious how the meeting on Friday went.
[05:35] <thumper> jam: which one?
[05:35] <jam> btw, are we supposed to be switching to #juju?
[05:35] <jam> thumper: mark
[05:35] <thumper> yes
[05:35] <thumper> jam: it went really well
[05:36] <thumper> jam: I want to sort the mailing lists out first, and was going to announce irc changes when that was done
[05:36] <jam> sure
[05:36] <thumper> bug got a bit caught up trying to finish something off
[06:30]  * vino in induction prg
[07:07] <wallyworld> vino: there's a go fmt error in the juju run pr thant landed cmd/juju/commands/run_test.go:95:30: missing ',' before newline in composite literal
[07:10] <wallyworld> kelvinliu: i just pushed a new version of the operator image to dockerhub which adds a symlink the the jujud that the pythin charm helper code expects. will will still need to fix the python though
[07:10] <wallyworld> but things will work again with this change
[07:11] <wallyworld> we'll need to add the fixed python to the base base layer next and once that's verified, push an upstream change
[07:13] <vino> hi wallyworld
[07:13] <vino> i am looking into it.
[07:13] <wallyworld> hey
[07:13] <wallyworld> thank you
[07:16] <vino> not just that i found another issue as well.
[07:50] <vino> juju run is broken because of the commit we made this morning it wont work without explicitly specifying a timeout value
[08:17] <kelvinliu_> thx Ian.
[08:47] <vino> wallyworld:  PR#8603 fix for run command
[08:53] <wallyworld> looking
[08:53] <vino> thank u
[08:54] <wallyworld> vino: lgtm
[20:11] <admcleod_> anyone here have experience with a mixed provider model, e.g. MAAS + manually provisioned machines?
[20:13] <rick_h_> admcleod_: what are you looking for?
[20:13] <admcleod_> someonet that has experience with that
[20:13] <rick_h_> admcleod_: in what way? I mean I know several folks have used it for certain things
[20:14] <admcleod_> i have a controller in maas, ive added an s390x lpar (it has to be a manually provisioned machine)
[20:14] <rick_h_> k
[20:14] <admcleod_> and im having issues with deploying bundles to it. im in the process of trying different scenarios to create a bug
[20:14] <admcleod_> but someone may know something very explicit already
[20:15] <rick_h_> this hit the mailing list right? /me thought he saw it earlier today
[20:15] <admcleod_> i didnt post it there
[20:15] <rick_h_> ah sorry, the main juju channel
[20:15] <admcleod_> yep :)
[20:17] <rick_h_> admcleod_: so if you add a machine for the non-s390x and then use the --map-machines where 0=0,1=1 (assuming 0 is the lpar per the other convo) that fails to work work?
[20:17] <rick_h_> hmm, one thing I've not tested out is if the map-machines will allow you to only map some of the machines in the bundle to existing numbers in the model
[20:18] <admcleod_> well. im using --map-machines=existing, because if its ALL manual provider, that works fine
[20:18] <admcleod_> but what im seeing so far is that it wont use the existing machine
[20:18] <admcleod_> i have 12 different scenarios that im trying out now to add to a bug, e.g., bundle with/without machines, with/without constraints, with/without map machines
[20:19] <rick_h_> right, but if you're map machine existing but you only have one machine manually added I'm not sure how that's supposed to work right
[20:19] <rick_h_> constraints are ignored if a placement directive is in play
[20:19] <rick_h_> you've overriden any of that
[20:19] <rick_h_> and map machines is just a placement directive is my understanding
[20:19] <admcleod_> well, that may be what its supposed to do
[20:19] <admcleod_> but im testing it regardless
[20:19] <rick_h_> there's no sense saying "constrain to a machine with 4g of ram and put it on machine 2"
[20:20] <rick_h_> k
[20:20] <admcleod_> sure. that makes no sense.
[20:20] <admcleod_> neither does 'map-machines=existing' .. oh ill ask for another machine from maas then
[20:20] <rick_h_> right
[20:21] <rick_h_> so I would expect that before the bundle deploy you'd have the existing machines setup, you'd map number by number (or they have to match the same number in the bundle to the number in the model) and it should work?
[20:21] <rick_h_> but you're saying that it fails to work properly in that case?
[20:21] <admcleod_> well, imagine a scenario where i want 3 machines for 3 magpie units (the real scenario is openstack with different hypervisor architectures)
[20:21] <admcleod_> so i have to add the s390x machine before i deploy the bundle
[20:21] <admcleod_> but its a maas controller for the amd64 nodes
[20:22] <admcleod_> so i only manually add 1 machine
[20:22] <admcleod_> then what i would expect is if i deploy the bundle with --map-machines=existing, it would use the manually provisioned machine and request 2 more from maas
[20:22] <rick_h_> so I'd ask you to not use existing, but instead use a number match for that one machine and see if it works
[20:22] <admcleod_> ill try that now
[20:23] <admcleod_> but why should existing not work?
[20:23] <admcleod_> does that imply 'all must exist or i will ignore you'?
[20:23] <rick_h_> so I'm nervous about what "existing" does as it's assuming use the numbers of the machines in the bundles against the same numbers in the model
[20:23] <thumper> morning
[20:23] <rick_h_> this is what I mean in that I've not tested a partial deploy like that where only some machines are available in the model vs not
[20:24] <admcleod_> ok, let me tell you what happens with the number...
[20:24] <rick_h_> thumper: here can tell you the what why after that :)
[20:26] <thumper> balloons: shall we use the QA sync for the 1:1 you can't make tomorrow?
[20:26] <admcleod_> rick_h_: didnt work, pastebin coming
[20:27] <rick_h_> admcleod_: kk
[20:27]  * thumper awaits pastebin
[20:27] <admcleod_> wait wrong bundle, have to do that again
[20:28] <rick_h_> ah ok
[20:28] <thumper> admcleod_: can you make sure we have the status showing machines, and the bundle?
[20:28] <admcleod_> thumper: yep
[20:32] <admcleod_> alright, so if i specify the machines in the bundle correctly, then both map-machines=existing and map-machines=#=# work ok. so thats ok
[20:33] <rick_h_> admcleod_: ok cool, that makes me feel a little better
[20:33] <admcleod_> so map-machines=existing explicitly requires machine defintiions and placement directives?
[20:33] <rick_h_> admcleod_: that's what I'm not sure what exactly existing does. I've not used it much tbh. If I map I go all mappy
[20:33] <admcleod_> i was hoping i could specify a constraint, e.g. arch, and that would map to existing machines
[20:33] <rick_h_> admcleod_: yea, but since mapping is a placement, constraints get ignored
[20:34] <admcleod_> alright
[20:34] <admcleod_> so then i cant use constraints with manually added machines?
[20:34] <rick_h_> admcleod_: I don't think there's a place where that works out because you're back to saying "constraint this" but at the same time it's about matching machine numbers.
[20:35] <admcleod_> well. if i was only using MAAS for machines, i could ignore defining machines explicitly, and use arch constraints
[20:35] <rick_h_> admcleod_: right
[20:35] <rick_h_> "let the provider deal with it"
[20:36] <admcleod_> but i cant do that with a manually added machine
[20:36] <veebers> Morning all
[20:36] <rick_h_> but when you go with manual machines and mapping you've taken the provider out of the picture
[20:36] <admcleod_> is that a 'feature' or a bug?
[20:36] <admcleod_> well forget mapping then
[20:36] <rick_h_> hmm, if you don't do any mapping and all the machine were added to the model (e.g. you weren't asking juju to provider for some things and not for others) I'm not sure tbh
[20:37] <admcleod_> right so i guess "juju deploy" talks directly to the provider and doesnt check manually provisioned machines first
[20:37] <rick_h_> right
[20:37] <admcleod_> that is incredibly annoying
[20:37] <thumper> admcleod_: existing effectively replaces 0=0,1=1,2=2...
[20:38] <admcleod_> thumper: right
[20:38] <thumper> explicit mapping overrides existing
[20:38] <thumper> you can use explicit mapping with and without existing
[20:38] <admcleod_> alright. so i can sort of work around my issue with mapping and machine specification and placement
[20:38] <thumper> admcleod_: deploy of bundles does check the existing model first
[20:39] <admcleod_> thumper: ah well it doesnt seem like it does
[20:39] <thumper> no... it does
[20:39] <thumper> I'd like a concrete example that shows it isn't working
[20:39] <admcleod_> thumper: ok, without machine definitions, with a manually added machine, with constraints
[20:39] <rick_h_> thumper: so if he manually adds a machine of a unique arch into the model and then deploys the bundle and expects juju to match the machine based on arch constraints juju will not pick up the existing machine
[20:39] <rick_h_> thumper: because constraints = provider and the machine is not provider based (manaully added)
[20:40] <thumper> juju doesn't do any of that
[20:40] <thumper> use existing is *only* for numbered placement
[20:40] <admcleod_> ok
[20:40] <admcleod_> so forgt map-machines
[20:40] <admcleod_> how about just using constraints
[20:40] <rick_h_> thumper: that's what we're saying. If you juju add-model; juju add-machine ssh.....(s390x); juju deploy openstack-bundle-with-one-s390x constraint machines;
[20:40] <admcleod_> thats what im trying to prove
[20:41] <rick_h_> it doesn't work that way
[20:41] <thumper> no... it doesn't work that way
[20:41] <thumper> at all
[20:42] <thumper> juju deploying a single app with constraints will never choose an existing machine
[20:42] <thumper> unless you use --to
[20:42] <thumper> which points to a machine
[20:42] <rick_h_> thumper: right, and then --to negates any constraint checks at that point.
[20:42] <thumper> this is outside bundles even
[20:42] <thumper> agreed
[20:42] <admcleod_> ok so thats my answer then
[20:42] <admcleod_> i cant use constraints
[20:42] <rick_h_> thumper: that's what we're establishing with admcleod_, he was hoping that to make his bundle work his only change to the deploy was to add the machine that matched the constraints manually.
[20:43] <admcleod_> and just before i bothered: https://pastebin.canonical.com/p/BYj5p3hfzT/
[20:43] <admcleod_> right because we have some bundles that do rely on constraints to provision multiple architectures without using --to
[20:43] <rick_h_> thanks for clarifying admcleod_
[20:43] <thumper> yeah, that isn't going to work with the current implementation
[20:43] <thumper> you can specify multiple architectures, but the provider must provide those
[20:44] <admcleod_> thumper: alrighty
[20:44] <thumper> can you maas also have a s390x pod?
[20:44] <thumper> s/you/your/
[20:45] <admcleod_> not right now
[20:45] <admcleod_> ill use --map-machines and explicit machines
[20:45] <admcleod_> it wouldve just been nice to be able to only use constraints
[20:45]  * thumper nods
[20:45] <thumper> I understand
[20:46] <thumper> babbageclunk: ping
[20:46] <admcleod_> i mean if juju knows the arch of the manually provided machine... would it be that hard to implement? or would that cause more problems than it would solve
[20:47] <thumper> I think it would cause more problems than it would solve without a comprehensive review of behaviour
[20:47] <admcleod_> right. i guess being explicit is the safest way
[20:47] <balloons> Morning thumper
[20:47] <admcleod_> alright thanks for not making me do that 24 times
[20:47] <thumper> babbageclunk: morning
[20:47] <thumper> ugh
[20:47] <thumper> that was ment for balloons
[20:48] <veebers> thumper: woah, getting a bit passive aggressive with your ping there ;-)
[20:48] <balloons> Sure we can chat now
[20:49] <thumper> balloons: I've jumped in our 1:1 HO
[20:57] <babbageclunk> thumper: morning!
[20:59] <babbageclunk> (also everyone else)
[21:16] <thumper> babbageclunk: I have something I'd like you to look at before our 1:1
[21:17] <babbageclunk> thumper: ok
[21:17] <thumper> babbageclunk: https://github.com/juju/juju/pull/8604
[21:17] <babbageclunk> (Oh which is at 10, not 9:30, right? I keep forgetting.)
[21:17] <babbageclunk> looking now
[21:18] <thumper> babbageclunk: yes 10
[21:45] <admcleod_> hrm. so should i also expect networking issues with this "mixed provider" model? i normally dont have a problem deploying to lxd on these manual machines, but in this scenario im getting "cannot get subnet" - so, presumably the MAAS provider has issues with the subnet used on the manually deployed machine?
[21:54] <thumper> babbageclunk: I'm in our 1:1 HO now if you can start early
[21:55] <babbageclunk> thumper: ok - not done with the review yet though (although probably also won't be by 10 either so <shrug>)
[21:55] <thumper> admcleod_: there is always opportunities for networking issues between a normal provider and manual
[21:55] <thumper> babbageclunk: I want to talk through that change a bit too
[21:56] <admcleod_> thumper: alright well ill log a bug for that one, not sure its much of a blocker