[13:14] <Code_Bleu> holman: 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:48] <esv> Code_Bleu, use per-boot script
[13:51] <esv> Code_Bleu, could you create the custom cloud.cfg file, create an image template and use that to make subsequent deployments?
[14:34] <holman> Code_Bleu: okay that should work 
[14:35] <holman> Code_Bleu: could you please share logs? 
[15:47] <Code_Bleu> holman: https://dpaste.com/4S869BB7G
[15:48] <Code_Bleu> holman: 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:49] <Code_Bleu> holman: We were originally doing something like this before that original PR I mentioned that meena submitted and was merged: if [ ! -L /run ]; then
[15:49] <Code_Bleu>    rm -rf /run
[15:49] <Code_Bleu>    ln -sf /var/run /run
[15:49] <Code_Bleu> fi
[16:03] <Code_Bleu> holman: 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:43] <Code_Bleu> holman: 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:44] <Code_Bleu> holman: https://dpaste.com/CMDWP7M2J
[19:16] <esv> Code_Bleu, /run and /var/run are RAM filesystems and regenerated with every boot
[21:12] <holman> Code_Bleu: oof, 140 is crazy
[21:12] <holman> Any idea what it is waiting on? 
[21:13] <holman> esv: i think you're missing some context
[21:15] <holmanb_> Code_Bleu: man 7 hier seems to imply that /var/run is the right spot
[21:15] <holmanb_> but I guess it doesn't explicitly say that it gets cleaned
[21:16] <esv> i realized a bit, trying to hide now.
[21:16] <holmanb_> all good :)
[21:17] <esv> :D
[21:17] <esv> still hiding 
[21:17] <holmanb_> Code_Bleu: but now I see this: https://lists.freebsd.org/pipermail/freebsd-stable/2016-August/085449.html
[21:17] <holmanb_> and it doesn't seem to have gone anywhere
[21:17] <holmanb_> bleh
[21:26] <holmanb_> Code_Bleu: which provider are you using again?
[21:46] <Code_Bleu> holmanb_: Cloudstack
[21:52] <holmanb_> Code_Bleu: gotcha
[21:52] <holmanb_> thanks
[21:53] <holmanb_> did you happen to grab ds-identify.log from the long boot?
[22:10] <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:37] <Code_Bleu> holmanb_: 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:38] <Code_Bleu> holmanb_: 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 changes
[22:47] <Code_Bleu> holmanb_: 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.md