| 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:33 |
| 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:34 |
| meena0 | anyway, time to rework my roadmap. | 14:43 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| blackboxsw | parts of cmd.main, cloudinit/temp_utils.py and cloudinit/sources/helpers/azure.py | 19:39 |
| 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:42 |
| 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:55 |
| meena | if you put it on /run in BSD it means it's in / which means it's not ephemeral | 19:56 |
| 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:57 |
| 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. | 19:59 |
| 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:01 |
| 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:02 |
| 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:05 |
| 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:13 |
| 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:20 |
| 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:21 |
| 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:52 |
| 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:53 |
| blackboxsw | because ds-identify pre-checks environment variables DMI information kenv etc. and should correctly limit datasource_list to only viable datasources | 20:55 |
| meena | We don't have such a phase in rc, and we don't have an rc script for it either | 21:25 |
| meena | which datasource_list wins, btw? the one in /run, or the one I /etc? | 21:26 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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 | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!