[08:42] <kholkina> dpb1 hi! do you know an answer for my question published yesterday?
[08:43] <kholkina> cannot find full logs for this channel
[10:22] <dpb1> kholkina: perhaps in a few more hours.  yesterday was a US holiday, most of the contributers were off.
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
[14:16] <rharper> kholkina: w.r.t user-data; cloud-init does not currently watch the metadata url for changes.  Unless your instance-id changes, cloud-init does not re-read the metadata and take action.   Adding a scripts_user/always won't help if cloud-init has already booted and initialized the instance.   Do you have any background on what you're trying to do?
[14:23] <kholkina> rharper: I want to have an ability to get (and execute) updated userdata on instance reboot. What is the better way to do this?
[14:23] <rharper> just a single key or you really want the whole instance to be reconfigured; I don't know all of what you have in your user-data
[14:25] <rharper> any background about the data change? are you adding a user or installing a package; things that cloud-init normally does during boot?
[14:25] <kholkina> just a single key in the section 'cloud-config'
[14:26] <kholkina> now I'm trying to manipulate ssh-keys
[14:28] <rharper> looking to add a key, or modify existing ones?
[14:29] <smoser> other question is "host" or "user/public" keys
[14:29] <kholkina> modify keys in 'default_user/.ssh/authorized_keys'
[14:33] <smoser> kholkina: right. so for now, cloud-init will only do that once per instance. you could possibly change something to make it do it every boot, but it really only appends keys.
[14:39] <kholkina> smoser: Yes, I've found that it's possible only to add new keys on reboot. But I need to delete some files from /var/lib/cloud to do this. So would be nice if you can suggest better solution to get an updated data
[14:41] <smoser> kholkina: well, you could change the frequency of 'ssh' config module
[14:41] <smoser> but doing so would have the unwanted side affect of re-generating ssh keys for the host
[14:43] <smoser> kholkina: i dont have a good suggesiton for you at the moment. :-(
[14:43] <smoser> we do plan to make cloud-init more dynamic in this regard, but nothing right now/
[14:43] <smoser> what cloud is this?
[14:44] <kholkina> openstack
[14:48] <smoser> yeah, k'm sorry. i dont have a good answer for you. :-(
[14:49] <kholkina> do I need to remove a cache or it will work just with [ssh, always] in cloud.cfg?
[14:51] <rharper> I kind of think that you don't want to have it regen the host keys;  might be better to watch the metadata URL yourself and read-and-apply the change outside of cloud-init for now
[14:53] <rharper> smoser: for cached openstack, re-invoking cloud-init single wouldn't have it re-read metadata URL would it?
[14:53] <smoser> no, it wont.
[14:54] <rharper> if you removed the obj cache, it might, right ?
[14:54] <smoser> well, but then it would probably mostly think it was a new isntance.
[14:54] <rharper> hrm, yeah
[14:54] <smoser> an dif that wasnt the behavior it did have, then i wouldnt want to tell someone to rely on that
[14:55] <rharper> yeah
[20:20] <dojordan> @blackboxsw - question about the dhcp-discovery. I am getting a permission denied on the temp dir in /run/cloud-init when calling dhclient, but there is a comment in the method saying to use /var/tmp since /run/cloud-init is mounted noexcec... Not really sure why its using the wrong directory: Command: ['/run/cloud-init/tmp/cloud-init-dhcp-zz0g2p4_/dhclient', '-1', '-v', '-lf', '/run/cloud-init/tmp/cloud-init-dhcp-zz0g2p4_/dhc
[20:20] <meetingology> dojordan: Error: Missing "]".  You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands.
[20:27] <rharper> wow, uhm, thanks? meetingology ?
[20:27] <nacc> rharper: did someone forget to stop a meeting?
[20:27] <rharper> possibly
[20:27] <rharper> that'd be blackboxsw
[20:27]  * nacc thought the bot didn't listen outside of meetings
[20:27] <nacc> #endmeeting
[20:28]  * nacc may not have perm if they didn't start it
[20:28] <rharper> right
[20:28] <rharper> I think blackboxsw might need to do that
[20:28] <rharper> prolly forgot since open hours last week, I suspect
[20:28] <nacc> although i thought the bot changed the topic too, but maybe i'm wrong
[20:28] <nacc> yeah, likely
[20:28] <rharper> yeah, this is the same instance as the other ubuntu channels, so maybe blackboxsw has it tweaked some
[21:41] <dojordan> dumb question, but cloud-init runs as root, correct? if so, how come when mkdtemp runs as root it returns /run/cloud-init even though it is mounted noexec?
[21:50] <rharper> dojordan: two things going on;  1) systemd makes /tmp and /var/tmp unusable as the systemd tmp cleaning service can nuke those at any time; so cloud-init moved it's "tmp" space under a path cloud-init owns (/run/cloud-init)  2)  specifically around the dhclient and tmp dirs is related to apparmor policy around dhclient
[21:52] <dojordan> 2) makes sense, and I believe I am running into that. However, the temp_utils.py:_tempfile_dir_arg first checks if _TMPDIR has already been set and if so returns it
[21:52] <dojordan> therefore it does not honor the needs_exe if it is not the first invocation of the function, right?
[21:53] <rharper> lemme look at the code
[21:53] <rharper> oh, I see
[21:54] <rharper> if a non-exec user  calls it first, the second caller cannot reset it
[21:54] <rharper> that's bit naughtly;
[21:55] <rharper> well, one hammer is to fetch the global and reset _TMPDIR = None to recall it; but that seems wrong
[21:55] <dojordan> what's the point of the global
[21:55] <rharper> makes a singleton
[21:55] <dojordan> maybe im missing something
[21:55] <rharper> once we've figured out a TMPDIR, we just keep reusing it
[21:55] <rharper> we don't need a per-call different tmp directory
[21:56] <rharper> just need to find one tmpdir with the required features and they all callers use that one
[21:56] <dojordan> unless we have an needs_exe=False then needs_exe=True
[21:57] <rharper> yeah, that seems like an issue; I suspect if your datasource is not running local, it's request to have a  tmpdir with needs_exec set isn't the first one; it seems like trouble to re-issue on (if it's currently non-empty)
[21:58] <rharper> since the EC2 datasource was moved to run at localtime, it is likely a first user of that and gets to set the needs_exec=True first;
[21:58] <dojordan> what's weird is it is running local but i guess there must be an earlier call still
[21:59] <rharper> it seems so
[22:00] <rharper> azure's OpenSSLManager uses mkdtmp
[22:00] <dojordan> yup, just found that
[22:02] <dojordan> thoughts on best fix? one option is looks at needs_exe first. If it is true then just use the _EXE_ROOT_TMPDIR
[22:03] <rharper> I'm not sure yet
[22:03] <rharper> that's one way; but I
[22:03] <rharper> I
[22:03] <rharper> bah
[22:03] <rharper> I
[22:04] <dojordan> haha
[22:04] <rharper> i'm somewhat concerned with changing the global if the dir is populated;
[22:04] <dojordan> my thought was not to change the global
[22:04] <dojordan> since the _EXE_ROOT_TMPDIR is static anyway
[22:04] <rharper> right; one could just return the different directory (assuming it exists)
[22:05] <rharper> not clear if that could cause confusion w.r.t where a callers files are
[22:08] <dojordan> but the only way to guarantee one directory then is always use the exe root one, which seems wrong too
[22:09] <blackboxsw> #endmeeting
[22:09] <rharper> yay blackboxsw has returned
[22:10] <blackboxsw> sorry was afk for a kiddo dr checkup. reading scroll back
[22:10] <rharper> dojordan: I *think* it could be OK for the root case to use the need_exec to pick the path it returns, despite what's set in the global
[22:10] <blackboxsw> but looks like endmeeting didn't close anything ( and I thought Ihad already posted the closing logs from last meeting last week at cloud-init.github.io
[22:11] <rharper> blackboxsw: yeah, no idea; maybe meetingology just needs a kick in the pid
[22:12] <blackboxsw> will ping in #meetingology channel on that, not sure why it responded to that earlier message, all cmds should start with a #
[22:13] <rharper> hehe
[22:15] <blackboxsw> testing in a side channel, any command that starts with @ also seems to get parsed by meetinology
[22:20] <rharper> hehe
[23:19] <dojordan> @blackboxsw, I am testing out the ephemeral ipv4 stuff now, but for some reason broadcast address is not in the lease file. any thoughts?
[23:27] <rharper> dojordan: is the netmask included? if so you can derive broadcast IIRC
[23:28] <dojordan> okay cool. that was my backup plan :)
[23:29] <dojordan> do I apply the mask to the fixed address or the router to get the broadcast address?
[23:29] <dojordan> i guess fixed is probably more reliable
[23:33] <blackboxsw> hrm, I thought we had a helper function for deriving that broadcast addr
[23:33] <blackboxsw> :w
[23:34]  * blackboxsw checks around
[23:40] <blackboxsw> nah was net_prefix_to_ipv4_mask and it's ilk in cloudinit/net/network_state.py
[23:40] <blackboxsw> I thought I saw a discussion on one branch that discussed potentially writing a utility to do that calculation.
[23:42] <blackboxsw> if a helper function is writting dojordan to calculate broadcast, I guess I'd like to see if live in cloudinit/net/network_state.py like the other net-related helper funcs
[23:43] <blackboxsw> if a helper function is written*
[23:52] <dojordan> cool, i'll put it there