=== blackboxsw is now known as blackboxsw_away
[10:41] <aciba> meena: about the dict with repeated keys, I am not sure which will be the access pattern to the data-structure, but may this helps: https://docs.python.org/3/library/collections.html#collections.defaultdict
[10:41] <aciba> meena: using a defaultdict(list) and append elements to the same key
[12:15] <meena> aciba: to be honest, I'll need to see what the access pattern is myself, first, before tackling cjp256's duplicated MAC issue
[12:57] <meena> looking at patches that past me imported into this project i'm working on again and seriously questioning their competence.
[15:02] <itjamie> any chance for a review on https://github.com/canonical/cloud-init/pull/1808 this week?
[15:02] -ubottu:#cloud-init- Pull 1808 in canonical/cloud-init "Support string replacement for nocloud seed path" [Open]
=== blackboxsw_away is now known as blackboxsw
[15:15] <blackboxsw> itjamie: thanks for the ping. definitely going through that today, was dealing with a release upload for cloud-init 22.4 and now I'm free and focused on it.
[15:16] <blackboxsw> itjamie: thx for that PR by the way, I had wanted to pull something together in that space to improve our deployment strategy, I'll have a couple of thoughts for you today on it
[15:43] <minimal> blackboxsw: also wondering about related changes to the Phone Home module - thinking of auto-provisioning scenarios where you can to control both the user-data supplied (as itjamie's PR relates to) and also the end-of-cloud-init-run data sent by Phone Home module
[15:43] <minimal> BTW just saw the revised c-i ReadThe~Docs site and first thing struct me was a negative - the modules page now does not provide a list of modules at the top with links within the page to each individual module :-(
[15:45] <falcojr> minimal: That moved to the sidebar on the right, but I can see how that could less intuitive
[15:46] <minimal> falcojr: add didn't realise that was a "pop up" side, found it now via the icon
[16:16] <blackboxsw> minimal: thanks for that thought on Phone Home module. That would make sense too: parameterized URLs  based on DMI or sysfs data on the VM/system
[16:17] <blackboxsw> I'll try to keep that in mind with the review on PR 1808 to see if we might provide a common interface/function that could surface these parameterized values in a URL in a way that can be consumed my multiple config modules
[16:24] <itjamie> Parameterized urls would be a big change from the "folder" based urls currently used wouldnt it? Its why i didnt even attempt go that route
[16:25] <itjamie> Since right now urls in seedfrom must end in / and then it appends each filename. Changing that to param based would seem like a breaking change...
[16:27] <itjamie> a middleground could be to supply all the dmi data as headers... that wouldnt change the existing url structure
[17:06] <minimal> blackbowsw: yeah i'm thinking of a feedback loop - dynamic user-data for bootstrap and then possibilty some more info than currently provided by Phone Home to confirm the end result of bootstrapping
[17:10] <blackboxsw> itjamie: I think providing headers may be an interesting/compelling use-case too from cc_phone_home. What I meant was a simplistic url processing from cc_phone_home's 'url' config to allow variable substitution in the `url:` config that cc_phone_home talks to. 
[17:11] <blackboxsw> something like `url:  http://example.com/{sys.chassis_serial}/`
[17:12] <itjamie> Thats separate from the nocloud methods though right?  I personally want to continue to use seedfrom but with a bit of url processing
[17:12] <blackboxsw> minimal/itjamie: sounds like you are thinking a bit more like supplemental POST data based on certain keys ?
[17:14] <blackboxsw> itjamie: yes I agree that sentiment is separate, but I was confining my ideal so something that just generacally handles uniform URL string processing with a supoort template/variable syntax that can source /sys/class/dmi/id/* fields which I think will help your seedfrom URL cause and could be leveraged in other places if we don't define it strictly in a  function insie DataSourceNoCloud.py. 
[17:15] <minimal> blackboxsw: I don't have any firm data in mind currently
[17:15] <itjamie> Makes sense
[17:15] <blackboxsw> itjamie: BTW I'm hoping to also povide you w/ skeletal unittest coverage w/ a review today on this to help grease the wheels a bit
[17:15] <blackboxsw> lotsa meetings today, so the review probably won't be done for a couple hours.
[17:18] <blackboxsw> community-notce: upstream release 22.4 has been published https://github.com/canonical/cloud-init/releases/tag/22.4
[17:19] <blackboxsw> community-notice: Also Ubuntu has uploaded StableUpstreamReleases of 22.4 into the (kinetic|jammy|focal|bionic)-proposed pockets for testing and verification this week. If you are interested in testing behavior of 22.4 on your cloud of choice: please see https://cloudinit.readthedocs.io/en/latest/topics/debugging.html#manual-sru-verification-procedure
[17:20] <blackboxsw> community-notice: Thanks falcojr for driving the release, to see the content/features and fixes in 22.4 checkout James' post at https://discourse.ubuntu.com/t/release-of-cloud-init-22-4/32265
=== blackboxsw changed the topic of #cloud-init to: 22.4 Released! 11/16 | Bugs: https://bugs.launchpad.net/cloud-init/+filebug | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
=== blackboxsw changed the topic of #cloud-init to: 22.4 Released! 11/15 | Bugs: https://bugs.launchpad.net/cloud-init/+filebug | PRs: https://git.io/JeVed | release schedule: https://discourse.ubuntu.com/t/cloud-init-2022-release-schedule/25413
[17:47] <holmanb> AnhVoMSFT: Do we have any ideas how this behavior might be similar/different on the BSDs? I see https://www.freebsd.org/cgi/man.cgi?query=hv_netvsc&sektion=4
[17:52] <holmanb> AnhVoMSFT: A retry loop with a small delay before continuing sounds pretty awful, but since dup macs is currently a failure path anyways, the only delay it would cause is a delay before throwing an exception that stops cloud-init.
[17:55] <holmanb> meena: I meant to ping you as well on the bsd question a moment ago, so uh, ping?
[17:57] <holmanb> AnhVoMSFT cjp256: Adding driver-specific logic to that would help us to fail a little bit faster in some cases. Since this failure ends in an unconfigured system anyways, I wonder whether the added complexity of keying off a driver is worth it.
[18:28] <atmark> hello, I have OpenStack VM instance running and tried to modify the metadata for the instance. The VM will never show the updated metadata. I can pull the current metadata from the OpenStack API inside the VM but the other sources such as ConfigDrive will not update. Is there way to avoid re-deploying the VM to see the updated metadata?
=== smoser1 is now known as smoser
[18:57] <falcojr> atmark: is the updated metadata reflected if you query the metadata URL directly? If not, there's nothing cloud-init can do about that. If so, you can run 'cloud-init clean' to force cloud-init to re-fetch the metadata on next boot
[18:58] <falcojr> same if it's exposed through a config drive. If the files on mount aren't updated, I don't think there's anything cloud-init can do about that
[19:19] <meena> holmanb, AnhVoMSFT , I would have to spin up a server in Azure to test, and/or read source code
[20:50] <AnhVoMSFT> holmanb meena: https://github.com/canonical/cloud-init/pull/1853
[20:50] -ubottu:#cloud-init- Pull 1853 in canonical/cloud-init "net: skip duplicate mac check for netvsc nic and its VF" [Open]
[23:18] <minimal> a question about network v2, with #1794 merged the docs now say that gateway4 and gateway6 are deprecated. So in a static config how then should a default gateway be specified? via "routes:" ?