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