/srv/irclogs.ubuntu.com/2024/03/06/#cloud-init.txt

Code_Bleuholman: I do have the set_hostname, set_password and runcmd to be set to always ( ie. [set_hostname, always] ) that is in the /etc/cloud/cloud.cfg that was generated after the install.  I can do a cloud-init clean and reboot and that works, but we need a solution to not have to manually run the cloud-init clean.13:14
esvCode_Bleu, use per-boot script13:48
esvCode_Bleu, could you create the custom cloud.cfg file, create an image template and use that to make subsequent deployments?13:51
holmanCode_Bleu: okay that should work 14:34
holmanCode_Bleu: could you please share logs? 14:35
Code_Bleuholman: https://dpaste.com/4S869BB7G15:47
Code_Bleuholman: I do not believe the issue is with the script actualy working, but the fact that it's storing the data on a mount that is not being cleared on reboot..when it should.15:48
Code_Bleuholman: We were originally doing something like this before that original PR I mentioned that meena submitted and was merged: if [ ! -L /run ]; then15:49
Code_Bleu   rm -rf /run15:49
Code_Bleu   ln -sf /var/run /run15:49
Code_Bleufi15:49
Code_Bleuholman: however even adding the above to the /etc/rc.local file does not resolve the issue.  Only running the 'cloud-init clean' (so far) is allowing it to pick up the new settings.16:03
Code_Bleuholman: I put the symlink stuff back (prob not needed) and added the 2 rm -f commands to remove the instance data stuff. (prob why it works now) and I commented out the ds-identify and specified my provider directly in the cloud.cfg ( because it was taking over 140 secs!! to detect my provider )16:43
Code_Bleuholman: https://dpaste.com/CMDWP7M2J16:44
esvCode_Bleu, /run and /var/run are RAM filesystems and regenerated with every boot19:16
holmanCode_Bleu: oof, 140 is crazy21:12
holmanAny idea what it is waiting on? 21:12
holmanesv: i think you're missing some context21:13
holmanb_Code_Bleu: man 7 hier seems to imply that /var/run is the right spot21:15
holmanb_but I guess it doesn't explicitly say that it gets cleaned21:15
esvi realized a bit, trying to hide now.21:16
holmanb_all good :)21:16
esv:D21:17
esvstill hiding 21:17
holmanb_Code_Bleu: but now I see this: https://lists.freebsd.org/pipermail/freebsd-stable/2016-August/085449.html21:17
holmanb_and it doesn't seem to have gone anywhere21:17
holmanb_bleh21:17
holmanb_Code_Bleu: which provider are you using again?21:26
Code_Bleuholmanb_: Cloudstack21:46
holmanb_Code_Bleu: gotcha21:52
holmanb_thanks21:52
holmanb_did you happen to grab ds-identify.log from the long boot?21:53
holmanb_Code_Bleu: would you mind filing a bug report for this with details? I'd like to get this ironed out, but meena isn't here now and I don't have access to cloudstack to test it 22:10
Code_Bleuholmanb_: I don't think I have that log for the long boot. Right now, that isn't too big of a deal for me, because i just specified it directly.  My main issue is being able to have it properly update when i change the hostname, password..etc.  22:37
Code_Bleuholmanb_: as you hopefully saw earlier, I was able to get it to work by having the instance files in /var/run be deleted in the rc.local file.  So now when it reboots, it is able to detect the changes22:38
Code_Bleuholmanb_: I'm not sure how quick I can get to filing a decent bug report for this, but I'd recommend you look at this to test Cloudstack environment.  It is really really simple to spin up a local dev environment to test with. - https://github.com/apache/cloudstack/blob/main/tools/docker/README.md22:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!