| rharper | smoser: would you expect trunk cloud-init to run inside trusty as-is ? | 00:07 |
|---|---|---|
| smoser | rharper, yeah, i'd think so | 00:47 |
| smoser | dont remember though. | 00:47 |
| rharper | smoser: ok, it doesn't; that does make injecting a deb of cloud-init into the various target releases somewhat problematic; | 01:22 |
| smoser | oh. trusty needs python2 | 01:23 |
| smoser | right ? | 01:23 |
| smoser | is that it. | 01:23 |
| smoser | try | 01:24 |
| smoser | ./packages/bddeb --python2 -v -S | 01:24 |
| smoser | i'm trying that | 01:24 |
| rharper | ah, that makes sense | 01:25 |
| smoser | well, it does install | 01:28 |
| rharper | ph | 01:29 |
| rharper | it installs | 01:29 |
| smoser | but needs python-jinja2 and python-oauthlib the second of which might not be necessary | 01:29 |
| smoser | as i think it tries one and then the other | 01:29 |
| smoser | and jinja2 also | 01:29 |
| rharper | it errors out running | 01:29 |
| smoser | we can probably make it build wihtout those deps | 01:29 |
| rharper | /bin/sh: 1: exec: cloud-init: not found^M | 01:29 |
| rharper | I'm injecting the deb; dpkg --install; apt-get -f install ; that picks up package deps | 01:29 |
| smoser | seems to work for me | 01:30 |
| smoser | (with --python2) | 01:30 |
| rharper | right | 01:30 |
| smoser | i have to run | 01:30 |
| rharper | and built inside trusty sbuild | 01:30 |
| rharper | ok | 01:30 |
| smoser | right. | 01:30 |
| rharper | Keeping session: trusty-amd64-0c52d381-b0b8-48af-a299-5ed976f72b21 | 01:35 |
| rharper | E: cloud-init_0.7.7~bzr1163-1.dsc: amd64 not in arch list or does not match any arch wildcards: all -- skipping | 01:35 |
| * rharper sbuilds harder | 01:37 | |
| Odd_Bloke | smoser: So I now have a few different things that are pending merges in to trunk; I've been holding off on that because of overheard conversations about switching to git, but that hasn't happened yet (AFAIK). | 09:51 |
| Odd_Bloke | smoser: Is trunk still frozen for the move, or can we continue using it? | 09:51 |
| smoser | Odd_Bloke, i can't right now be delayed by moving to git. | 13:49 |
| smoser | i'd like to be on git. and i'd welcome you or someone setting up a git branch that synced trunk | 13:50 |
| smoser | on launchpad i think. | 13:50 |
| Odd_Bloke | smoser: I'd like that too, but also don't have the time. | 13:50 |
| Odd_Bloke | smoser: So can we safely merge things in to lp:cloud-init for the time being? | 13:50 |
| smoser | yes | 13:50 |
| Odd_Bloke | OK, cool. | 13:50 |
| smoser | and i'm ok for you to do that. | 13:51 |
| smoser | do the merges yourself, that is, and push. | 13:51 |
| Odd_Bloke | smoser: Ack, thanks. | 13:51 |
| smoser | some things: | 13:51 |
| Odd_Bloke | smoser: Also, I'm going to have a patch for UUID endianness for trusty soonish. | 13:51 |
| Odd_Bloke | (Luckily, it doesn't affect wily onwards. \o/) | 13:51 |
| smoser | a.) tox must work | 13:51 |
| smoser | b.) do not add dependencies | 13:52 |
| smoser | c.) commit message in 'git style' format | 13:52 |
| smoser | short description, blank line, longer description | 13:52 |
| smoser | d.) update ChangeLog with roughly short description, and please give people credit there | 13:52 |
| smoser | e.) when a bug is fixed, please --fixes lp:XXXXX on the commit | 13:53 |
| smoser | Odd_Bloke, so its cloud-init's job to flip endieanness of a uuid ? | 13:53 |
| Odd_Bloke | smoser: The problem is that the kernel with the bug is in the wild. | 13:53 |
| smoser | i think basically we just have to test both possible endianness | 13:53 |
| Odd_Bloke | if current_instance_uuid == reported_instance_uuid: | 13:54 |
| Odd_Bloke | # The endianness of the instance UUID has not changed | 13:54 |
| Odd_Bloke | return reported_instance_uuid | 13:54 |
| Odd_Bloke | NAILED IT | 13:54 |
| Odd_Bloke | if current_instance_uuid == reported_instance_uuid: | 13:54 |
| Odd_Bloke | # The endianness of the instance UUID has not changed | 13:54 |
| Odd_Bloke | return reported_instance_uuid | 13:54 |
| Odd_Bloke | Oh FFS. | 13:54 |
| Odd_Bloke | How do clipboards in X even work? | 13:54 |
| Odd_Bloke | smoser: http://paste.ubuntu.com/15266719/ is what I have currently. | 13:54 |
| Odd_Bloke | Untested as yet. | 13:55 |
| smoser | if current_instance_id in (big_endian(value), little_endian(value)): | 13:55 |
| smoser | good | 13:55 |
| smoser | can you put such a function in util ? | 13:56 |
| smoser | i'm expecting that very soon i'll be having the same thing on openstack | 13:56 |
| Odd_Bloke | smoser: So ATM it only affects Azure on trusty and maybe precise (I haven't checked there yet, focussed on getting trusty fixed first). | 13:57 |
| smoser | http://paste.ubuntu.com/15266739/ | 13:57 |
| Odd_Bloke | smoser: So this was all going to be in an Ubuntu patch. | 13:57 |
| smoser | interestingly. azure uses system-uuid | 13:58 |
| smoser | openstack uses product-uuid | 13:58 |
| smoser | would both be vulnerable? or is product-uuid safe due to its different location? | 13:59 |
| Odd_Bloke | smoser: Where does OpenStack use product-uuid? | 14:00 |
| smoser | see thatpaste. | 14:00 |
| smoser | and then followed paste is http://paste.ubuntu.com/15259269/ | 14:00 |
| Odd_Bloke | smoser: I think the OpenStack data source uses the metadata API to get the instance ID. | 14:01 |
| Odd_Bloke | smoser: It may be that that's also presented via DMI, but I don't think it's used. | 14:02 |
| Odd_Bloke | (And so it should be fine) | 14:02 |
| Odd_Bloke | Anyway, lunch is ready, I'll BBIAB. | 14:03 |
| smoser | Odd_Bloke, read the message :) | 14:04 |
| smoser | i'm looking to change that. or at least to not re-hit the MD (which might be there) if the dmi data says that i am the same insatnce i was last time. | 14:04 |
| Odd_Bloke | smoser: Oh, I didn't understand it was a proposed change. :) | 14:17 |
| Odd_Bloke | smoser: Oh, hmph, we remove the /var/lib/cloud/instance link before we determine instance ID. | 15:14 |
| smoser | Odd_Bloke see /var/lib/cloud/data/previous-instance-id | 15:15 |
| smoser | and honestly, your check here should really run before we remove that link | 15:16 |
| smoser | because what you're doing is fairly definitive | 15:16 |
| smoser | and we only remove that link so that we go searching again, which we wouldnt need to do. | 15:16 |
| smoser | make sense ? | 15:16 |
| Odd_Bloke | smoser: Not quite, no. Looking at bin/cloud-init, the bits under '# Stage 4' don't do anything but clean things up if we aren't running with --local... | 15:20 |
| Odd_Bloke | (Perhaps I don't understand enough about when we run cloud-init at boot, and how) | 15:20 |
| smoser | right. you are adding somethign that is smarter than that. | 15:20 |
| smoser | so basically first thign that happens is cloud-init --local runs. | 15:21 |
| smoser | and it removes /var/lib/cloud/instance/ | 15:21 |
| smoser | if it had 'manual_cache_clean' then it would nto remove that link | 15:21 |
| smoser | and it would not go looking for a datasource again | 15:21 |
| smoser | it'd just re-use the cached data. | 15:21 |
| smoser | which is what you want it to do. | 15:21 |
| smoser | so | 15:22 |
| smoser | if manual_cache_clean: | 15:22 |
| smoser | do not remove | 15:22 |
| smoser | else: | 15:22 |
| smoser | if my_quick_check_for_instance_id() == the_previous_instance_id: | 15:22 |
| smoser | do not remove | 15:22 |
| smoser | else | 15:22 |
| smoser | remove link | 15:22 |
| Odd_Bloke | But my quick check for instance ID is Azure-specific, other things might will need to hit metadata APIs etc. | 15:23 |
| Odd_Bloke | And we haven't yet determined a data source at this point. | 15:24 |
| Odd_Bloke | I'm not saying that we shouldn't do that, I just don't think I can do it in the scope of a fix for a critical bug (that only affects old versions of cloud-init). :) | 15:25 |
| smoser | 2 othe rthings that allow me to support you making such a possibly invasive change | 15:28 |
| smoser | a.) /var/lib/cloud/data/previous-datasource is there. meaning you could look and noly consider this if the previous datasource was azure | 15:28 |
| smoser | i dont think this is necessarily required, though, given | 15:28 |
| smoser | b.) its a UUID ! this thing should never be seen *anywhere* randomly twice | 15:29 |
| smoser | the failure path i guess is if you are a new instance on hardware, where that value is actually the node's uuid. | 15:29 |
| smoser | and you happen to have ran on this system when someone captured a new image. | 15:30 |
| Odd_Bloke | smoser: Or if the cloud sets the same value for all instances. | 15:30 |
| smoser | and it happened to hit the same instance id that your "proper" check found ? | 15:30 |
| smoser | if a cloud has all their instance ids with the same instance-id, then yes. we are foobarred. | 15:31 |
| smoser | i think we can strongly suggest people not do that. | 15:31 |
| Odd_Bloke | :D | 15:31 |
| rharper | smoser: I think the lxd check isn't quite right; IIUC, if one does not specify a lxd: dict in cloud-config, then it shouldn't attempt to install lxd; we do a lxd_cfg = cfg.get('lxd'); which if yaml doesn't include a lxd section returns None; the next check if not lxd_cfg and isinstance(lxd_cfg, dict); is True and False for lxd_cfg of NoneType; this means we fall through and attempt to install lxd; | 19:11 |
| smoser | you're probably right. | 19:13 |
| rharper | adding a not isistance(, dict) I think achieves what is wanted; assuming that if someone adds just lxd section (empty dict); that will install lxd .. | 19:13 |
| rharper | cool, with a fix in that logic; I don't get lxd attempting to install in trusty (and thus breaking since it needs to be installed via backports); I;ll file a bug, and send you a MR | 19:37 |
| rharper | there's also another lurking error in one of the error paths; pyflakes cloudinit/config/cc_lxd.py will show it | 19:37 |
| rharper | smoser: I packaged a python3 version of cloud-init built inside a xenial sbuild; it installs to /usr/lib/python3.5/dist-packages ; the python3 interpreter on vivid doesn't know to look there; contrast with curtin, which uses /usr/lib/python3/dist-packages which works for any python3.x IIUC; shoudl we do the same when packaging cloud-init ? or do we need to build a new cloud-init deb for each release? that does mak | 20:12 |
| rharper | e testing changes to cloud-init across all release a longer process since it requries N rebuilds | 20:12 |
| smoser | hm... the packaging doesn't use /usr/lib/python3.5 at all. right ? | 20:13 |
| smoser | it dh_python that does that. | 20:14 |
| rharper | oh | 20:14 |
| rharper | hrm, maybe the tools/build-deb in curtin does something different | 20:14 |
| rharper | I built the curtin package on my xenial host, so I don't think an sbuild of curtin would change the python path | 20:15 |
| rharper | build curtin inside xenial sbuild; that is | 20:15 |
| smoser | well i'm certain that i have never typed that path | 20:15 |
| rharper | I agree | 20:15 |
| rharper | now to look at the difference | 20:15 |
| smoser | tools/build-deb does with dh_python too (curtin) | 20:15 |
| rharper | maybe newer debhelper ? | 20:17 |
| rharper | 7 vs 9 ? | 20:17 |
| smoser | well thats just declaring the minimum | 20:18 |
| smoser | it uses what isthere. | 20:18 |
| smoser | rharper, i know what it is. | 20:46 |
| smoser | see in curtin/trunk/debian/rules | 20:46 |
| smoser | we build for python in $(PY3VERS) | 20:47 |
| smoser | it has somethignto do with that. | 20:51 |
| rharper | smoser: yeah, I was looking at the rules in curtin which specifies 2 and 3; looking to see if I can build with those changes | 20:58 |
| suro-patz | hello folks! | 22:44 |
| suro-patz | cloud-init 0.7.x on rhel7 is failing to execute due to dependency on urllib | 22:45 |
| suro-patz | am I missing some requirement? | 22:45 |
| suro-patz | https://github.com/openstack/cloud-init/blame/0.7.x/cloudinit/util.py#L49 | 22:46 |
| suro-patz | harlowja_at_home: ^^ | 22:49 |
| harlowja_at_home | suro-patz, sup | 23:15 |
| harlowja_at_home | is six installed? | 23:16 |
| harlowja_at_home | or a new enough six? | 23:16 |
| harlowja_at_home | suro-patz, i'd check the version of six | 23:16 |
| harlowja_at_home | causeit works for me | 23:16 |
| suro-patz | harlowja_at_home: yes, that's where the issue was | 23:27 |
| suro-patz | the rhel7 image i was using had six-1.3 :( | 23:27 |
| harlowja_at_home | ya, sounds old | 23:28 |
| harlowja_at_home | to old | 23:28 |
| suro-patz | Do you think it makes sense to put a lower bound in cloud-init requirements | 23:28 |
| suro-patz | harlowja_at_home: ^^ ? | 23:28 |
| harlowja_at_home | nope | 23:28 |
| harlowja_at_home | oh | 23:29 |
| harlowja_at_home | yes i mean | 23:29 |
| suro-patz | ok, I will go ahead and submit a request | 23:29 |
| harlowja_at_home | suro-patz, https://github.com/openstack/cloud-init/blob/master/requirements.txt#L8 | 23:29 |
| suro-patz | this days is it on github/gerrit or ol bazar stuff? | 23:29 |
| harlowja_at_home | oh nm, the 0.7.x branch not have that | 23:30 |
| suro-patz | oh cool | 23:30 |
| harlowja_at_home | smoser, where 0.7.x stuff happening now-adays | 23:30 |
| harlowja_at_home | :-P | 23:30 |
| suro-patz | yes, 0.7.x does not have | 23:30 |
| harlowja_at_home | i think smoser thought launchpad for 0.7.x and git for 2.0 stuff | 23:30 |
| harlowja_at_home | he'll know best | 23:30 |
| suro-patz | okie dokie | 23:31 |
| suro-patz | harlowja_at_home: thanks ! | 23:31 |
| harlowja_at_home | np | 23:31 |
| rharper | smoser: I was unsuccessful in teaching cloud-init to do both python2 and 3 ; without more study at least. Currently I'm just using the python2 version of the build any place that doesn't have python3.5 (which I belive is only xenial) | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!