=== shardy is now known as shardy_lunch | ||
=== shardy_lunch is now known as shardy | ||
smoser | harlowja, thank you. | 12:48 |
---|---|---|
smoser | harlowja, you can see things for proposed merge into cloud-init's git trunk this way... | 12:49 |
smoser | all the cloud-init repos that launchpad knows about (~user/cloud-init) are viewable at https://code.launchpad.net/cloud-init | 12:50 |
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:51 |
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/ | 12:52 |
=== contrapumpkin is now known as copumpkin | ||
=== rangerpbzzzz is now known as rangerpb | ||
smoser | larsks, around ? | 13:59 |
larsks | Sort of :) Phone meeting. I saw your changes; hope to look at that this afternoon. | 13:59 |
smoser | larsks, alternatively if you can tell me how to test that i did not break your work with bdrpm i'd just merge | 14:01 |
=== rangerpb is now known as rangerpbzzzz | ||
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:23 |
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:24 |
larsks | I think the existing code is post-your-re-import. But yeah, may be missing tags. | 16:25 |
smoser | yeah, just missing tags then. | 16:27 |
smoser | that makes more sense. | 16:27 |
smoser | rharper, powersj harlowja ^ above paste points to building cloud-init in an centos7 lxc. | 16:29 |
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. | 16:30 |
rharper | smoser: what's with the ssh stuff in the build env? | 17:22 |
rharper | it's a builder script? | 17:24 |
harlowja | whats up | 17:24 |
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:25 |
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:26 |
harlowja | (well the mock question isn't) | 17:27 |
harlowja | but the spring part is | 17:27 |
larsks | I had figured that out, but thanks :) | 17:28 |
* rharper enjoys the artic air during his sprints | 17:29 | |
=== rangerpbzzzz is now known as rangerpb | ||
harlowja | lol | 17:29 |
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:31 |
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:32 | |
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:33 |
rangerpb | it is a good compromise, the only downside is the python version is not figured out like it is with entry_point | 17:34 |
smoser | rangerpb, right. and that is fine. | 17:35 |
smoser | except... | 17:35 |
smoser | which python do you call ? | 17:35 |
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:36 |
rangerpb | i did see python version is determined in the make file | 17:37 |
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:05 |
rangerpb | how about running a command which in turn could do that? | 18:06 |
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:07 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
rangerpb | smoser, we could conditionally import stuff based on what cloud-init is doing | 19:25 |
larsks | AHHHH STOP ADDING LOGIC! :) | 19:28 |
larsks | Seriously, that would be premature optimization unless you first demonstrate the magnitude of the performance hit. | 19:29 |
rangerpb | im a people pleaser | 19:31 |
smoser | actually, yeah. | 19:32 |
smoser | the crap that i have for the stages and paths makes it bad. | 19:32 |
smoser | larsks, here is time info | 20:03 |
smoser | http://paste.ubuntu.com/21937409/ | 20:03 |
rangerpb | and your conclusion is ? | 20:04 |
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:05 |
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:06 |
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 | 20:07 |
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:14 |
harlowja | killing my package building CI job without that ;) | 21:33 |
=== rangerpb is now known as rangerpbzzzz | ||
larsks | harlowja: *I* think it's ready, if you and smoser are happy with it... | 23:13 |
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:24 |
mgagne | this fix didn't make it afaik: http://paste.ubuntu.com/20492837/ | 23:28 |
mgagne | in fact, I think this bug hasn't been fixed yet: https://bugs.launchpad.net/cloud-init/+bug/1605749 | 23:32 |
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:53 |
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:54 |
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 | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!