[14:33] <holmanb> meena: regarding https://github.com/canonical/cloud-init/pull/2165#discussion_r1184320463 - you're welcome to make that change - it would probably make more sense as a separate PR though, so it's up to you
[14:33] -ubottu:#cloud-init- Pull 2165 in canonical/cloud-init "Ephemeral Networking for FreeBSD" [Open]
[14:33] <meena0> holmanb: let's get this merged, so I can get paid
[14:34] <holmanb> and as for the PR, I'll try to get in my review today
[14:34] <holmanb> meena0: sounds good
[14:34] <meena0> thanks
[14:43] <meena0> anyway, time to rework my roadmap.
[19:31] <blackboxsw> falcojr: holmanb are you seeing tox -re integraiton-tests fail locally? I think pytest 7.3.2 (released 6/10) now does something else funky with conftest path loading. for some reason it's loading test/unittests/conftest.py  during an `integration-tests` run 
[19:31] <blackboxsw> the result I see is a failure like this https://paste.ubuntu.com/p/RfCdbxtgGP/  also failing all our jenkins jobs
[19:32] <blackboxsw> we could express a dependency on "responses" in integration-tests.txt.... but that's not a real dependency in our integration tests....
[19:32] <blackboxsw> if I pin pytest=7.3.1 integration tests run fine
[19:33] <blackboxsw> I'm guessing it has something to do with https://github.com/pytest-dev/pytest/issues/10987
[19:33] -ubottu:#cloud-init- Issue 10987 in pytest-dev/pytest "`pytest_sessionstart` not run in custom test directories" [Closed]
[19:33] <meena0> how hard would it be to move cloud-init's /run to /var/run on *BSD? — on new installations
[19:35] <blackboxsw> meena0: I think there are probably quite a few unintentionally hard-coded place in cloud-init that may have needed to source global settings or the Paths object and don't.... hrm
[19:36] <blackboxsw> cloudinit/cmd/devel/logs.py for instance. ds-identify (not sure how we override that globally)
[19:36] <meena0> cloud-init is the only thing that writes to /run
[19:37] <blackboxsw> generally Paths.run_dir should be the place that gets setup globally for the top-level /run/cloud-init dir \.
[19:37] <blackboxsw> so in principal that should be it... but there are places which probably should have sources Paths and didn't
[19:39] <blackboxsw> parts of cmd.main, cloudinit/temp_utils.py and cloudinit/sources/helpers/azure.py
[19:42] <blackboxsw> but, it should be ephemeral and lost across instance reboot anyway.  Most consumers external shouldn't be using those files directly, but there's nothing saying they shouldn't either. I know of a couple of ubuntu packages that rely on seeing flat files in /run/cloud-init... but BSD-wise I think you are free to use a more appropriate directory
[19:55] <blackboxsw> I think the pytest issue also relates to the fact that we globally configure [pytest] testpaths  in our tox.ini and we don't specialize those paths down in tests/integration_tests.
[19:55] <meena> oooooooooof 
[19:56] <meena> if you put it on /run in BSD it means it's in / which means it's not ephemeral 
[19:57] <blackboxsw> so now pytest 7.3.2 actually honors our "tox-global" `[pytest]\ntestpaths = tests/unittests` and fails to load responses python module because our integration tests don't need it and hence don't express that dependency
[19:59] <blackboxsw> meena: per that case, I think cloud-init upstream doesn't treat those files as persistent for anything we store there.... The are used for most recent status due to last boot related to ds-identify, cloud-id detected, instance-data.json, status.json result.json details on the system.
[20:01] <blackboxsw> section 3.15 of filesystemheirarchy standard for linux https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf. Just pointing out that it's blown away per boot
[20:02] <blackboxsw> so I'd not worry about persisting that data across boot if you'd like to write it somewhere else that is ephemeral/variable for *BSD. I'd say move the old files to the new true ephemeral location if BSD has a concept.
[20:05] <meena> https://github.com/canonical/cloud-init/issues/4180
[20:05] -ubottu:#cloud-init- Issue 4180 in canonical/cloud-init "/run is not ephemeral on *BSD" [Open]
[20:05] <meena> So we don't ever read from run? only write? 
[20:13] <blackboxsw> meena: certain cloud-init cmdline tools read from /run/cloud-init (cloud-init status, cloud-init query etc ).
[20:13] <blackboxsw> most of the operations are a write-once type thing.
[20:13] <meena0> aye
[20:13] <meena0> So no drama
[20:20] <blackboxsw> meena: not too much. But agreed it's slightly different behavior on *BSD if /run is not cleared per boot. one thing to note as well is ds-identify (which limits datasource detection) emits /run/cloud-init/cloud.cfg to the discovered  datasource names which cloudinit python code will then source as the filtered list of viable datasources to check via the DataSource.get_data calls. 
[20:20] <blackboxsw> So, if that list is stale for some reason then cloud-init may not try to walk through all datasources to discover the right platform.
[20:21] <blackboxsw> It may be irrelevant to *BSD as I don't think you use ds-identify, but somethjing to be aware of if you are migrating that Paths.run_dir to something else
[20:21] <meena0> but ds-identify isn't run automatically?
[20:52] <blackboxsw> meena: on systemd-based systems it's automatically run at system generator timeframe https://www.freedesktop.org/software/systemd/man/systemd.generator.html on BSD I wasn't sure anything actually ran it. Do you know?
[20:53] <blackboxsw> that would have informed the review of https://github.com/canonical/cloud-init/pull/4159 I think.
[20:53] -ubottu:#cloud-init- Pull 4159 in canonical/cloud-init "BSD: remove datasource_list from cloud.cfg template" [Merged]
[20:53] <blackboxsw> as I would expect that this hardcoded datasource_list is not necessary if ds-identify is active in BSD-land somehow.
[20:55] <blackboxsw> because ds-identify pre-checks environment variables DMI information kenv etc. and should correctly limit datasource_list to only viable datasources
[21:25] <meena> We don't have such a phase in rc, and we don't have an rc script for it either
[21:26] <meena> which datasource_list wins, btw? the one in /run, or the one I /etc?
[23:44] <blackboxsw> meena: sorry got pulled away. datasource_list from ds-identify reduces the viable list from whatever was originally configured in /etc/cloud/*. If BSD had such an early RC trigger it'd save BSD a lot of time trying and rejecting the full list of all viable datasources as defined in /etc/cloud*.  Basically ds-identify reads /etc/cloud/* datasource_list, and does a quick inspection of DMI and kenv values.
[23:45] <blackboxsw> If any kenv values look like they may match then ds-identify keeps that datasource in the configured datasource_list all others which don't manifest in kenv/DMI attributes are filtered out so that the python code only calls the likely matched subset of datasource.
[23:46] <blackboxsw> if BSD images don't have a predefined shortlist in datasource_list config of /etc/cloud for a given cloud, this amounts to about 10 minutes of wait time on non-OpenStack platforms where OpenStack endpoints are retried for 10 minutes or something
[23:47] <blackboxsw> so when your 4159 PR dropped that shortlist config for datasource_list, it means it would be desireable for *BSD to trigger ds-identify in early boot before cloud-init 'init-local' RC script runs