| TomD | Hello guys! I'm using VMware Aria Automation to deploy templates in on-prem vmware infra and I managed to successfully use cloud-init in all OS's but freebsd, for some reason freebsd doesn't mount cd0 so it doesn't see the ovf xml to select OVF DataSource, is there anyone here that can help me troubleshooting this? | 02:52 |
|---|---|---|
| === apollo13_ is now known as apollo13 | ||
| TomD | does anyone knows about freebsd+cloudinit? | 16:33 |
| Odd_Bloke | Hey folks, I'm having a bit of a hard time with the modules documentation page. I want to link people to a specific tabbed section (normally "Examples") but the tabs don't seem to be encoded in the URL when I click. Am I missing a trick? | 17:56 |
| Odd_Bloke | (I will also note that the page is harder to use as a reference since it moved to having tabs: I can no longer open the page, hit Ctrl-F and search for the config key I'm looking for.) | 17:59 |
| minimal | TomD: meena is the resident FreeBSD person | 18:37 |
| Odd_Bloke | Hmm, I think I've found another way in which passing `system_info` in vendor-data can't be exactly replaced by cloud-config. We currently configure default apt mirrors using `system_info`, which means that if a user provides a primary mirror via `apt:` in user-data then that mirror is used as both primary and security (i.e. all apt updates will come from there). If we use `apt:` in | 18:56 |
| Odd_Bloke | vendor-data to configure primary and security mirrors, then the user's primary mirror will override our primary, but our security mirror will remain in the configuration (i.e. only non-security updates will come from their configured mirror). | 18:57 |
| Odd_Bloke | (https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_apt_configure.py#L1050-L1071 is what governs the configure-security-as-primary-if-only-primary-specified behaviour.) | 18:58 |
| Odd_Bloke | Or maybe this isn't "another" way, as we've discussed previously, the default_user case can be covered with `user:`. :) I don't think we have an equivalent to `user:` for mirror configuration, though. | 19:02 |
| Odd_Bloke | (https://irclogs.ubuntu.com/2024/04/10/%23cloud-init.html#t18:40 is the previous conversation I'm referencing.) | 19:07 |
| falcojr | hey Odd_Bloke: for examples, we'll soon be having a different page highlighting all examples that can also be linked to: https://github.com/canonical/cloud-init/pull/5282 ...but that doesn't solve the ctrl-f piece. There's not a good solution for that atm but I understand the concern | 19:35 |
| -ubottu:#cloud-init- Pull 5282 in canonical/cloud-init "[docs] WIP - cloud config examples library" [Open] | 19:35 | |
| falcojr | If I'm understanding your system_info use case correctly, it feels more like a hack if I'm being honest. Users still *can* override that key. You're just relying on them not knowing about it and using the advertised user data key instead, correct? | 19:42 |
| minimal | falcojr: sounds more like an expectation that when at (at least some) sub keys of "apt:" are override that other keys of "apt:" should also be overriden (including with "blank" values when they're not present in user-data) | 19:45 |
| minimal | i.e. "apt:\n primary:\n" is being override from vendor-data by value in user-data | 19:45 |
| minimal | but "apt:\n security:\n" in vendor-data still exists because user-data didn't *explicitly* override it | 19:46 |
| falcojr | yeah, I think it's possible to include a merge strategy in your vendor data that would allow you to do that | 19:47 |
| minimal | seems like a wish to treat "primary:" and "security" as a "joined at the hip" set - if one is override then the other should be "blank" | 19:47 |
| falcojr | but in general merging and overriding are fraught with footguns the way it currently works. I'd really like to allow for completely separate applying of vendor data and user data, but that's a fairly large overhaul and not likely something I'll have time for soon | 19:48 |
| Odd_Bloke | If users want to override that key, I don't mind them doing that TBH. The issue is that there isn't a way we can modify our vendor-data such that users who are currently launching instances with primary-only `apt:` in user-data will continue to see the same behaviour. | 19:49 |
| Odd_Bloke | (And we're having users complain about our "invalid" vendor-data due to the schema validation errors now present in logs.) | 19:50 |
| falcojr | Odd_Bloke: file a bug with the specific keys. If we know of a use case we're likely to reconsider | 19:52 |
| Odd_Bloke | Cool, will do, thanks! | 19:52 |
| Odd_Bloke | (And, for clarity, I think the behaviour with `apt:` in vendor-data is preferable: users will get security.ubuntu.com configured for security updates unless they explicitly override it. But as we haven't been requiring users to explicitly override it thus far, we'd be introducing "new" behaviour by switching.) | 19:54 |
| Odd_Bloke | I've filed https://github.com/canonical/cloud-init/issues/5392 | 20:47 |
| -ubottu:#cloud-init- Issue 5392 in canonical/cloud-init "[enhancement]: cloud-init does not provide a schema-compliant way to retain current `system_info` `package_mirrors` behaviour" [Open] | 20:47 | |
| falcojr | thanks! | 20:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!