=== mup_ is now known as mup
[00:09] <timClicks> https://jaas.ai/docs/getting-started - would love people's feedback on this, esp. on whether it makes you more motivated to share it!
[00:15] <wallyworld> babbageclunk: sorry, was at bank, i can tell you in standup
[00:15] <babbageclunk> ok
[01:04] <wallyworld> babbageclunk: got a sec? standup?
[01:04] <babbageclunk> wallyworld: sure omw
[01:12] <wallyworld> babbageclunk: and remove-application --force works as well as remove-relation --force, right?
[01:13] <babbageclunk> It should do... looking in the code now, hang on
[01:15] <wallyworld> babbageclunk: and also, remove-offer --force should send through the correct option to force remove the app which then force removes the relation etc
[01:15] <wallyworld> normally you can't remove an offer if there's still the app it is offering
[01:17] <babbageclunk> yeah, remove-offer --force definitely does that
[01:19] <babbageclunk> I'm not sure about the remove-application --force one removing the relation when there's a stuck unit - I'm sure it will if the --force is done straight away but it's possible that if you do it unforced first then maybe the removeCount handling will mean that the application doesn't get removed.
[01:19] <babbageclunk> I'll give it a try this afternoon
[01:19] <babbageclunk> no sign of those raft timeouts on scaling stack
[01:23] <wallyworld> i'm also going to test removing an offering model
[01:23] <wallyworld> we should be sure that --force works anytime
[01:23] <wallyworld> even after a try without
[02:39] <kelvinliu> wallyworld: we don't support `deployment` field in metadata yet, right?
[02:39] <wallyworld> we do
[02:39] <wallyworld> for service type
[02:40] <kelvinliu> charm-tools doesn't support it yet
[02:40] <wallyworld> oh, maybe not
[02:40] <wallyworld> that will need fixing
[02:40] <kelvinliu> wondering how to build the charm has deployment field
[02:41] <wallyworld> i think i have edited the built charm in the past
[02:41] <wallyworld> can't recall exactly
[02:41] <kelvinliu> i guess, Juju itself support but we never have any charm use it yet
[02:41] <wallyworld> yeah, probably
[02:42] <kelvinliu> ok, i will have a 3rd PR on charm tools repo
[02:46] <wallyworld> ok
[05:57] <babbageclunk> wallyworld: managed to test the scenario you were wondering about - remove-application with a stuck unit in a relation, then remove-application --force - it worked!
[06:25] <wallyworld> babbageclunk: awesome! i tested too
[06:25] <wallyworld> i stopped a lxd controller and did stuff to the other controller in cmr
[06:26] <wallyworld> seemed to go ok
=== exsdev0 is now known as exsdev
[12:16] <achilleasa> manadart: I have updated my PR to only persist the subnetID and fixed some broken tests. Can you take a look? I am now looking at the instancepoller bits...
[12:18] <manadart> achilleasa: Yep.
[13:38] <jhobbs> hi kwmonroe, could you please help get a new version of the grafana charm published to pick up a change in layer snap? https://bugs.launchpad.net/grafana-charm/+bug/1843745
[13:38] <mup> Bug #1843745: snap install causes error if there are non-ascii characters in the output <cdo-qa> <foundations-engine> <Grafana Charm:New> <Snap Layer:Fix Released> <https://launchpad.net/bugs/1843745>
[14:24] <achilleasa> manadart: CI passes for my PR. Should I go ahead and land it?
[14:42] <kwmonroe> jhobbs: https://jaas.ai/grafana/31 is in edge.  i'm running the upgrade tests now; pending success, you cool if i push that through to stable, or would you like some time to test?
[14:46] <jhobbs> kwmonroe: i'll give it a spin real quick, thanks
[14:53] <manadart> achilleasa: Yes.
[14:54] <achilleasa> manadart: I need a tick ;-)
[14:54] <manadart> achilleasa: Oops. Did the ol' comment review. Done.
[14:57] <kwmonroe> jhobbs: one thing we've done for other charms that include layer:snap is provide a 'core' resource so people can attach a core.snap to facilitate the install in offline deployments.  prometheus2 and graylog have this, but i see that grafana does not.  is that important for you?
[14:59] <jhobbs> kwmonroe: i'm surprised that hasn't come up yet; I think the field team drove those requests before. I suspect it will be required for grafana too
[15:00] <jhobbs> kwmonroe: my test just passed so I'm +1 whenever yours complete
[15:00] <kwmonroe> fwiw, we'd add a 'core' and 'grafana' resource -- 0-bytes by default.  it came up for a smattering of charms: https://bugs.launchpad.net/graylog-charm/+bug/1828063, but we didn't have grafana on the list.
[15:00] <mup> Bug #1828063: core snap is not a defined resource for charms that have other snaps as a resource definition <cpe-onsite> <Etcd Charm:Fix Released by cynerva> <Kubernetes E2E Test Charm:Fix Released by cynerva> <Kubernetes Master Charm:Fix Released by cynerva> <Kubernetes Worker Charm:Fix Released
[15:00] <mup> by cynerva> <Graylog Charm:Fix Released by kwmonroe> <Prometheus2 charm:Fix Released by kwmonroe> <vault-charm:Fix Released by cynerva> <https://launchpad.net/bugs/1828063>
[15:02] <kwmonroe> jhobbs: upgrade tests just passed; https://jaas.ai/grafana/31 is now through to stable.
[15:03] <kwmonroe> i'll note grafana on the above bug as "affected projects" and get that worked soonish.
[15:06] <jhobbs> kwmonroe: great, thanks on both counts!
[15:47] <achilleasa> rick_h: I am still going through the docs/deploy cmd sources for the binding bits. If it turns out that it's not that hard to also update existing bindings when upgrading charms do we want to land that as a single chunk of work?
[15:49] <rick_h> achilleasa:  have a sec to chat?
[15:56] <achilleasa> rick_h: sure. meet you in daily?
[15:56] <rick_h> achilleasa:  sure thing
[17:52] <pmatulis> can juju pass autostart order information to containers? it should be able to pass any configuration key right?
[18:30] <hml> pmatulis: i don’ tbelieve you can
[19:11] <pmatulis> hml_, oh!
[19:11] <hml_> pmatulis:  that data would go in the profile for the container right?
[19:11] <pmatulis> hml_, i don't think so
[19:12] <hml_> pmatulis:  how would you get it up then?
[19:12] <pmatulis> it would be key 'boot.autostart.priority' (see https://lxd.readthedocs.io/en/latest/containers/)
[19:13] <hml_> pmatulis:  right.. those values end up in the container profiles
[19:14] <pmatulis> ohh
[19:14] <hml_> pmatulis:  juju won’t pass up anything… and boot is an excluded key in lxdprofiles from a charm
[19:16] <pmatulis> i thought boot priority would be at the lxd daemon level. doesn't a profile just apply to a single container? seems this key controls multiple containers
[19:16] <hml_> pmatulis:  you can have a default profile which applies to all containers
[19:17] <hml_> you can multiple profiles on a container if you want
[19:18] <pmatulis> oh, that makes sense then
[19:18] <pmatulis> it would be sweet to have a bundle dictate the order in which containers would come up
[19:18] <pmatulis> but i guess not
[19:19] <hml_> pmatulis: the order to boot in?  or are created in?
[19:35] <pmatulis> hml_, booted, on the host
=== hml_ is now known as hml
[22:31] <ezobn> Hi! I have some issues. I had got nice working juju openstack Queens deployment. So trying to upgrade it to Rocky. Have got upgrades all charms themselves. Everything good except openstack compute service list is empty. And debug on nova-cloud-controller shows that it is some timeouts reading nova cells that have found. But them never been configured in the system.  Any bugs on this by the chance?