[13:49] <natorious> morning
[13:51] <smoser> good morning sir.
[13:51] <natorious> I'd noticed the decorator properties in the http ds are not in the parent class.  Is that intentional?
[13:53] <natorious> also noticed what you were referring to w/ network config returning and I'll fix that in the existing merge req
[13:54] <natorious> re prop decorator, I was thinking that would change the method signature and therfore not inherit/override
[14:03] <smoser> ok.
[14:03] <smoser> cloud-init meeting
[14:03] <claudiupopa> hi.
[14:03] <smoser> hello natorious smoser claudiupopa
[14:03] <smoser> jgrimm,
[14:03] <smoser> Odd_Bloke,
[14:03] <jgrimm> o/
[14:03] <natorious> \o
[14:04] <smoser> my bit.ly url for cloudinit-reviews somehow busted. :-(
[14:04] <smoser> so
[14:05] <smoser> http://bit.ly/cloudinit-reviews-public
[14:05] <smoser> i finally got around to reading claudiupopa's proposal at https://review.openstack.org/#/c/220095/ yesterday
[14:06] <smoser> talked with him a bit.  i think we agree that openstack's config-drive and MD are odd fellows.
[14:06] <smoser> natorious, wonder if you have thoughts on that.
[14:06] <smoser> would xenstore on rackspace still be a possible datasource ?
[14:06] <natorious> yea, I don't see why not
[14:07] <natorious> the image would have to have some baked in deps to be able to access it like a store
[14:07] <natorious> but thats essentially how the openstack guest agents use it today
[14:07] <smoser> it woudl be the preferred one there ?
[14:08] <smoser> or do they now have openstack MD everywhere.
[14:08] <natorious> likely, yeah.  Citrix makes it dead easy as a preferred
[14:08] <natorious> were doing http and configdrive too
[14:08] <smoser> citrix ?
[14:08] <natorious> XenServer
[14:09] <smoser> ok.
[14:09] <smoser> ok. so... how about this.
[14:09] <smoser> the one topic we have from last week was python2.6 .
[14:09] <smoser> and Odd_Bloke quickly pointed out that there are official python2.7 sources for centos and for redhat
[14:10] <smoser> in 'SCL's
[14:11] <smoser> that still leaves me sles to look at, but i went and built some images last week and have them in a local cloud so i can easily poke around.
[14:12] <smoser> so i think we can say 2.7
[14:12] <smoser> then i guess move on./
[14:12] <natorious> um
[14:13] <smoser> um ?
[14:13] <smoser> as in you dont like that?
[14:13] <natorious> to clarify, the products I'm currently working on dont use xenstore
[14:13] <natorious> at all
[14:13] <natorious> dunno the full context
[14:13] <smoser> does rackspace have any that to do your knowledge?
[14:14] <natorious> yea, their public cloud
[14:14] <natorious> this is how they mine that source too
[14:14] <natorious> https://github.com/rackerlabs/openstack-guest-agents-unix
[14:15] <natorious> so right now to get cloud-init to work w/ this guest agent
[14:15] <natorious> you have to tweak the boot order and deps
[14:16] <natorious> bc cloud-init pretty much requires networking to function properly and unless the guest agent has configured it, it wouldn't work
[14:17] <smoser> right. 0.7.x definitely does.
[14:17] <natorious> we were managing that ordering outside of the pkgs though
[14:17] <smoser> that is a primary goal to be addressed.
[14:17] <natorious> k, cool
[14:18] <smoser> i kind of talked a bit to the plan for that in my response to claudio
[14:18] <smoser> on boot, we have something that goes looking for "network config sources"
[14:19] <smoser> that thing blocks boot until it decides how your networking shoudl be configured.
[14:19] <smoser> it configures it, and then lets boot continue.
[14:19] <smoser> later in boot (when network comes up)
[14:19] <smoser> cloud-init again goes looking for a datasource for user-data, meta-data ... other things.
[14:20] <natorious> makes sense
[14:20] <smoser> i'll start trying to write this better into a spec
[14:20] <smoser> it is tricky
[14:20] <smoser> because figuring out what networking is supposed to be is not easy
[14:21] <smoser> and figuring out if this is config you've found should be applied (and possibly overwrite the user's config) is not easy either. ie, if this was a reboot.
[14:21] <smoser> honestly, ditching the "snapshot without clean" thing... woudl make things so much easier.
[14:25] <smoser> natorious, i'll look back above at your questions here in a minute.
[14:25] <smoser> and will try to write down my theory on boot order for cloud-init into a spec for review.
[14:26] <natorious> ty
[14:35] <natorious> I'd like to get this WIP configdrive merge request in today and have a few low fruit hangers left
[14:36] <natorious> or we still waiting for discussion?
[14:37] <smoser> natorious, i think we're done with meeting
[14:37] <smoser> ok... so wht do you want me to look at
[14:37] <natorious> oh, lol
[14:37] <natorious> so is the taskflow bit a + now that 2.7 works?
[14:38] <natorious> I'm finishing load and _get_data for the cd ds and I'll submit it as a WIP.   There were some properties defined in the http ds that were not defined as properties in the base
[14:39] <natorious> wasn't sure if that was intentional
[14:40] <smoser> wrt taskflow, i dont know. still need to lok at that. it has quite a dependency chain.
[14:40] <natorious> also was hoping to chat a bit about BaseOpenStackSource.network_config
[14:41] <smoser> and my virutal-env pip install of taskflow jsut failed here... doign a c compile
[14:42] <smoser> i'll see if we can't strike that ctaskflow conversation up with Odd_Bloke later. who appears non-present.
[14:42] <smoser> ok. your questions. you want to go down the list of what you wrote before meeting ?
[14:42] <natorious> really its just _is_password_set in the  http ds is set as a property but the BaseDataSource._is_password_set is not
[14:43] <jgrimm> smoser, are you cancelling next week meeting?  or still planning to have while you are travelling?
[14:44] <smoser> well, yeah, i'm not going to be there.
[14:44] <smoser> but willsend mail to that affect and say that it can occur in my absense.
[14:45] <jgrimm> k
[14:46] <natorious> and the network_config bit which w/ network_json being its own format, should we still plan on returning the json data in those cases and the file content in the other?
[14:46] <natorious> like type check on the receiving end whatnot?
[14:47] <smoser> i think it shoudl be a property in the base class.
[14:47] <smoser> as we use it as one in the tests
[14:48] <natorious> ah right, I'll include that change in here then too
[14:48] <smoser> natorious and "file_content" ? you mean /etc/network/itnerfaces file ?
[14:48] <natorious> yea
[14:50] <natorious> the projects I'm working on are moving away from that to using network json but the way the ds classes are modeled would mean network_config could then return either or
[14:50] <natorious> just want to make sure that was acceptable
[14:50] <smoser> the end goal in my head is for cloud-init to read that network_json from its "network config source" (which here is an http source... see the tricky-ness of network config sources ? )
[14:51] <smoser> and then turn that into an interneal representation of networking configuration and then render it.
[14:51] <natorious> right, so dhcp to static
[14:51] <smoser> since we have multiple different formats we're going to have to read.
[14:52] <smoser> network_json, /etc/network/interfaces, ec2 metadata format ..
[14:52] <natorious> if the ds class is to process each, its going to take me a bit longer on this
[14:53] <smoser> well, dont worry about "rendering" the network config for now.
[14:54] <natorious> k, so I'll just return it as is and look at either processing it outside of the ds or add to it when I get there
[14:54] <smoser> just have the datasource fetch it. have it available. and some future "render networking" thing will take that as input and do its job.
[14:55] <smoser> yeah. i think so.
[14:55] <natorious> for the configdrive ds there were a few base methods that didn't make sense too. Like post_password and is_password_changed
[14:55] <natorious> the base doesn't raise an exc so there could be unexpected results down the road
[14:56] <smoser> i think NotImplementedError makes sense at least initially
[14:57] <natorious> and thats all I got for now.  Will try and get this w/ some tests in today sometime.  I'll look at some network config bits after this too.  Hopefully get something to test w/ :)
[14:57] <natorious> k
[14:58] <natorious> where are you traveling to?
[14:58] <smoser> seattle next week.
[15:00] <natorious> ah sweet.  If you all end up going to the Austin, TX OpenStack Summit 2016, we should get up for sure
[15:00] <natorious> I live an hour away from Austin
[18:20] <smoser> claudiupopa, what would you use to render your specs/<spec>.rst  ?
[18:25] <harlowja> smoser https://pypi.python.org/pypi/restview
[18:25] <harlowja> what i do is
[18:25] <harlowja> restview -l :5000 specs/
[18:26] <harlowja> the open a webbrowsr @ localhost:5000
[18:26] <harlowja> and bam
[18:26] <harlowja> 'Every time you reload the page, restview will reload the document from disk and render it. This is very convenient for previewing a document while you’re editing it.' is nice
[18:27] <smoser> thanks harlowja
[18:27] <harlowja> np
[18:36] <claudiupopa> Aaa, cool, didn't know about that, thanks.
[18:36] <harlowja> its pretty nice
[18:36] <harlowja> what i use for all my rst specs stuffs
[19:12] <smoser> i'm guessing there are other tools that do this, and you will just laugh at me, but i had 'venv' to do things like this.
[19:12] <smoser> https://gist.github.com/smoser/2d4100a6a5d230ca937f
[19:12] <smoser> then i just have a 'restview' file in my ~/bin/
[19:12] <smoser> #!/bin/sh
[19:12] <smoser> exec venv restview restview "$@"
[21:07] <harlowja> smoser cool, no idea, i have a tool that looks for a .venv on every 'cd' and tries to source it, and on leaving that directory exits the venv
[21:07] <harlowja> that way i can have each repo i work on have a different venv, and just cd .. and all that will enter/exit it
[21:08] <harlowja> https://gist.github.com/garyjohnson/394c58e22a2adfa103e2 and similar
[21:08] <harlowja> various ones of those around