[08:06] hello there, i'd have a few questions regarding how and where to place some user-data that should be run once only, on the first boot, and as early as possible, but after network, in order to reconfigure some database entries that contain IP addresses === hjensas is now known as hjensas|afk === hjensas|afk is now known as hjensas [16:09] Does anyone know why execution order is per-once, per-instance, per-boot? I would have expected decreasing frequency, or at least according to frequency in any order. Not most-least-middle. Thanks! [16:10] Btw I'm going according to the /etc/cloud/cloud.cfg on my EC2 VM, as well as what I'm seeing in my log. [16:11] beantaxi:i'm confused. [16:11] per-once : frequency == 1 [16:12] per-instance: frequency = N, where N is the number of instances [16:12] per-boot: frequency = N + B (b number of boots) [16:12] so it is in increasing order of frequency, not most-least-middle [16:16] Ah sorry, I typed that wrong. [16:17] The above would be great ... but it's actually once - boot - instance. That is what I meant to type. My apologies. [16:20] https://pastebin.com/uPpErqJE [17:28] is the 20.4 SRU in xenial/bionic -proposed yet? [17:28] I mean 20.3 [17:29] yes, you can always check https://launchpad.net/ubuntu/+source/cloud-init [17:30] or run `rmadison cloud-init` on ubuntu systems [17:31] AnhVoMSFT: right, and falcojr3 has begun SRU testing. we're expecting to blitz a lot of that SRU validation tomorrow [17:31] Thanks @powersj @blackboxsw [17:38] AnhVoMSFT: I'm currently running 20.3 from bionic-proposed. So far so good. [19:24] smoser: So if I set "manual_cache_clean: true" in user-data I'm passing to a lxd container, am I right in thinking that I should be able to unset this just by removing /var/lib/cloud/instance/manual-clean? (I've also modified the user-data and meta-data in the seed directory to (a) not set manual_cache_clean any longer, and (b) present a different instance ID.) [19:24] Or am I missing a step? [19:26] (I think I might be seeing a bug, but as I'm writing the documentation to follow, I can't be sure. :p) [19:33] well, assuming you otherwised cleaned up correctly, yes i think so. [20:34] smoser: Yep, there's a problem: if you pass `manual_cache_clean: True` in, then it will persist forever (even if you remove that file, it will be replaced on next boot). We write the user-data from the first boot to /var/lib/cloud/instance/cloud-config.txt and on subsequent boots we read that file as part of our `Init.cfg` _before_ determining whether or not this is a new instance. This means that the [20:34] configuration we use at runtime includes manual_cache_clean (even though the seed directory indicates this is a first boot, and its user-data does not include it), so we will always be in `trust` rather than `check` on that instance. [20:34] (I'll file a bug with more details, this might be inscrutable if you haven't spent several hours staring at this code. :p) [20:35] well, thats righ though [20:36] its trusting cached data [20:36] that was the poitn [20:37] but i think if you removed that file (manual_cache_clean) then ds-identify will re-run. [20:51] The problem is it's loading the cached data, then using that cached data to determine whether or not it should trust the cached data. [20:52] Odd_Bloke:its "manual cache clean" [20:52] *manual* [20:52] OK, but you said that removing /var/lib/cloud/instance/manual-clean should be sufficient? [20:53] And it isn't, because the presence of that is ignored if manual_cache_clean is set to True in the cached data. [20:53] So... "unfreeze", if manual_cache_clean was set is just: [20:53] rm -Rf /var/lib/cloud/instance /var/lib/cloud/instance/ [20:55] i think you can probably get away with just the link. [20:55] OK, right, so it isn't the case that "I should be able to unset this just by removing /var/lib/cloud/instance/manual-clean"? I'm just trying to make sure that I understand what's going on here.