[01:29] <kelvinliu> wallyworld: I can't reproduce the missing sku name even on the 2.6 model upgraded from 2.4
[01:36] <wallyworld> kelvinliu: hmmm, not sure. i thought i reproduced it a while back. maybe ask him in #juju if he's tried it again with 2.7?
[01:38] <kelvinliu> yep
[03:38] <kelvinliu> wallyworld: I think I found the problem here, the model has to be upgraded from 2.3 but not 2.4+.
[03:40] <kelvinliu> wallyworld: im wondering we should land the fix to 2.7 or?
[03:41] <wallyworld> kelvinliu: 2.8 is fine
[03:41] <kelvinliu> ok, cool
[03:42] <wallyworld> i thought it was 2.4, but naybe we chnaged sku type in 2.4 and not 2.5
[03:50] <wallyworld> thumper: so yeah, i reproduced the issue where upgrade-charm hook runs "for no reason" deploying a bundle. WTF. need to figure out why
[03:55] <tlm> ian got 5 min for HO ?
[03:55] <tlm> wallyworld:
[03:55] <wallyworld> sure
[03:55] <thumper> wallyworld: cool, being able to reproduce is one of the hardest issues
[03:55] <wallyworld> yup
[03:57] <thumper> timClicks_: we should create a simple doc around agent ratelimiting with examples
[03:57] <thumper> something to add to the queue
[03:58] <kelvinliu> wallyworld:  it's not related with the SKU change at all. It's because we use unmanaged storage which requires a storage account but we changed to use managed storage for all model after 2.3. so no storage account anymore.
[04:01] <kelvinliu> for no storage account case, we set the SKU.Name to `Aligned`, but set an empty SKU struct for models do have a storage account (the one upgraded from 2.3)
[04:18] <wallyworld> kelvinliu: ah i see, nice pickup
[05:27] <kelvinliu> wallyworld: ah, can i grab u 2mins?
[05:29] <wallyworld> sure
[09:11] <flxfoo> Hi there
[09:13] <flxfoo> I am trying to patch an interface (solr). I have one first issue with current version, calling `add-relation` works fine, but `remove-relation` breaks with ('Unable to determine default scope: no current hook or global scope'
[09:13] <flxfoo> is that something that is on the interface side or something missing from the charm (which I doubt) ?
[09:14] <flxfoo> sorry working in the `apache-solr` charm not the interface.
[09:48] <stickupkid> I guess we use labels on PRs now
[09:48] <stickupkid> :)
[09:51] <achilleasa> manadart: on develop, is the core/network.InterfaceInfo populated by the machiner? I want to add a new field to indicate if this is a virtual port (for OVS)
[09:53] <achilleasa> does that mean that I need to bump the relevant APIs or are they already bumped on develop?
[09:57] <manadart> achilleasa: Yes, it will be populated by the machiner and instance-poller. I don't think they have been bumped on develop since the 2.8 release, but I may be wrong.
[09:57] <manadart> achilleasa: Technically it should be bumped right stickupkid? I think there have been instances where we have gotten away with omitempty.
[09:58] <achilleasa> manadart: stickupkid weren't they bumped when Origin was introduced?
[10:00] <manadart> achilleasa: Does it matter if it is a virtual port? InterfaceInfo already has IsVirtual returning true if the NIC is VLAN-tagged.
[10:00] <manadart> achilleasa: Origin went out with 2.8.0.
[10:01] <achilleasa> manadart: when starting kvm containers you need to pass "<virtualport type='openvswitch' />" to bridge to OVS
[10:02] <manadart> achilleasa: Righto.
[10:02] <achilleasa> to get that info in kvm/libvirt I can either add it to NetworkInfo which is decorated as a libvirt.Interface
[10:02] <achilleasa> or add it to the decorated type as an extra arg
[10:02] <achilleasa> which means that I need to fetch the OVS bridges and populate that on the fly when I boot the kvm container
[10:03] <achilleasa> I am doing the latter but thought that maybe if I added this info to NetworkInfo it would be more elegant
[10:04] <achilleasa> (also my NIC does not use VLANs so I can't use IsVirtual)
[10:04] <stickupkid> achilleasa, manadart yeah, but I'd need to check
[10:04] <manadart> achilleasa: We'll need it to flow back and forth right? In to state via InterfaceInfo->NetworkInfo->LinkLayerDevice and back the other way as network config?
[10:04] <achilleasa> manadart: yes... consirerably more effort than detecting on the fly
[10:05] <achilleasa> but I think it's better from a modeling perspective
[10:05] <manadart> achilleasa: Yes.
[10:05] <achilleasa> given that brctl skips ovs bridges I think it's better to have a more accurate view on the hardware (virtual or not)
[10:06] <achilleasa> plus, getting it in via the machiner will also allow me to use it in the lxd PR
[10:06]  * manadart nods.
[10:07] <achilleasa> ok, I will do that then and amend my lxd PR afterwards
[10:07] <achilleasa> we might be able to get away with omitempty here though given that the machiner will report it correctly eventually, right?
[10:08] <achilleasa> (so no bump would be required?)
[10:12] <stickupkid> anybody know where this package went in 2.8 https://github.com/juju/juju/tree/2.7/permission
[10:12] <stickupkid> ah core
[10:14] <stickupkid> I wish we had a job for `go mod tidy` <--
[10:16] <stickupkid> manadart, achilleasa https://github.com/juju/juju/pull/11689
[10:27] <achilleasa> stickupkid: I can review this in about 1h if that's OK. Trying to get a fix for the panic for the next 2.7 sha. Can you take a quick look at https://github.com/juju/bundlechanges/pull/62?
[10:28] <stickupkid> achilleasa, this is super super low priority, yeah I'll take a look
[10:31] <stickupkid> achilleasa, I love how the documentation for SplitN is wrong "The count determines the number of substrings to return"
[10:31] <stickupkid> achilleasa, well that's a lie, we asked for 2, you gave us 1
[10:32] <achilleasa> stickupkid: it's all best effort :D
[10:33] <stickupkid> achilleasa, SplitAtMaxNButProbablyWillBeLess()
[10:58] <manadart> stickupkid achilleasa: Can I get a review of https://github.com/juju/juju/pull/11690 ? It's just regenerated mocks.
[11:09] <stickupkid> manadart, ....
[11:10] <stickupkid> ah, you've added 2.7 as well
[11:58] <flxfoo> endpoint_from_flag() would return an object from a given flag that can be found in the logs. for endpoint_from_name() what would be the name form?
[13:38] <achilleasa> can I get a CR on https://github.com/juju/juju/pull/11692?
[13:39] <achilleasa> petevg: can you also take a look at the warning output and let me know if the wording is OK or tweaking is needed? ^^
[13:43] <petevg> achilleasa: the warning is a little unclear on the consequences. Will the endpoints show up as dupes, or not show up at all?
[13:44] <achilleasa> petevg: take a look at the end of the QA steps; basically, you will see them be removed and added
[13:46] <petevg> achilleasa: got it. I suggested a small change to the wording to reflect that.
[14:25] <achilleasa> hml: can you take a look at ^
[14:26] <hml> achilleasa:  i’m knee deep in other stuff… is there a time rush?  i can look later
[14:26] <achilleasa> hml: no but I was hoping to land this some time today so it's included in the next 2.7 sha
[14:27] <achilleasa> if you can take a look later and hit merge if it's ok that would be great
[14:28] <hml> achilleasa:  will do
[14:39] <stickupkid> I wish `juju upgrade-controller --build-agent` had a `--splat` flag, which would also update the one in the PATH
[21:31] <skay> postgresql charm question. I've changed the backup_dir setting, but the DUMP_DIR in the pg_backup_job script still points to the old setting
[21:32] <skay> shouldn't it change?
[21:48] <skay> aha. it might be a bug that was fixed and I haven't upgraded the charm