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