[07:58] harlowja: I've been OOO since the weekend, I'm planning on spending some time this morning to get a proof of concept that we can discuss at the meeting this afternoon. [07:58] harlowja: So none as yet, but thanks for the offer! [10:31] Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands https://review.openstack.org/220593 [10:35] Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands https://review.openstack.org/220593 [10:41] harlowja: ARGH, so networkx have dropped Python 2.6 support in their latest release. [10:41] harlowja: Which the latest two versions of taskflow depend on. [10:41] Total sadface. [10:55] Also the installation failure doesn't happen in tox. :/ [12:35] is't possible to put cloud-config data into file and re-run it using cloud-init cli? [12:36] currently I've to stop EC2 instance, update UserData and restart it which I find it to be very inconvenient method [12:58] Morning! [13:22] eofs: should be doable. Just rid your instance data from /var/lib/cloud [13:24] natorious: I tried to put my config into /etc/cloud/cloud.conf.d/10_custom.cfg, removed everything from /var/lib/cloud and rebooted [13:24] http://pastebin.com/HK99AfNc [13:25] "final_message" was printed into logs, but htop wasn't installed and no packages were upgraded [13:26] eofs: what was the cli command you used? [13:27] rebooting as you suggeted should work . after removing /var/lib/cloud [13:27] pastebin (hint, wonderful command called 'pastebinit' is installable from ubuntu) your /var/log/cloud-init.log [13:36] eofs: reason I ask is that the update upgrade install pkg module defaults to loading in the config mode so you would trigger it with something like 'cloud-init modules --mode config' or something along those lines [13:39] odd, it seems to work now [13:39] launched new, clean instance, added my settings into /etc/cloud/cloud.conf.d/10_custom.cfg, removed /var/lib/cloud and rebooted [13:40] maybe I managed to "brick" by previous instance somehow [13:40] eofs: removing /var/lib/cloud could be problematic on some distros init systems too === rangerpbzzzz is now known as rangerpb [13:42] natorious, it shoudl be ok to do taht. [13:43] if not, i'd consider it a bug. things should be generally idempotent. [13:46] ok, cool. I did see some odd behavior with 0.7.7 when troubleshooting nic config on systemd by blowing away the /var/lib/cloud dir [13:47] iir I had asked that same q here a year or so ago and blowing away /var/lib/cloud wasn't the rec way of resetting at the time [13:50] smoser: harlowja: claudiupopa: 10 minute warning for meeting. :) [13:50] coreos-cloudinit seems to have easy to use cli: "coreos-cloudinit --from-file /path/to/file" [13:51] easier than removing some random folder and rebooting and waiting n-seconds for instance to come online again [13:53] eofs, well, you dont have to. [13:53] you can run a single mode again [13:53] cloud-init single --name=foo --frequency=always [13:53] aah... where's the documentation!? ;) [13:54] did something break in the latest release for CentOS 6? [13:55] https://gist.github.com/jimbobhickville/4114f51b55b04a2f4d4b [13:56] first bit is the exception that is thrown when trying to run cloud-init, the 2nd is the yum update output where it updated to the latest version. This was a fresh image built yesterday [13:59] jimbobhickville, it would seem that your 'requests' package is busted somehow [13:59] jimbobhickville: That _looks_ like a packaging problem with python-requests. [13:59] Hah. [14:01] smoser: harlowja: claudiupopa: Meeting? [14:01] this is all just from the official centos repos [14:01] Yes [14:02] jimbobhickville: https://bugs.centos.org/view.php?id=9139 looks similar. [14:03] ok. lets start a meeting. [14:03] thx Odd_Bloke [14:03] we'll just walk through open reviews quickly and then a open discussion [14:04] Odd_Bloke: looks like the suggested fix of cleaning up the leftover folder worked, thanks [14:04] jimbobhickville: \o/ [14:05] reviews at http://bit.ly/cloudinit-reviews-public [14:05] So no hangouts meeting? [14:06] oh. hm.. do you want hangout? i'd gotten to enjoy these in irc. [14:06] Not necessarily, no. [14:06] and some others had been showing up for them. [14:06] and are not on our hangout. [14:06] lets put that into open discussion :) [14:06] first review in my list is [14:06] https://review.openstack.org/#/c/220593/ [14:07] which is marked WIP [14:07] i know that Odd_Bloke and harlowja have talked some about taskflow [14:07] Yeah, I talked with harlowja as well regarding https://review.openstack.org/#/c/220095/ [14:08] this does add a requriement on taskflow, which generally speaking we'd like to avoid. so maybe in the commit message or somewhere, a justification for picking up that requirement woudl be nice. [14:08] especially since python3 version is not terribly easily available [14:08] i'll put such coments into review here [14:08] The question if we really need taskflow for this. [14:09] For instance, regarding the parallel discovery and execution, it might not be so easy to use it. [14:09] So I really like taskflow for the overall stuff. [14:10] It allows us to declare a graph of tasks and dependencies, and execute as we want (persisting between runs). [14:10] It supports the whole range of supported Python versions? [14:10] Well, that's something I want to bring up in general discussion. [14:10] It does not support Python 2.6. [14:10] But I'd like to have a discussion about why we support Python 2.6. [14:10] would /tmp be the best place for a taskflow db though? [14:11] wouldn't some distros blow away /tmp on reboot [14:11] all probably do [14:11] natorious: I would expect that to move to /var/lib/cloud. [14:11] Except windows maybe. [14:11] But that's a PITA for testing. [14:11] s/testing/manual testing/ [14:12] Because /var/lib/cloud either does not exist or is owned by someone inconvenient (i.e. root). :p [14:12] I believe RHEL 6.x still has Python 2.6 by default. I'm not sure about SLES 11 / 12. [14:12] Yeah, RHEL 6 is definitely still on 2.6. [14:12] its worth discussing. [14:14] we'll have to investigate the plausibility of RHEL 6 support with a newer python if we want to drop 2.6 [14:14] iirc sles 11 is using 2.6 as well [14:14] ie we really do need to have *some* supported path there. [14:14] Do we think that a new version of cloud-init is ever going to hit RHEL 6? [14:14] tpeoples: do you know about SLES 12? [14:14] its quite possible that it would not be in official archives of rhel6 [14:15] Odd_Bloke: if there were a critical new feature + lots of customer demand, the answer is "maybe". [14:15] Odd_Bloke: I would hope that to be the case too [14:15] but we have people who would want to use it there in their images (possibly on their official images for their users on public clouds) [14:15] that ^^ [14:16] did taskflow drop 2.6 support recently? It used to support it [14:16] smoser: I agree, and some companies may build cloud-init 2.0 RPMs for use on RHEL 6 to maintain the same level of cloud-init functionality across their private clouds regardless of the operating system in the image. [14:17] jimbobhickville, harlowja is sleeping [14:17] but he can answer that, and i'll follow up with him today [14:17] that coudl be an option also [14:17] jimbobhickville: Taskflow recently bumped its networkx requirement to a version of networkx that has dropped 2.6 support. [14:17] there ya go. [14:17] though, redhat doesn't have specific requirements going into base images and so if needed, they could add in their py 3 deps [14:18] explain ? [14:18] natorious, " redhat doesn't have specific requirements going into base images" ? [14:18] you're not gonna convince public cloud providers to install py3k in the cent6 images by default [14:19] smoser: I'm not aware of specific guidelines for a red hat base image per se. The python 3 dependency packages could also be pre-installed in the base images [14:19] ok. [14:19] so we do need to look more into this. [14:19] and see if there is some path to python versions from this decade in rhel6 [14:20] This sounds, to me, like there are a loooong list of people who could club together to backport cloud-init and its dependencies to Python 2.6, if they insist on supporting a version of Python that is EOL. [14:20] and sles [14:20] I imagine that networkx dependency issue was a mistake. openstack requires python 2.6 support last I checked and taskflow is trying to become an official library [14:20] ok. lets move along. this has been good discussion though. but i need to move.. to make another meeting :) [14:21] As an upstream, I'm not sure why we would take on the burden of supporting a Python version that is, I stress, END OF LIFE. :p [14:21] Anyway, to be continued. :) [14:21] Odd_Bloke, because we want to support an OS that is *not* END OF LIFE (for another 5 years ;) [14:21] next: https://review.openstack.org/#/c/220095/ [14:22] for that... anyone reading along here. [14:22] pelase read that spec that claudiupopa has written and comment on the review [14:22] make sense ? [14:22] * smoser will read today also [14:22] https://review.openstack.org/#/c/220536/ [14:22] that seems to me to be straight orward enough [14:22] the one thing that i would suggest is that '--log-to-console' is long to type. [14:22] --log=- ? [14:23] woudl that be possible , Odd_Bloke ? [14:24] ok. i'll comment on review. lets go on [14:24] https://review.openstack.org/#/c/220543/ [14:24] smoser: It's non-trivial so, yeah, let's continue that conversation in the review. [14:24] i'll just ack that now. [14:25] ok. and thats it. the only other one is my pip2distro... which i thin is pie in the sky, but i wish someone had. [14:25] so that i could do some thing like: pip-install-deps-as-seen-on-ubuntu-14.04 [14:26] or rhel6. or whatnot. to easily test in a similar environment to that you'd get with package installed dependencies. [14:26] so. open discussion.. [14:26] 2 things here. [14:27] a.) do people find this medium appropriate, or do we want to have some audio/voice enabled medium ? [14:27] i've been happy with this one... i want tog et a channel logger in here though at very least. [14:27] I prefer IRC, because it's more transparent. [14:27] I like this medium. [14:28] isn't ubuntulog2 logging the channel? [14:28] Yeah, and the fact that more people can chime in is also better. [14:28] And will scale better once we hit the $video_provider channel limit. :p [14:28] b.) ... shoot . what was this one ? [14:28] +1 on shoot. [14:29] Im fond of irc as well [14:29] well, i'll dig a bit on our py26 discussion. [14:29] please feel fre to ping me at any time here. [14:30] I think it might be worth blocking out an hour for this meeting. [14:30] smatzek, was right. [14:30] http://irclogs.ubuntu.com/2015/09/09/%23cloud-init.html [14:30] (He said, setting up Hangouts for his meeting) [14:30] that log is sufficient for me. [14:30] It would also be good to have a way of proposing topics etc. [14:31] So, I've read thru the hacking and spec docs. Not sure where to get started though. The spec mentions distro namespaces and datasources that don't exist. [14:31] agreed. [14:31] you have thoguths ? [14:31] So, for example, people can't forget what they were going to bring up. ;) [14:31] I don't, but I'm happy to take an action to go and find something. [14:32] natorious, yeah.. a getting started and list of things to do would be good/necessary. [14:32] we do have http://bit.ly/cloudinit-roadmap [14:32] bc the distro classes are already spec'd? Should I start hacking on some distro basics and datasources from scratch? [14:33] which is intended to be that. [14:34] like current master branch has an osys namespace which looks like it should be distro related? [14:34] right. [14:35] i do have to jump away for a minute. [14:36] for a while. so natorious you can continue with Odd_Bloke (possibly) or i can return to you in a while. [14:36] i think you're US time zone-ish, right? [14:36] smoser: yeah, CST [14:36] natorious: there are is a data source implemented already. [14:36] https://github.com/stackforge/cloud-init/tree/master/cloudinit [14:37] k, so all our current configs use ConfigDrive as a datasource and am looking forward to persistency whatnot. Would need to get that going to be able to test [14:37] think I saw a trello task for that [14:38] claudiupopa: is that something your actively working on or mind if I hack at it a bit? [14:39] No, I'm not doing any work with that right now, please go ahead and hack at it. :-) [14:43] cool deal. I might have a trello login somewhere [14:44] Apologies, was on a call. [14:44] Back now. [14:45] yeah, I can login and subscribe to trello tasks but, can't assign [14:46] What's your trello id or email? I'll add you on the board. [14:46] nathan.house@rackspace.com [14:47] ty [16:02] hrm… cloud-init should still be writing /var/lib/cloud/data/result.json on completion right? [16:03] jimbobhickville, /run/cloud-init/result.json [16:05] ah, the path changed recently? [16:05] that file doesn't exist either [16:24] jimbobhickville, /run/cloud-init/ shoudl be there. [16:28] the folder does not exist. maybe rackspace overrides that? [16:28] result.json used to be in the path I pasted up until I just updated our image and now it no longer seems to be generated at all. /var/log/cloud-init.log and /var/log/cloud-init-output.log both indicate that cloud-init completed === jor_ is now known as jor [16:57] ooh, missed this error: http://mirror.rackspace.com/centos/6/updates/x86_64/Packages/libXfont-1.4.5-5.el6_7.x86_64.rpm: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" [16:57] jimbobhickville what u doing here [16:57] ha [16:57] lol [16:57] jimbo [16:57] haha, wrong room on that last paste [16:57] lol [16:58] so, nevermind, cloud-init is still the default installed version on this image because the yum update failed when I built it. [16:58] sooo hmmm, good point on 2.6 and taskflow, arg, didn't think about that [16:58] thus no output of the results.json [16:58] jimbobhickville 'taskflow is trying to become an official library' [16:58] ehmmmm [16:58] 'trying'''' [16:58] lol [16:58] :-P [16:59] is it official now? I haven't paid as much attention lately [16:59] i think its official as u can get [17:00] obamba didn't sign it into law though [17:00] but i'm working on that [17:00] harlowja: Well, I'm trying to convince everyone to drop Python 2.6 as a requirement. [17:01] Because this problem is only going to get worse and worse. [17:01] And also anyone still shipping Python 2.6 needs to go and sit in a corner and think about what they've done. [17:01] (Whilst paying people to backport modern Python software for them) [17:05] Odd_Bloke oh, i'm probably the person asking for 2.6 support :-P [17:05] but maybe, it can be done, ha [17:05] harlowja: WHYYYYYYY [17:05] and just say use 0.7.x for rhel6 [17:06] mainly rhel6 + yahoo will probably be around for a while [17:06] but i think it might be ok to just say 0.7.x is the last rhel6/python2.6 stuff, [17:06] cern i think also even wanted support for rhel5 (which uses 2.4 python) [17:06] I don't understand the person who needs to run RHEL6 but is also happy to run something from outside of the RHEL6 repos as root. :p [17:06] some cern guy asked me at the summit about that [17:07] i think i told that cern person to go talk to smoser ha [17:07] * harlowja didn't want to touch that with a stick, lol [17:07] (Furthermore, I don't understand why that person wouldn't also be happy to install a modern Python also from outside of the RHEL6 repos :p) [17:08] Odd_Bloke ya, its possible, and probably we should just do 2.7 and i'll figure out what to do about the yahoo stuff (which i don't think will be a big issue on my side) [17:08] vs making all your lifes painful :-P [17:08] i'll take one for the team, lol [17:09] Well, there were other people at the meeting earlier (thanks for showing up BTW ;) who also didn't like the sound of dropping 2.6 support. [17:10] hmmm, meeting [17:10] u guys still have that to early, lol [17:11] Odd_Bloke but jimbobhickville knows some taskflow, so he can represent a little :-P [17:11] good ole jimbo [17:11] ha [17:11] Odd_Bloke, i agree with above. [17:12] er... sort of [17:12] i'll let u smart people decide, i think i'd be ok with dropping 2.6 and i'll deal with it here === alexpilotti_ is now known as alexpilotti [17:12] 0.7.x for rhel6/python2.6 and thats fine i think, for the time being at least from my side [17:12] i'd expect someone who really wanted new software on rhel6 to be fine to build their own python (or get it from some source they trusted) [17:13] smoser agreed, yahoo can/will do that if needed (and already does some of that anyway) [17:13] or just https://wiki.centos.org/AdditionalResources/Repositories/SCL [17:13] which provides Python 2.7 (python27) [17:13] *although its a PITA to use imho, but whateva [17:14] the use case which woudl warrent 2.6 support is public cloud use [17:14] whats this public thing u talk about [17:14] lol [17:14] if someone makes an image available on a pbulic cloud of something called either "centos" or "rhel", then i'd expect that they'd need very-close-to-fficial python [17:15] Would someone want a new version of cloud-init in their "assumed to be normal" RHEL6/CentOS 11 image? [17:16] CentOS 11? [17:16] ;) [17:16] that may arrive in year 2100 [17:16] Um, *SLES. [17:16] $enterprise_linux_distro $old_version_number [17:16] :) [17:20] ya, so i'm torn here, i get both of the views on this [17:21] and taskflow also dropped 2.6, because pretty much all of openstack dropped 2.6 (including libraries that taskflow uses, which means that taskflow also has to drop 2.6 due to the transitive of this...) [17:21] *transitive nature of this [17:21] now one could make a minature taskflow, if they so wanted [17:22] but that sorta sucks as a solution imho [17:22] openstack dropped 2.6 ? [17:22] ya [17:22] what is the rhel 6 support case then ? [17:22] for openstack, surely redhat supports openstack kilo or liberty on rhel6 [17:23] right? [17:23] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048999.html [17:23] 'The application projects are dropping python 2.6 support during Kilo' ... [17:23] libraries dropped it this cycle [17:23] sooo smoser afaik, there is no kilo + rhel6 support [17:23] basically from what i know its 'go use rhel7' [17:23] harlowja: yep [17:23] wow [17:24] which afaik, rhel7 is/was always the recommended RDO 'solution' [17:24] never rhel6 [17:24] yeah. [17:24] https://www.redhat.com/archives/rdo-list/2015-May/msg00209.html [17:24] ya [17:24] my team (and other companies, cern, godaddy) gets to have the fun time of actually moving rhel6 -> rhel7 [17:24] its super-fun :-/ [17:24] especially on hypervisors :-/ [17:25] it helps that i also maintain http://anvil.readthedocs.org/ but its still a pita [17:27] but afaik, no kilo and beyond for rhel6 (from redhat at least) [17:27] those companies that used openstack on rhel6 are on there own... [17:29] * Odd_Bloke --> EOD [17:29] ok. well, then for rhel i'm kind of convinced. [17:30] Final thought: we should consider having this sort of conversation on some sort of ML so that people don't have to be temporally present to have input. :p [17:30] Odd_Bloke agreed [17:30] agreed [17:31] isn't there one that is setup for launchpad? [17:31] But that is a discussion for another time when we N meet again. :p [17:31] *for/by launchpad [17:31] https://launchpad.net/cloud-init/+topcontributors crap, no longer #2 [17:31] lol [17:31] damn u Odd_Bloke damn u !!! [17:31] lol [17:34] * harlowja guess i've been slacking, ha [17:35] interesting, didn't realize openstack was dropping 2.6 support. we have to support centos6 because all the hortonworks stuff only just now started offering centos7 support and we support the most recent two versions. Until they release another version and we can drop the last centos6-only version [17:35] which is like 6 months out most likely [17:35] jimbobhickville cool, good to know [17:35] ya, openstack dropped it like a year ago (for the projects, libraries dropped in last 6 months) [17:35] we do install py27 as well, though, so we could probably work around it if cloud-init can be configured to not use the system python install [17:36] it should be able to be configured that way [17:36] depending on how u guys build py27 [17:36] and how u want to install cloudinit (rpm?) [17:36] both are rpm-installed [17:37] k [17:37] no cloud-init-env.sh we can force the PYTHONPATH in or something? [17:37] not sure, probably a few ways to pull it off [17:37] jimbobhickville, the goal would be to be virtualenv installable. [17:37] anyway, we can probably just stick with the current version anyway, and rhel6 won't ship a version that requires py27 [17:37] so yeah, fairly easily relocatable. [17:38] do we have any offical RH person involved here? [17:38] the one thing that is most annoying for that at the moment is python-yaml. i *think* its the only thing that isnt pure python [17:38] (aka, not me) ha [17:38] smoser i think the python-yaml library works in pure python (but slower) [17:39] it just has 'speedups' that it can compile in [17:39] probably can tell it to stop doing that [17:39] somehow [17:39] you can do compiled modules in a virtualenv anyway [17:39] (at least I thought you could, pretty sure we do) [17:39] from http://pyyaml.org/wiki/PyYAML 'both pure-Python and fast LibYAML-based parsers and emitters. ' [17:40] u can probably tell it to just use the pure-python one (or it should be smart and fallback) [17:40] harlowja, yeah, i just tried that and verified. [17:40] cool [17:41] http://paste.ubuntu.com/12322352/ [17:41] cool [17:41] seems like it does a reasonable job of figuring it out [17:41] http://svn.pyyaml.org/pyyaml/trunk/setup.py has a interesting 'LIBYAML_CHECK' in it (some c code, ha) [17:41] so i guess thats whats being used [17:43] anywayssss, so i'll let u guys ponder over the py26 question [17:43] i'll be ok with it, and will deal with whatever the consequences are here at y! (nothing to much expected that i can think of right now, ha) [17:49] we'll be fine here as long as the new version doesn't show up on the rhel yum repos [17:50] (for rhel6 I mean) [18:24] smoser somehow i got emailed about this, https://github.com/number5/cloud-init/commit/7bde163d344737b99c594ae1d2cdcb3e31d45197#commitcomment-13125937 [18:24] lol [18:24] not sure whats up with that :-P [18:25] someone complaining... [18:26] he lost me at "nobody writing code in 2015" [18:26] :) [18:26] so many logical fallacies in one small statement [18:26] good think i wrote it in 2012 [18:26] :) [18:27] that's what you should respond. just that [18:27] lol [18:28] jimbobhickville ok i responded [18:28] and i left a hamburger [18:28] ha [18:29] hopefully meets your expectations as far as response, lol [18:29] bb [18:32] a++ would troll again [19:03] lol [19:16] should the configdrive source live in the openstack namespace? [19:17] it looks like alot of the base can be shared between the two etc [19:17] or would having them in their own be better bc of configdrivenet? [19:18] natorious you can look 0.7 to see how that was done [19:18] harlowja used a lot of common code there. [19:21] yeah, via helpers [19:22] nothing other than the openstack helper mod ever made it in there though [19:22] "in there" ? [19:23] almost seems like configdrive should live in the openstack ns. But, if other clouds use it outside of openstack, not sure it would make sense [19:23] yeah so like 0.7.7 has sources.helpers.openstack [19:23] but nothing else in sources.helpers [19:24] i'd consider configdrive to be in openstack namespace. [19:24] even if someone else used it. they'd be mimicking openstack. [19:24] if i understand what you're asking [19:25] k, right. Like as in should configdrive and httpopenstack share a base [19:26] sure [19:56] doesn't configdrive and httpopenstack share a base? [19:56] * harlowja thought they did