openstackgerritNate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance  https://review.openstack.org/22546505:43
openstackgerritNate House proposed stackforge/cloud-init: Removed buffer return from http source vendor data  https://review.openstack.org/22924605:43
smosergood morning natorious13:54
natorioushopefully I did that patch right ^^.  Didn't see anything else mentioned to directly address.  I'd fixed that spelling thing via amend.13:56
claudiupopahey folks.13:56
claudiupopaAre we doing a meeting today?13:56
natoriousgot 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:57
openstackgerritMerged stackforge/cloud-init: LICENSE: correct wording with respect to Apache 2  https://review.openstack.org/22847113:58
natoriouswas planning a separate request for network json config too.  Feel free to correct me if I'm going about things wrong or backwards13:59
natorioushi claudiupopa o/13:59
claudiupopaHi natorious \o!14:00
claudiupopaso irc or hangouts?14:00
smoserirc i think for now.14:00
smoserok. 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
smoseri just accepted a license file change.14:01
smoser https://review.openstack.org/#/c/228471/14:01
smoserthe change was to make the LICENSE file not self contradictory.14:02
smoser https://review.openstack.org/#/c/228471/1/LICENSE14:02
claudiupopaI'm not a lawyer, but looks good to me. ;-)14:02
smoseras previously it basically said "if you want to offer as apache 2.0 only, then put the GPLv3 header above"14:02
smoserwhich doens't make sense :). now its says14:03
openstackgerritNate House proposed stackforge/cloud-init: [WIP] Updating openstack.base to support configdrive inheritance  https://review.openstack.org/22546514:03
smoser "if you want to offer as apache 2.0 only, then put apache header above"14:03
smoserthansk to jgrimm for that.14:03
smoseri 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
smoseri have a couple topics for open discussion14:04
smoseris 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
smoserOdd_Bloke, you here ?14:05
claudiupopaSure, let's go with open discussion then and see where natorious can use our help.14:05
smoserheres hwat i had foro open discussion topics14:05
smoser * python2.6 support: shall we bother with this?14:05
smoser    + need someone to look at viability of 2.7 on rhel 6.14:05
smoserthe primary immediate driver of this is desire of using taskflow.14:06
smoserbut generally.. if we can do without 2.6, that might be nice.14:06
smoserthe goal would be to have *some* solution for running this on rhel 614:07
claudiupopaIt would be nice to not need it, yes, but it depends after all on your supported platforms.14:07
smoserand probably some sles, but i'm not so familiar with sles family of products.14:07
claudiupopaso the problem is rhel 6?14:07
smoserwell, and probably some sles.14:07
claudiupopawhen it's scheduled for EOL?14:07
Odd_BlokeThe heat death of the universe (which will largely be caused by people having to maintain software for RHEL 6). :p14:08
Odd_BlokeWikipedia says 2020.14:08
natoriousthey have a 10 year cycle :/14:08
claudiupopain the same year as python 2.714:08
claudiupopanot a coincidence.14:09
Odd_BlokeMore, if we want to cover their extended lifecycle support. :p14:09
smoseri'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
smoserbut not if that path includes "go to some dude's web site" or "download python2.6 and compile"14:09
smoserie, i'd accept 'enable EPEL'14:09
Odd_BlokeIs there going to be a path to installing cloud-init 2.0 on RHEL6 that fits your criteria?14:11
smoserthats what i want to know. i'd like someone to dig on that a bit.14:11
smosersmatzek, might know. also might have info on sles14:12
natoriouswhat about pinning taskflow to before the 2.7 dep change?14:13
claudiupopathat doesn't sound that good.14:13
claudiupopaAnd if I'm not mistaken, the problem is with a dependency of taskflow.14:13
smoserwell, apparently taskflow isn't itself 2.7 only.14:13
smoserbut generally speaking if we can say "no 2.6" then that woudl make life easier.14:14
smoserso i'm looking ofr a way, and a sane path for that.14:14
smoseri kond of hoped someone woudl take this and run with it.14:14
smoseri guess i can do that a bit after meeting14:14
smoserok. so next topic, then.14:15
claudiupopaBtw, let's use trello for this as well.14:15
smatzekI 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
smoserclaudiupopa, good idea.14:15
smoserclaudiupopa, you want to add a task and give it to me ?14:15
smosersmatzek, ok. you can help me :). thanks for offering.14:15
smosergoogle 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
Odd_BlokeThat's because you have to be insane to still be running RHEL6. :p14:16
natoriouswe could make a rhel/cent rpm for alt installing python2.7 that would work though14:16
smosernatorious, as in smoser maintain python2.7 on rhel ?14:17
smatzekI 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
smosersmoser == some-dude-i-wouldn't-trust14:17
natoriousiir it can't replace the python2.6 due to yum or some such14:17
smosernatorious, yeah, python2.7 would be the name installed. i'd never expect that /usr/bin/python would be 2.7.14:18
smatzekmaybe 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
smoserbut i really dont want to maintain pytthon package.14:18
smosersmoser, that is how i am leaning14:18
smatzekhande = =hang14:18
smoserlets move on.14:19
smoseractually one more thing here.14:20
Odd_BlokeWell, 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. :p14:20
smoserplease everyone here just join cloud-init mailing list . https://launchpad.net/~cloud-init14:20
smoserand i'll use that list to write to.14:21
smosersmatzek, natorious claudiupopa you are all actioned to join that :)14:21
smoserok. natorious now lets move on.14:21
smoseryou want to ask some questions to the channel ?14:22
natoriousyeah, sure14:22
natoriousso configdrive14:22
natoriousdo we want to support v1 and v2?14:22
natoriousare the only differences vfat vs iso14:23
smoseri really dont care about v1.14:24
claudiupopaWhat's the difference between v1 and v2? We're also interested in vfat for cloudbaseinit for instance.14:24
smoserit was pretty bad i think14:24
smoserand i think that v2 has been in place for probably 2 years ?14:24
smoserno one other than possibly natorious's employer is running a 3 year old openstack cloud :)14:25
smosernatorious, do you have a need to support config drive v1 ?14:26
smoseri'm reallynot terribly opposed to it.14:26
smoserbut it woudl not land high on my priority list14:26
natoriousI 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 structure14:26
smatzekanyone have links to a spec or other doc that describes v1 and v2?14:26
smoserwell, we dont want to assume 'unmounted'14:26
smoserreally we want to look for the filesystem label14:26
natoriousk, that might make it even easier14:27
smoserthat seems to me to be the biggest thing.14:27
smoserit 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
smosers/drive/drive or partition/14:27
smoserie, if someone put something like that... they probably did it so you would find it.14:28
smosernow... obviously such a person could be malicious14:28
natoriousare we still doing an on first boot hook?14:28
smoserthats a good question14:28
natoriousdidn't see any examples of that in the http ds14:28
smosercloud-init 0.7 basically always searches for a datasource.14:29
smoser(on every boot)14:29
smoserunles the  user sets 'manual_cache_clean' or some such14:29
smoserthe reason for that is so that it can detect "new instance".14:29
smoserso that the user who does:14:29
smoser  * boot instance14:29
smoser * install a package14:30
smoser * shutdown and snapshot14:30
smoserdoesn't have to also do: 'run cloud-init clean'14:30
smosernow that search is painful14:30
smoserin many ways.14:30
natoriousits also ordered and limited by the datasources defined config right?14:31
smoseras for config drive, it means that if you messed up the label, then the instance would get all foobarred.14:31
smoserwe could possibly take a position that we do a quick check to see 'is this a new instance'14:32
smoserand only go looking further if that quick check failed14:32
smoserand 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:32
smoseri'm open to ideas here, and i dont knwo what a good "quick check" is.14:33
smoseri suspect that a lot of people do something like the above14:33
Odd_BlokeBTW, on Python 2.7 in RHEL6: https://twitter.com/ncoghlan_dev/status/64922837513590374414:33
smoserso that probably needs to generally work14:33
smoserOdd_Bloke, scl that references http://people.redhat.com14:33
Odd_BlokeI found this: https://www.softwarecollections.org/en/scls/rhscl/python27/14:34
smosernatorious, you ahve thoguths on that ?14:34
smoseri'd like to not have to search every boot14:34
natoriousstuck on quick check.  So if the instance is new but from a snap14:34
natoriousit could have previous instance data in it14:34
smatzekI 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
natoriousinstance uuid is sourced from ds so we couldn't use that to determine caching of ds method14:35
smoserwell, there might be a heuristic that is sane.14:35
smosersimilar 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
natoriousthere's also hw identifiers that can be used no?14:36
smoserie some look at the system (hard drive ids, cpu number ... might be a suffiicent quick check)14:37
natoriousso like tie an instance id data to hw identifiers somehow14:37
smatzekchecking hw identifiers doesn't work because you could have done a cold VM migration.14:37
smatzekor live followed by a reboot.14:37
smoserin which case the 'quick check' said "looks like it changed".14:38
smoserso we'd just do a longer check.14:38
smoserand if thats annoying to the user, then can still manually set "manual clean" or something.14:38
smoseryou see what i mean ?14:38
natoriouslive migrate wouldn't hit cloud-init until a new reboot too14:39
smatzekI'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
smoserwell, and live migrate would surely have the same (virtual) hard drive id14:39
natoriousso processing the ds detection and determining the same instance uuid should keep things going still14:39
smatzeka 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:39
smosersmatzek, correct.14:40
smoserin which case, a user there would have to tell cluod-init that it should check every time.14:40
smoseri dont knwo how i feel about it.14:40
smatzekif 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
smosersmatzek, well,. to be fair, on a sane cloud.. if you did that, and your new isntance landed on the same "host".14:42
smoser(or similarly configured host)14:42
smoseryou'd still hope that you'd prvide new "hard drive" serial number to the virtual disk.14:42
smoseri guess if in fact you'd  handed the guest the same physical disk..14:42
smosersmatzek, well on the offical published images, we'd clean whatever data is tehre.14:43
smoserbut the ubuntu image build process never invokes cloud-init14:43
claudiupopawhat about windows?14:43
natoriousthere could be instances that use vdi chains for image caching who share a common base14:44
smoserclaudiupopa, thats why you're here :)14:44
natoriousbut I think the vdi snaps have unique sn's14:44
claudiupopaFirst of all, I don't think I know what's HW. :-)14:44
smoseri'd think they would, natorious . but you're right, they dont necessarily. but you'd think it would be desireable.14:45
smoserso lets say this:14:46
smoser * cloud-init should have a cleanly documented way to explicitly disable or explicitly enable per-boot checking for instance id14:46
smoser * cloud-init may provide a "auto" mode for that that does some heuristics based checking or other quick checking14:47
smoser   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
smoserdoes that seem sane ?14:48
natorious* cloud-init cares not re v1 configdrive14:48
smoserunless natorious makes it care, which is ok14:49
smoserone example i'd like to give of a very sane and quick check would be on lxd.14:49
smoserlxd 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:49
smoserthat 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
natoriousinteresting, I'd have to look into that and see about setting up a test env too14:50
natoriousbeing socket I take it means not listed under block devs14:51
smoseryeah. its just a unix socket that lxd exposes an api on from outside.14:51
smoseri think that vmware has a similar thing.14:52
smoserdid you have other question, natorious ?14:52
natoriousthink thats it14:52
natoriousgot what I need to get another request in.  its going to depend on the previous but should be alright14:54
smosernatorious, cool14:56
smoserclaudiupopa, you going to stick around for a while ?14:58
smoseror are you EOD14:58
claudiupopaI'll be here for some time.14:58
smoserok. i'll ping in a bit14:59
=== harmw_ is now known as harmw
stanguturiHi, 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:01
natorioushi stanguturi!21:22
natoriouscloud-init --version should print out the installed version21:22
stanguturihi natorious21:22
natoriousif your looking for some specific source change you made prior to building the pkg21:22
natoriousyou can check the installed source too21:22
natorioustypically in /usr/lib64/pythonX.X/site-packages/cloudinit etc21:23
natoriousX.X being 2.7 or 3.4 and whatnot etc21:23
natoriousdepending on the targetted init system specified when building the pkg would depend on where what init scripts or service files get installed too21:24
stanguturigreat. Wher are the log messages that get printed when the cloud-init runs on machine boot21:24
natoriousbut like if its not running on boot, perhaps you targetted the incorrect init sys for your distro version21:24
natorious /var/log/cloud-init.log or /var/log/cloud-init-output.log21:25
natoriousone of the previous versions had a thing where most log msgs would go to syslog though21:25
natoriousto change that you can comment the log line in /etc/cloud/cloud.cfg.d/05_logging.cfg for it21:27
natoriouslike # - [ *log_base, *log_syslog ]21:27
natoriousleaving  - [ *log_base, *log_file ] uncommented etc21:27
=== crobertsrh is now known as _crobertsrh
natoriousmight not be an issue for you.  Thought worthy of a mention though21:28
stanguturiok. 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:30
natoriouswhat init system are you using?21:39
natoriousafter making the change and reinstalling, rm your /var/lib/cloud dir and it'll be like its bran new etc21:40
natoriousdon't think you necessarily need to reboot either21:40
natoriousyou could probably just fire off the init scripts again21:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!