[01:29] <lucidone> On a k8s cloud (openstack magnum), am I responsible for deploying an ingress controller? (and cert-manager etc) are there charms for doing that?
[01:36] <lucidone> `juju expose $app` isn't doing much without a controller - which makes sense
[09:13] <nammn_de1> stickupkid: around to talk about the cmd init thing?
[09:14] <stickupkid> nammn_de1, sure
[09:14] <nammn_de1> stickupkid: need to get my coffee, meet in 5 min?
[09:14] <stickupkid> sure
[09:47] <nammn_de1> anyone ptal please? https://github.com/juju/juju/pull/11022 2.7 into develop
[11:20] <stickupkid> manadart, that took some doing, external controllers can now be imported :)
[11:20] <manadart> stickupkid: Sweet.
[11:20] <stickupkid> manadart, i'm just cleaning up the github PR page, but it's read for review
[11:20] <stickupkid> https://github.com/juju/juju/pull/11008
[11:27] <stickupkid> manadart, I've added some qa steps etc
[11:35] <nammn_de1> stickupkid: in jenkins, the parameters which are set, are those set as env?
[11:35] <stickupkid> nammn_de1, depends
[11:35] <nammn_de1> stickupkid: easy way to find out?
[11:36] <stickupkid> nammn_de1, most if not all are set directly via parameter builds and others can be buildvars
[11:36] <stickupkid> nammn_de1, yeah look at the job
[11:36] <stickupkid> *job config
[11:37] <nammn_de1> ah lol, I was looking at it. Thanks, I just realized why I got confused. We had some which used a `region` but never used it in the config
[11:37] <nammn_de1> and then I had the thought, well someone might had something in mind doing it. Probably a env :D
[11:39] <stickupkid> nammn_de1, most if not all should be parameters
[11:39] <nammn_de1> stickupkid: got it
[14:31] <nammn_de1> stickupkid manadart hml: the region addition thing: https://github.com/CanonicalLtd/juju-qa-jenkins/pull/348
[14:32] <nammn_de1> while at it: https://github.com/juju/juju/pull/11022 just checked,  thumper https://github.com/juju/juju/pull/11019 merge does not include the other PR merges
[14:33] <nammn_de1> thumper ff is around 20 hours old, while the pr i include are newer as it seems
[14:34] <nammn_de1> reason is mostly only my test-branches change
[14:53] <stickupkid> ah, feels good - 100% coverage https://pastebin.canonical.com/p/SbXGPvGZyC/
[15:05] <nammn_de1> rick_h: https://github.com/juju/juju/pull/11024
[15:05] <nammn_de1> works as described
[15:05] <nammn_de1> now
[15:16] <nammn_de1> stickupkid: https://github.com/juju/juju/blob/develop/cmd/juju/firewall/setrule.go#L33-L35 as wallyworld said before, we only support ssh right now. The others can be set but don't have an effect yet. How do we want to handle that? Removing them? Adding a pointer that they are not implemented yet, but eventually will be ?
[15:16] <nammn_de1> rick_h^
[15:20] <stickupkid> manadart, considering this folder is 100% independant from state, I wonder if we should move it to core https://github.com/juju/juju/tree/develop/state/migrations
[15:23] <manadart> stickupkid: Maybe into the migration package at the root, as that stuff isn't used ubiquitously.
[15:23] <stickupkid> manadart, legit
[16:15] <rick_h> nammn_de1:  looking
[16:38] <nammn_de1> rick_h: yes, it does exactly that :D
[16:47] <stickupkid> manadart, you around?
[16:53] <rick_h> nammn_de1:  ok
[16:54] <stickupkid> rick_h, quick ho, I have a question around firewall rules...
[16:54] <stickupkid> ?
[16:56] <rick_h> stickupkid:  omw
[17:33] <stickupkid> rick_h, solved it, I've made some clean up to simplify :D
[17:36] <rick_h> woot
[19:40] <timClicks> A good thread is emerging on discourse around the use of public charms: https://discourse.jujucharms.com/t/-/2446
[19:41] <rick_h> yea, definitely points out we need to be ahead of the game a little bit with the snap store changes to namespaces and such
[19:41] <rick_h> take some getting used to
[19:50] <nammn_de1> rick_h: thanks!