[00:42] <wallyworld> kelvinliu: this PR is a follow up to the azure onefrom last week - the azure use-public-ip config is removed and a constraint is used instead https://github.com/juju/juju/pull/11974
[00:42] <kelvinliu> wallyworld: looking
[00:48] <kelvinliu> wallyworld: lgtm ty
[00:48] <wallyworld> tyvm
[08:22] <achilleasa> stickupkid: reminder for taking a look at https://github.com/juju/charm/pull/317
[10:23] <icey> anybody around for a Juju on OpenStack IPv6 question?
[10:29] <stickupkid> icey, what's the issue?
[10:30] <icey> stickupkid: all of the machines came up with a v4 and a v6 (dual stack ftw), Juju recognized this (and seems to always prefer ipv6 now?), at some later time, the interfaces lost their v6 addresses, rendering juju's connectivity information (juju status --format=yaml) incorrect as the machines no longer are addressable on ipv6
[10:31] <icey> there's no containers or anything so Juju's not changing things with bridges, I'm not honestly sure where to look
[10:34] <icey> it seems like it maybe dropped when adding the fan network ingerface?
[10:34] <icey> interface
[10:50] <stickupkid> icey, well offically we don't support v6, so I'm unsure what's happening about why we're always preferring that now...
[10:51] <stickupkid> icey, it's on our long term roadmap to support that
[10:51] <icey> https://pastebin.ubuntu.com/p/CwJdyYBv2t/
[10:51] <icey> stickupkid: every unit has it's ipv6 address there
[10:51] <icey> also happens with a dual stack MAAS
[10:53] <icey> stickupkid: the yaml format: https://pastebin.ubuntu.com/p/JHWCczzXFs/
[10:57] <stickupkid> icey, maybe jam might have some thoughts on it
[10:58] <icey> an annoying thing that juju's apparent ipv6 preference is that, when using libjuju, a unit's `.public_address` becomes the ipv6 address
[10:58] <stickupkid> oh really
[10:59] <icey> yup :)
[10:59] <icey> so I basically can't libjuju with my models that are deployed on a dual-stack OpenStack :)
[11:00] <icey> (using 2.8.1)
[11:00] <icey> I can try with 2.8.2 if that might change things
[11:01] <stickupkid> I'm unsure, manadart isn't around atm as he would be the best person to ask
[13:34] <jam> o/
[13:35] <jam> losing addresses is obviously going to be problematic for us, and it would certainly be good to understand how/why
[14:24] <achilleasa> jam: are you aware of anyone else importing bundlechanges? As part of my changes I want to emit multi-line descriptions for changes and I would prefer changing the interface signature to return []string instead of a single string with \n that the caller has to split/join
[14:25] <achilleasa> I could also add an "ItemizedDescription" method but if nothing else depends on the package I could just modify Description
[14:29] <jam> achilleasa, I'm not directly aware of it, but my exposure to that is relatively small at this point. Is it just something where we should rev the version of the module and make the changes?
[14:29] <jam> it certainly doesn't sound like a backwards compatible change
[14:30] <achilleasa> that's also an option. But if we are the only users of the package it would be fine
[14:30] <achilleasa> As stickupkid pointed out, this code should probably live in the juju tree anyway
[14:30] <jam> achilleasa, it sounds like a general "be good to your APIs" process, though.
[14:30] <achilleasa> ok, I will bump the version to be on the safe side