=== shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [12:48] harlowja, thank you. [12:49] harlowja, you can see things for proposed merge into cloud-init's git trunk this way... [12:50] all the cloud-init repos that launchpad knows about (~user/cloud-init) are viewable at https://code.launchpad.net/cloud-init [12:51] lp:cloud-init (aka ~cloud-init-dev/cloud-init) git repo is at https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init [12:51] a list of all cloud-init-dev's cloud-init branches can be seen here [12:51] https://code.launchpad.net/~cloud-init-dev/cloud-init/ [12:51] the 'master' branch https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master [12:51] and that has 'Branch merges' "7 branches proposed for merging into this one" [12:52] which points https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master/+activereviews [12:52] all of that is navigatable but sometimes non-obvious [12:52] s/sometimes/ === contrapumpkin is now known as copumpkin === rangerpbzzzz is now known as rangerpb [13:59] larsks, around ? [13:59] Sort of :) Phone meeting. I saw your changes; hope to look at that this afternoon. [14:01] larsks, alternatively if you can tell me how to test that i did not break your work with bdrpm i'd just merge === rangerpb is now known as rangerpbzzzz [16:23] larsks, ok. so i think i'm going to just pull my changes. [16:23] brpm works for me as via: [16:23] http://paste.ubuntu.com/21909186/ [16:23] smoser: okay. totally going to look at things this afternoon; yesterday was just busy :) [16:23] larsks, i understand not geting aroudn to things. [16:23] But if it works for you that is probably the best test. [16:23] you have been a big help. thank you. [16:24] see that paste there, i built successfully with rpmbuild [16:24] your repo needs to get tags ro 'git describe' doesnt work [16:24] and i thikn your repo needs new repo basically (since i re-imported) [16:24] end result though, trunk should bddeb and brpm shortly [16:25] I think the existing code is post-your-re-import. But yeah, may be missing tags. [16:27] yeah, just missing tags then. [16:27] that makes more sense. [16:29] rharper, powersj harlowja ^ above paste points to building cloud-init in an centos7 lxc. [16:30] there are some less-than-ideals there (i had to copy the list of rpms to install rather than using something in trunk to generate it) and i the script assumes it has to branch a remote repo, but generally did work. [17:22] smoser: what's with the ssh stuff in the build env? [17:24] it's a builder script? [17:24] whats up [17:25] i like building things :-P [17:25] now just need to see if lxc is on our build slaves, lol [17:25] larsks is it prefered to use lxc, or use the mock thing i was reading about [17:25] https://fedoraproject.org/wiki/Mock [17:25] mock is generally what people use for building packages in pristine environments. [17:26] is that like glacial sprint pristine? [17:26] *glacial spring [17:26] or like my local pond pristine [17:26] lol [17:26] Oh, maybe, you had me confused for a minute. [17:26] the above is just messing around [17:26] lol [17:27] (well the mock question isn't) [17:27] but the spring part is [17:28] I had figured that out, but thanks :) [17:29] * rharper enjoys the artic air during his sprints === rangerpbzzzz is now known as rangerpb [17:29] lol [17:31] harlowja: incidentally, you'll note that brpm now has a --srpm option which will *just* build a source rpm, which you can then hand off to mock. [17:32] cool [17:32] gotta get my jenkins build scripts up to date to try some of this [17:32] * harlowja has been recently messing with http://docs.openstack.org/infra/jenkins-job-builder/ [17:33] and getting the CI guy onboard with using that [17:33] smoser, hey around? i was talking with larsks about the problem with entry_points, bloating /usr/bin/, and fully qualified path names to executables .. he had a nice idea where instead of using entry_point, the scripts call python -m instead [17:34] it is a good compromise, the only downside is the python version is not figured out like it is with entry_point [17:35] rangerpb, right. and that is fine. [17:35] except... [17:35] which python do you call ? [17:36] python2 or python3 [17:36] well exactly .. thats the point I was bringing up [17:36] maybe its easier to come up with that. [17:36] i was thinking so ... but this is new territory for me as well [17:37] i did see python version is determined in the make file [18:05] hey harlowja are you aware of a way that setup.py could be used to replace a variable in a file prior to install ? [18:05] nope :-/ [18:06] how about running a command which in turn could do that? [19:07] larsks, smoser http://bazaar.launchpad.net/~bbaude/cloud-init/azure_dhcp/revision/1253 <-- how much does that make you throwup in your mouth? [19:09] rangerpb: yuuuuuuck. So, for the record: I think that templating the hook scripts seems unnecessary. I think we should trust the Python installer to put scripts where they will be in $PATH, and then just call them with an unqualified name. If someone *really* wants to override things by mucking about with $PATH, more power to them! [19:09] that dhclient hooks is *such* a crap interface [19:09] I mean, we trust it to put cloud-init in the right place... [19:10] smoser, i dont follow.. [19:10] larsks, thats not it though.. [19:10] the template is needed to get the right python binary [19:10] either python2 or python3 [19:10] as it is now. [19:10] It's not, in fact; this was all rangerpb trying to work around a prior requirement :) [19:11] I think we should just replace the call to '$PYTHON ...' in the hook scripts with 'cloudinit-dhclient-hook', no full path, and it all becomes much easier. [19:11] so, yes. anoterh alternative is to put a easyinstall program into /usr/bin/ [19:11] there we are couple of pieces to it. the right version, the right binary, the right install path [19:11] Which is exactly where console_scripts entrypoints get placed. [19:11] except then you have a crappy program that is not a user executable in /usr/bin/ [19:11] thats what i didn't like. [19:12] I guess. It seems like a lot of effort to work around it. [19:12] i'm polluting /usr/bin/ and destroying tab completion for cloud-init with some sillyness. [19:12] You have the cloudinit-dhclient-hook script bail out with an error message if called without the appropriate environment. [19:12] s/have/could have/ [19:13] the right place for 'cloud-inti-dhclient-hooks' is /usr/lib/cloud-init/ [19:13] which isn't going to be in a PATH (and for good reason) [19:13] The alternative -- which is my preference -- is to leave installation of the hook scripts up to the package. I know we've talked about this before, but I don't generally expect my setup.py to be setting up init scripts etc. for me. [19:13] The right place for the hook helper is probably distribution dependent. [19:13] sure. [19:13] but not in $PATH [19:13] (which is why I think it's a packaging issue) [19:14] and that is reasonable. [19:14] but then later on i break you, because your dealing with that now has to deal with a change we made upstream. [19:14] we're trying to make setup.py do the right thing. [19:15] i think the link there is pretty good. [19:15] I understand your goal, but I think that trying to turn setup.py into a multi-distribution system configuration tool is the wrong place to put our effort. [19:15] wait ... smoser did you think what I did was somewhat ok ? [19:15] not really a system configuration tool. just an install tool. [19:16] i know its a pain. [19:16] Well, setting up init/systemd/etc...I think of that more as system config. [19:16] i dont know what other things do here. [19:17] i generally agree, but cloud-init kind of has more involved init/systemd than other things. [19:17] A lot of things just install the executables via setup.py, and leave service configuration up to the packager (e.g., I think all the openstack services do that, for example). [19:17] its trying to be part of the os [19:17] i'm willing to accept that maybe this is over-doing things. [19:18] Eh, ultimately you're the driver :) [19:18] i think the link there is actually pretty good though [19:18] i think it is the closest to accomplishing what you wanting without total insanity [19:18] just like ... partial insanity [19:19] some nit picks i have , but largely good. [19:19] comment away [19:19] that dhclient hooks interface is complete crap [19:19] So, what if we unlitaterally install the script into /usr/lib/..., and just call that explicitly from the hook scripts, which then don't require templating... [19:19] ...and packagers can patch setup.py if they want the script in a different place? [19:19] you could actually unintentionally and unknowingly break some other program's hook because you are setting PYTHON_BINARY [19:19] what crap that is. [19:20] Hence this ^^^ proposal :) [19:20] larsks, but installing into a static location doesnt fix which python version should be used [19:20] but you just added a level of indirction [19:21] Argh, right, I keep forgetting that silly detail. [19:21] you have to template the /usr/lib/ thing [19:21] yeah. [19:21] How about: [19:21] setup.py installs it in /usr/bin, and the package moves it? :) [19:21] Nah. [19:21] this is also sovled by piggy-backing on the cloud-init in /usr/bin/ [19:21] Never mind. [19:21] Oh, that's an even better idea. [19:21] Just making it a subcommand, you mean? [19:21] i dont follow that [19:21] Like 'cloud-init dhclient-hook'? [19:21] yeah. [19:21] wait !!!!!!!!!1 i suggested that before [19:22] Well hell, that fixes everything. [19:22] rangerpb: pics or it didn't happen :) [19:22] the only thing i didnt' lke there is that the main has a bunch of imports and stuff that the dhclient doesnt [19:22] making it much slower. [19:22] oh it happened :) [19:22] larsks, rangerpb i really appreciate boht of your inputs [19:23] smoser, so are you saying youll take the perf hit to make it a subcommand ? [19:23] I think that seems cleanest, honestly. [19:23] yeah but I gotta hear the man say it [19:23] :) [19:23] Oh sure, I'm just opining. [19:23] well, it would be slower [19:23] Opinionating. [19:23] thats what i'm saying. [19:23] so i can take ap icure ... [19:23] and slowness is a pita. [19:24] I guess. We'll already have run cloud-init once at that point, so hopefully most of the disk accesses are already cached. [19:24] cloud-init runs *after* dhclient does it not? [19:24] Well, point being, we run it twice in either case. [19:24] You could run some short tests to quantify the performance difference. [19:25] smoser, we could conditionally import stuff based on what cloud-init is doing [19:28] AHHHH STOP ADDING LOGIC! :) [19:29] Seriously, that would be premature optimization unless you first demonstrate the magnitude of the performance hit. [19:31] im a people pleaser [19:32] actually, yeah. [19:32] the crap that i have for the stages and paths makes it bad. [20:03] larsks, here is time info [20:03] http://paste.ubuntu.com/21937409/ [20:04] and your conclusion is ? [20:05] rangerpb, ok. i'm fine with a sub-command of cloud-init [20:05] \o/ [20:05] and a subcommand would be something like 'init' already is right> [20:05] ? [20:05] http://paste.ubuntu.com/21937756/ [20:05] right. [20:06] ok, ill get cracking on that ... any advise on how you would see that being done? [20:06] it is very real. [20:06] would you detect if the subcommand was given and jump from there asap ? [20:07] yeah, just register the subcommand with the args as the other ones are. [20:07] rangerpb: see the 'main' method in cloudinit/cmd/main.py [20:07] the performance difference is ~ .03 seconds between the 2 [20:07] larsks, yeah i was poking around in there to see as well [21:14] so when can we merge https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/301310 :-P [21:14] larsks is that ready? [21:33] killing my package building CI job without that ;) === rangerpb is now known as rangerpbzzzz [23:13] harlowja: *I* think it's ready, if you and smoser are happy with it... [23:24] so I tested latest cloud-init 0.7.7~bzr1256-0ubuntu1~16.04.1 and it fails with a known bug we identified a couple of weeks ago where the bond link name attribute is expected by cloud-init but configdrive in OpenStack doesn't provide it since it's not part of the spec. [23:28] this fix didn't make it afaik: http://paste.ubuntu.com/20492837/ [23:32] in fact, I think this bug hasn't been fixed yet: https://bugs.launchpad.net/cloud-init/+bug/1605749 [23:53] mgagne cool, something to wrok on [23:53] once i get this git crap building, ha [23:53] :P [23:53] or others can, now that we have git! [23:53] ha [23:53] (wink wink) [23:53] * harlowja winks back at u [23:53] lol [23:53] ha [23:54] did u say u wanted to do that if we moved to git? [23:54] or was that someone else, ha [23:54] well, would make it less painful [23:54] I know smoser worked on fixing those issues AFAIK [23:55] in fact, this paste fixes the bond link name issue but also reproduces the issue where bond_links aren't physical nic but reference to link ids [23:55] anyway [23:55] will schedule some time to work on it tomorrow