=== rangerpb is now known as rangerpbzzzz [02:06] harlowja, i'd appreciate a look at https://code.launchpad.net/~smoser/cloud-init/trunk.lp1602373/+merge/300021 [02:06] and rharper ^ you too [02:53] and then, since you're clearly looking for something to do, [02:53] https://code.launchpad.net/~smoser/cloud-init/trunk.net-improve-lo-dns/+merge/298035 [02:59] rharper, fyi, this is what our openstack (serverstack) ends up readnering in /etc/network//interfaces.d/50-cloud-init.cfg [02:59] http://paste.ubuntu.com/19331646/ [02:59] it has the 'dhcp' and dns-addresses [03:00] i think that is in the realm of funky behavior [03:01] resolvconf seems to be ok i geuss. so maybe nevermind. === rangerpbzzzz is now known as rangerpb [13:48] smoser: re: server stack; it's setting a global dns service entry in network_data.json as well as marking the interface as configured via DHCP; Those aren't necessarily at odds; the DHCP response might not include a nameserver; or even the same ones. I don't think we know enough to not emit a global dns entry if one or more of the interfaces is also dhcp; [13:50] right. [13:51] its not really at odds, but it is pointless. i thought we (and resolvconf) might end up adding 2 dns servers of the same, or otherwise getting confused. [13:52] i was thinking it might be like our race [13:52] with the routes [14:12] not sure that it's pointless; resolveconf should collect as many values and collect them [14:12] no different than hooks in resolveconf.d [14:12] which can add additional values [14:13] in serverstack case, its setting a global value, and the DHCP response may include more [14:14] I'd think it'd rather be on the openstack side to decide to emit dns_nameserver under the 'services' section or not depending on the type of network being deployed === dmsimard is now known as dmsimard|afk === dmsimard|afk is now known as dmsimard [17:33] smoser will check that out [17:33] i've got a big godaddy module for cloudinit i'm working on [17:33] i'll share it with u guys, it probably has some things that can be made generic for all folks [17:34] but its a refactoring of things they were doing on firstboot via some non-cloud-init local triggering of puppet from a git repo and ... [17:38] which is duping some of cloud-init and ... [17:38] so i'm just fixing that, lol [17:53] hey harlowja smoser suggested i follow up with you on a python related question/problem if you have a sec [17:54] pertains to -> http://bazaar.launchpad.net/~bbaude/cloud-init/azure_dhcp/view/head:/setup.py#L214 [17:55] harlowja, smoser and i are curious if there is a way to change the install dir where line 217 ends up [18:00] smoser suggested me :-P [18:00] yeah, guilty as charged [18:00] ah, hmmm [18:00] good question [18:00] basically we'd like that line 217 to not end up /usr/bin [18:01] ya, i wonder if there is a way [18:01] i don't know one off the top of my head [18:01] but there probably is [18:01] i havent been able to find anything either [18:02] if u want, can u jump on #openstack-oslo [18:02] lifeless (who is in NZ) has a bunch of knowledge about this stuff [18:02] he might know a way [18:03] smoser, ill pursue that ... what do you want to do in the interim ? [18:05] harlowja, would there be some way to just move files after setup.py ran ? [18:05] mv? [18:05] ie, just hackily mv ./usr/bin/that-file ./usr/lib/cloud-init/other-file [18:06] well, withink the context of setup.py thugh, but outside the context of entry points [18:07] gotta be some way here [18:10] did u guys try --install-scripts [18:10] python setup install --help [18:10] shows that might work? [18:13] i think the rub is he wants cloud-init into /usr/bin but not others [18:13] hmmm [18:14] well thats weird [18:14] lol [18:14] smoser might be crzy [18:14] lol [18:14] we are trying to avoid flooding /usr/bin but like the benefit the entry_point provides as it injects the right python version, etc [18:16] rangerpb's other idea was to have cloud-init dhclient-hook [18:16] which i'm not really opposed to. [18:16] and then its '--help' can even say "you probably dont want to call this" [18:17] harlowja, is there a way to replicate the entry point upside but not call it out as an entry_point in setup.py ? [18:18] not sure [18:19] this is in setuptools/easy_install and all that which i don't know to much about how it works :-P [18:20] u may find some folks in #pypa (the pip people who also do setuptools and stuff afaik are in here) [18:20] harlowja, thats why we have you here. [18:20] this gets into there territory, lol [18:20] ha [18:20] if people ask me a question, they expect me to say 'go ask someone more knowledgeable' [18:21] but when they then ask you, you're supposed to know. [18:21] delegation is key, ha [18:21] i delegate to :-P [18:21] pypa folks though should really know [18:21] i'm just a country-bumpkin who doesn't know anything [18:21] lol [21:08] smoser https://gist.github.com/harlowja/781a010bbe2634982dbb0878982852bc if u get bored [21:08] https://gist.github.com/harlowja/781a010bbe2634982dbb0878982852bc#file-cc_godaddy-py-L733 [21:08] the submodule idea there would be nice to offically support [21:14] i'm also seeing https://gist.github.com/harlowja/41d557bb2c9dbd38a1c3c75bd834a0b6 :-/ [21:15] which seems odd [21:15] `chunk_size=1024` is the default [21:15] unsure why that would be invalid, lol [21:21] thats during reading '/sys/class/net/eth0/carrier'