[00:07] <rharper> smoser: would you expect trunk cloud-init to run inside trusty as-is ?
[00:47] <smoser> rharper,  yeah, i'd think so
[00:47] <smoser> dont remember though.
[01:22] <rharper> smoser: ok, it doesn't; that does make injecting a deb of cloud-init into the various target releases somewhat problematic;
[01:23] <smoser> oh. trusty needs python2
[01:23] <smoser> right ?
[01:23] <smoser> is that it.
[01:24] <smoser> try
[01:24] <smoser> ./packages/bddeb --python2 -v -S
[01:24] <smoser> i'm trying that
[01:25] <rharper> ah, that makes sense
[01:28] <smoser> well, it does install
[01:29] <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:30] <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:35] <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:37]  * rharper sbuilds harder
[09:51] <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?
[13:49] <smoser> Odd_Bloke, i can't right now be delayed by moving to git.
[13:50] <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:51] <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:52] <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:53] <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: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> 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:55] <Odd_Bloke> Untested as yet.
[13:55] <smoser> if current_instance_id in (big_endian(value), little_endian(value)):
[13:55] <smoser>  good
[13:56] <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:57] <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:58] <smoser> interestingly. azure uses system-uuid
[13:58] <smoser> openstack uses product-uuid
[13:59] <smoser> would both be vulnerable? or is product-uuid safe due to its different location?
[14:00] <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:01] <Odd_Bloke> smoser: I think the OpenStack data source uses the metadata API to get the instance ID.
[14:02] <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:03] <Odd_Bloke> Anyway, lunch is ready, I'll BBIAB.
[14:04] <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:17] <Odd_Bloke> smoser: Oh, I didn't understand it was a proposed change. :)
[15:14] <Odd_Bloke> smoser: Oh, hmph, we remove the /var/lib/cloud/instance link before we determine instance ID.
[15:15] <smoser>  Odd_Bloke see /var/lib/cloud/data/previous-instance-id
[15:16] <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:20] <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:21] <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:22] <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:23] <Odd_Bloke> But my quick check for instance ID is Azure-specific, other things might will need to hit metadata APIs etc.
[15:24] <Odd_Bloke> And we haven't yet determined a data source at this point.
[15:25] <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:28] <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:29] <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:30] <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:31] <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
[19:11] <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:13] <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:37] <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
[20:12] <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:13] <smoser> hm... the packaging doesn't use /usr/lib/python3.5 at all. right ?
[20:14] <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:15] <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:17] <rharper> maybe newer debhelper ?
[20:17] <rharper> 7 vs 9 ?
[20:18] <smoser> well thats just declaring the minimum
[20:18] <smoser> it uses what isthere.
[20:46] <smoser> rharper, i know what it is.
[20:46] <smoser> see in curtin/trunk/debian/rules
[20:47] <smoser> we build for python in $(PY3VERS)
[20:51] <smoser> it has somethignto do with that.
[20:58] <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
[22:44] <suro-patz> hello folks!
[22:45] <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:46] <suro-patz> https://github.com/openstack/cloud-init/blame/0.7.x/cloudinit/util.py#L49
[22:49] <suro-patz> harlowja_at_home: ^^
[23:15] <harlowja_at_home> suro-patz, sup
[23:16] <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:27] <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:28] <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:29] <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:30] <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:31] <suro-patz> okie dokie
[23:31] <suro-patz> harlowja_at_home: thanks !
[23:31] <harlowja_at_home> np
[23:33] <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)