[05:43] Nate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance https://review.openstack.org/225465 [05:43] Nate House proposed stackforge/cloud-init: Removed buffer return from http source vendor data https://review.openstack.org/229246 [13:51] morning! [13:54] good morning natorious [13:56] hopefully I did that patch right ^^. Didn't see anything else mentioned to directly address. I'd fixed that spelling thing via amend. [13:56] hey folks. [13:56] Are we doing a meeting today? [13:56] yes. [13:57] got a ways on configdrive and was looking at doing that as a separate request for that and it'd make it read a whole lot better w/ that in etc. [13:58] Merged stackforge/cloud-init: LICENSE: correct wording with respect to Apache 2 https://review.openstack.org/228471 [13:59] was planning a separate request for network json config too. Feel free to correct me if I'm going about things wrong or backwards [13:59] hi claudiupopa o/ [14:00] Hi natorious \o! [14:00] hey. [14:00] so irc or hangouts? [14:00] irc i think for now. [14:01] ok. so well walk over list of reviews quickly, and then open discussion and we can talk to natorious some there on his questions. [14:01] https://review.openstack.org/#/q/project:stackforge/cloud-init+status:open,n,z [14:01] i just accepted a license file change. [14:01] https://review.openstack.org/#/c/228471/ [14:02] the change was to make the LICENSE file not self contradictory. [14:02] https://review.openstack.org/#/c/228471/1/LICENSE [14:02] I'm not a lawyer, but looks good to me. ;-) [14:02] as previously it basically said "if you want to offer as apache 2.0 only, then put the GPLv3 header above" [14:03] which doens't make sense :). now its says [14:03] +1 [14:03] Nate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance https://review.openstack.org/225465 [14:03] "if you want to offer as apache 2.0 only, then put apache header above" [14:03] thansk to jgrimm for that. [14:04] i think reasonably thats all we have for the reviews. i think we should just help natorious a bit, with his questions and then we should try to get moving. [14:04] i have a couple topics for open discussion [14:05] is that ok? (i'm not skipping the reviews, i do want to talk about them, but i dont think they're jsut "quick") [14:05] Odd_Bloke, you here ? [14:05] Sure, let's go with open discussion then and see where natorious can use our help. [14:05] o/ [14:05] k [14:05] heres hwat i had foro open discussion topics [14:05] * python2.6 support: shall we bother with this? [14:05] + need someone to look at viability of 2.7 on rhel 6. [14:06] the primary immediate driver of this is desire of using taskflow. [14:06] but generally.. if we can do without 2.6, that might be nice. [14:07] the goal would be to have *some* solution for running this on rhel 6 [14:07] It would be nice to not need it, yes, but it depends after all on your supported platforms. [14:07] and probably some sles, but i'm not so familiar with sles family of products. [14:07] so the problem is rhel 6? [14:07] well, and probably some sles. [14:07] when it's scheduled for EOL? [14:08] The heat death of the universe (which will largely be caused by people having to maintain software for RHEL 6). :p [14:08] Wikipedia says 2020. [14:08] they have a 10 year cycle :/ [14:08] in the same year as python 2.7 [14:09] not a coincidence. [14:09] More, if we want to cover their extended lifecycle support. :p [14:09] i'm very much ok to say "supported with python2.7 on rhel 6" if there is some sane path to getting python 2.7 on rhel 6. [14:09] but not if that path includes "go to some dude's web site" or "download python2.6 and compile" [14:09] ie, i'd accept 'enable EPEL' [14:11] Is there going to be a path to installing cloud-init 2.0 on RHEL6 that fits your criteria? [14:11] thats what i want to know. i'd like someone to dig on that a bit. [14:12] smatzek, might know. also might have info on sles [14:13] what about pinning taskflow to before the 2.7 dep change? [14:13] that doesn't sound that good. [14:13] And if I'm not mistaken, the problem is with a dependency of taskflow. [14:13] well, apparently taskflow isn't itself 2.7 only. [14:13] right. [14:14] but generally speaking if we can say "no 2.6" then that woudl make life easier. [14:14] so i'm looking ofr a way, and a sane path for that. [14:14] i kond of hoped someone woudl take this and run with it. [14:14] i guess i can do that a bit after meeting [14:15] ok. so next topic, then. [14:15] Btw, let's use trello for this as well. [14:15] I would have the same criteria as smoser, if there is a sane path to getting 2.7 on rhel 6. I don't have info on if there is a sane path for that or not. I don't have the "python version included with" info for SLES 11 or 12 but could dig it up without much trouble. [14:15] claudiupopa, good idea. [14:15] claudiupopa, you want to add a task and give it to me ? [14:15] yep. [14:15] smatzek, ok. you can help me :). thanks for offering. [14:16] google doesn't seem to know about assane path to 2.6 that does not include "people.readhat.com/some-dude" (yes, thats better than some.dude.com, but...) [14:16] anyway.. [14:16] That's because you have to be insane to still be running RHEL6. :p [14:16] we could make a rhel/cent rpm for alt installing python2.7 that would work though [14:17] natorious, as in smoser maintain python2.7 on rhel ? [14:17] I still like Odd_Bloke's suggestion from several weeks past that those who bundle / ship python 2.6 after its EOL be made to sit in a corner and think about what they've done. [14:17] smoser == some-dude-i-wouldn't-trust [14:17] iir it can't replace the python2.6 due to yum or some such [14:18] natorious, yeah, python2.7 would be the name installed. i'd never expect that /usr/bin/python would be 2.7. [14:18] maybe we just hande RHEL 6 and those other OS levels on 2.6 out to dry with cloud-init 2.0 and if those distros really want it, they get python 2.7, on their distro. [14:18] but i really dont want to maintain pytthon package. [14:18] smoser, that is how i am leaning [14:18] hande = =hang [14:19] ok. [14:19] lets move on. [14:20] actually one more thing here. [14:20] Well, they could also maintain distro patches for taskflow/networkx/cloud-init 2.0 which would make it work on Python 2.6; the point is it's their problem. :p [14:20] please everyone here just join cloud-init mailing list . https://launchpad.net/~cloud-init [14:21] and i'll use that list to write to. [14:21] k? [14:21] Done. [14:21] smatzek, natorious claudiupopa you are all actioned to join that :) [14:21] ok. natorious now lets move on. [14:22] you want to ask some questions to the channel ? [14:22] yeah, sure [14:22] so configdrive [14:22] do we want to support v1 and v2? [14:22] done. [14:23] are the only differences vfat vs iso [14:24] i really dont care about v1. [14:24] What's the difference between v1 and v2? We're also interested in vfat for cloudbaseinit for instance. [14:24] it was pretty bad i think [14:24] and i think that v2 has been in place for probably 2 years ? [14:24] https://review.openstack.org/#/c/11184/ [14:25] s/2/3/ [14:25] no one other than possibly natorious's employer is running a 3 year old openstack cloud :) [14:25] burn [14:25] -.- [14:26] natorious, do you have a need to support config drive v1 ? [14:26] i'm reallynot terribly opposed to it. [14:26] but it woudl not land high on my priority list [14:26] I somewhat feel like most of the detection can be refactored down to detect umounted blockdevs searching f iso9660 and vfat fs w/ the same dir structure [14:26] anyone have links to a spec or other doc that describes v1 and v2? [14:26] well, we dont want to assume 'unmounted' [14:26] k [14:26] really we want to look for the filesystem label [14:27] k, that might make it even easier [14:27] that seems to me to be the biggest thing. [14:27] it would seem to me to be a low possibility of non-desired false positive if you found a drive with a label 'config-v2' [14:27] s/drive/drive or partition/ [14:28] ie, if someone put something like that... they probably did it so you would find it. [14:28] now... obviously such a person could be malicious [14:28] are we still doing an on first boot hook? [14:28] thats a good question [14:28] didn't see any examples of that in the http ds [14:29] cloud-init 0.7 basically always searches for a datasource. [14:29] (on every boot) [14:29] unles the user sets 'manual_cache_clean' or some such [14:29] the reason for that is so that it can detect "new instance". [14:29] so that the user who does: [14:29] * boot instance [14:30] * install a package [14:30] * shutdown and snapshot [14:30] doesn't have to also do: 'run cloud-init clean' [14:30] right [14:30] now that search is painful [14:30] in many ways. [14:31] its also ordered and limited by the datasources defined config right? [14:31] as for config drive, it means that if you messed up the label, then the instance would get all foobarred. [14:31] right. [14:32] we could possibly take a position that we do a quick check to see 'is this a new instance' [14:32] and only go looking further if that quick check failed [14:32] and if that quick check was buggy in that it did not recognize a new instance when it should have, we tell the user 'well, run "clean"' [14:33] i'm open to ideas here, and i dont knwo what a good "quick check" is. [14:33] i suspect that a lot of people do something like the above [14:33] BTW, on Python 2.7 in RHEL6: https://twitter.com/ncoghlan_dev/status/649228375135903744 [14:33] so that probably needs to generally work [14:33] Odd_Bloke, scl that references http://people.redhat.com [14:34] I found this: https://www.softwarecollections.org/en/scls/rhscl/python27/ [14:34] natorious, you ahve thoguths on that ? [14:34] i'd like to not have to search every boot [14:34] stuck on quick check. So if the instance is new but from a snap [14:34] it could have previous instance data in it [14:35] right. [14:35] I don't think there is a "quick check". I think the only real check you can make is to query datasources and get the instance ID from them to compare with ID on disk. [14:35] instance uuid is sourced from ds so we couldn't use that to determine caching of ds method [14:35] well, there might be a heuristic that is sane. [14:36] similar to what MS does / did when you bought a new hard drive and you had to call their customer support to allow you to run windows again. [14:36] there's also hw identifiers that can be used no? [14:37] ie some look at the system (hard drive ids, cpu number ... might be a suffiicent quick check) [14:37] so like tie an instance id data to hw identifiers somehow [14:37] yeh [14:37] checking hw identifiers doesn't work because you could have done a cold VM migration. [14:37] or live followed by a reboot. [14:38] in which case the 'quick check' said "looks like it changed". [14:38] so we'd just do a longer check. [14:38] and if thats annoying to the user, then can still manually set "manual clean" or something. [14:38] you see what i mean ? [14:39] live migrate wouldn't hit cloud-init until a new reboot too [14:39] I've struggled with these checks to see if you're a new instance for several years with both cloud-init and non-cloud-init based VM activation. I've found that cloud-init has the best way to check, with instance ID. [14:39] well, and live migrate would surely have the same (virtual) hard drive id [14:39] so processing the ds detection and determining the same instance uuid should keep things going still [14:39] right. [14:39] a quick check to see if HW changed would not trigger a deeper check if you too a VM snapshot and created a new VM using the snap on the same physical hardware. [14:40] smatzek, correct. [14:40] in which case, a user there would have to tell cluod-init that it should check every time. [14:40] i dont knwo how i feel about it. [14:42] if we had a setting like that users would have to flip it on if they plan to snap and deploy snaps. Also, wouldn't a hardware quick check require some hardware info in the base image for the public images you create? I suppose you could put bogus hw info in there so as not to disclose the actual HW you're creating them on. [14:42] smatzek, well,. to be fair, on a sane cloud.. if you did that, and your new isntance landed on the same "host". [14:42] (or similarly configured host) [14:42] you'd still hope that you'd prvide new "hard drive" serial number to the virtual disk. [14:42] i guess if in fact you'd handed the guest the same physical disk.. [14:43] smatzek, well on the offical published images, we'd clean whatever data is tehre. [14:43] but the ubuntu image build process never invokes cloud-init [14:43] what about windows? [14:44] there could be instances that use vdi chains for image caching who share a common base [14:44] claudiupopa, thats why you're here :) [14:44] but I think the vdi snaps have unique sn's [14:44] First of all, I don't think I know what's HW. :-) [14:45] i'd think they would, natorious . but you're right, they dont necessarily. but you'd think it would be desireable. [14:46] ok.. [14:46] so lets say this: [14:46] * cloud-init should have a cleanly documented way to explicitly disable or explicitly enable per-boot checking for instance id [14:47] * cloud-init may provide a "auto" mode for that that does some heuristics based checking or other quick checking [14:48] the auto mode shoudl generally be *very* quick and not be skewed to not have false negatives (when it missed a change that it should have seen) [14:48] does that seem sane ? [14:48] * cloud-init cares not re v1 configdrive [14:49] unless natorious makes it care, which is ok [14:49] yea [14:49] one example i'd like to give of a very sane and quick check would be on lxd. [14:49] lxd will expose its datasource via a socket /dev/lxd. it seems a sane "quick check" to do the unix-socket query 'get-instance-id' if /dev/lxd is present. [14:50] that suggests that the quick check should have access to the datasource that was used last... so that it woudl know it was lxd, and if previous was lxd and there is no /dev/lxd, then probably a change occurred. [14:50] interesting, I'd have to look into that and see about setting up a test env too [14:51] being socket I take it means not listed under block devs [14:51] yeah. its just a unix socket that lxd exposes an api on from outside. [14:52] i think that vmware has a similar thing. [14:52] did you have other question, natorious ? [14:52] think thats it [14:54] got what I need to get another request in. its going to depend on the previous but should be alright [14:56] natorious, cool [14:58] claudiupopa, you going to stick around for a while ? [14:58] or are you EOD [14:58] I'll be here for some time. [14:59] ok. i'll ping in a bit === harmw_ is now known as harmw [21:01] Hi, I am working on cloud-init 0.7.6. I was able to execute './packages/bddeb' command and successfully build the debian package. I installed the final debian package in Ubuntu machine. Can anyone provide some instructions to test the changes. I mean, are there any log files which say that the package has been run, etc. [21:22] hi stanguturi! [21:22] cloud-init --version should print out the installed version [21:22] hi natorious [21:22] if your looking for some specific source change you made prior to building the pkg [21:22] you can check the installed source too [21:23] typically in /usr/lib64/pythonX.X/site-packages/cloudinit etc [21:23] X.X being 2.7 or 3.4 and whatnot etc [21:24] depending on the targetted init system specified when building the pkg would depend on where what init scripts or service files get installed too [21:24] great. Wher are the log messages that get printed when the cloud-init runs on machine boot [21:24] but like if its not running on boot, perhaps you targetted the incorrect init sys for your distro version [21:25] /var/log/cloud-init.log or /var/log/cloud-init-output.log [21:25] one of the previous versions had a thing where most log msgs would go to syslog though [21:27] to change that you can comment the log line in /etc/cloud/cloud.cfg.d/05_logging.cfg for it [21:27] :x [21:27] like # - [ *log_base, *log_syslog ] [21:27] leaving - [ *log_base, *log_file ] uncommented etc === crobertsrh is now known as _crobertsrh [21:28] might not be an issue for you. Thought worthy of a mention though [21:30] ok. What is the best approach to test the changes. I am thinking of following 'make changes, build deb, install deb and reboot'.. Is there any other simple way to test the changes/ [21:32] :x [21:39] what init system are you using? [21:40] after making the change and reinstalling, rm your /var/lib/cloud dir and it'll be like its bran new etc [21:40] don't think you necessarily need to reboot either [21:41] you could probably just fire off the init scripts again