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