=== harlowja is now known as harlowja_away [11:15] smoser: We've been asked to stop updating the hostname on reboot on Azure, but still set it at first boot (and when we bounce the connection). [11:15] smoser: We can do this using update_hostname; is there any way that cloud.cfg.d can stop update_hostname from running? [11:20] s/using/by disabling/ [12:39] Odd_Bloke, sure. you can remove it from the list of modules. [12:39] but i thought it should only do it if you had not changed it. === rangerpbzzzz is now known as rangerpb [13:24] smoser: This is the issue where Azure only want hostname set on first boot. [13:24] s/set/set to the value they provide/ [13:25] smoser: So update_hostname does explicitly the opposite of what Azure want. :p [13:28] smoser: So can I pop something off the cloud_init_modules list in cloud.cfg.d (or the data source?), or would I have to redefine the entire list? [13:28] (Or just modify cloud.cfg) [14:16] Odd_Bloke, you have to redefine the entire list. [14:16] Odd_Bloke, but above, only set to the value they provide on first boot. [14:17] i *think* htats the behavior you get. [14:17] ie, boot, changes from ubuntu to some azure-provided name [14:17] if the user modifies /etc/hostname subsequently, it shouldnt do this agian [14:17] as it checks to see if the previous version is different than the current [14:17] and if it is, then doesn't do it. [14:17] Hmm, I don't _think_ that's what I've been seeing. [14:18] But I might have been bitten by that race condition. [14:18] So I'll check again before I do anything else. [14:18] hm.. i dont see it either.. wher eis that.. i know i did that somewher.e [14:19] ah. update_hostname does that. but set_hostname does not. [14:20] update_hostname is PER_ALWAYS [14:20] set_hostname is PER_INSTANCE [14:37] https://bugs.launchpad.net/cloud-init/+bug/1424710 [14:37] is there anything I can do to actually get this patch applied? [14:42] devicenull: Lennert says that he worked around this problem by installing a different version of cloud-init; does that mean that this patch has been applied downstream in Fedora/EPEL? [14:43] I don't see any relevant patches in the epel rpm for this [14:47] hah [14:47] the epel rpm "works" because it doesn't know about centos 7 using systemd [14:47] so it falls back to the old working method [14:51] <3 [14:52] devicenull: Your best bet is probably to open up a merge proposal in to lp:cloud-init with your change as a commit. [14:53] ok [15:35] devicenull, yeah, open a MP. i can pull it fairly quickly as it looks sane. i'd *like* a non-name-based approach to "does this use systemd" [15:37] will do [19:48] arg, smoser stackforge cloud-init is behind like by 100+ patches :( [19:48] suck [19:48] *behind bzr [19:48] on the 0.7.x branch... [19:50] http://paste.ubuntu.com/10823678/ [19:50] poopy [19:50] * harlowja wonder how we can get all those in without 155 openstack reviews, lol [19:51] oddly not all 155 just cleanily apploy [19:51] *apply [19:51] which is weird [19:51] smoser how did u make https://github.com/cloud-init/cloud-init initially? [19:52] * harlowja doesn't make sense that those patches wouldn't apply (since they came from git<->bzr layer) [19:52] 0047-Remove-a-comment-turd.patch [19:52] lol [19:52] 0051-Remove-debugging-turd.patch [19:52] lol [19:53] i used bzr fast export / git fast import probably [19:53] hmmm, intersting [19:54] maybe i should try that vs https://github.com/felipec/git-remote-bzr (or simiar) [19:55] hmmm [20:02] weird, ya, still doesn't cleanly apply, oddness [20:03] http://paste.ubuntu.com/10823722/ seemingly weird that that happens at all... [20:05] yeah, that is odd [20:05] def === shardy is now known as shardy_z [21:52] actually, I'm looking at this again and I can't figure out how update_hostname is supposed to work [21:52] based on "LOG.debug("%s differs from %s, assuming user maintained hostname."," [21:53] I assume it's not supposed to update the hostname if it's different from what it expects (cloud-init set the hostname once, then the user changed it) [21:53] but that doesn't seem to be what the code does [21:53] is my assumption that it's not supposed to be overwriting user changes correct? === rangerpb is now known as rangerpbzzzz [22:09] user changes being something out of band updating the hostname? [22:09] i forget what the code is doing, but maybe is what u sy [22:09] *say [23:04] yea [23:05] it looks like a bug tbh, I'll be looking into it more tomorrow [23:27] k [23:49] smoser arg, got closer [23:49] http://paste.ubuntu.com/10824510/ [23:49] did we turn on the ccla check in that repo :-/ [23:49] or need other way to make it ignore the committer... [23:50] but nearly got it to work, ha