16:00:00 #startmeeting OpenStack-Ansible 16:00:01 Meeting started Thu Jul 7 16:00:00 2016 UTC and is due to finish in 60 minutes. The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:04 o/ 16:00:05 The meeting name has been set to 'openstack_ansible' 16:00:10 ooh, i hit it right on 11:00:00 :) 16:00:13 Hello 16:00:19 #topic Roll call 16:00:19 Nice job mhayden 16:00:21 o/ 16:00:22 o/ 16:00:25 o/ 16:00:25 o/ 16:00:28 or perhaps i should have said 16:00 :P 16:00:31 you're the best mhayden. 16:00:37 congrats mhayden you're as good as a swiss watch :D 16:00:37 * mhayden hugs andymccr 16:00:41 o/ 16:00:43 o/ 16:00:55 o/ 16:01:02 howdy ametts 16:01:20 * ametts waves 16:01:38 \o/ 16:01:47 o/ 16:01:50 o/ 16:02:03 \/°\ 16:02:10 . 16:02:20 bgmccollum: You doing the worm there? 16:02:31 lol 16:02:44 o/ 16:02:51 okay, got a good crows here 16:02:57 #topic Action items from last week 16:03:08 the only i found was for odyssey4me to dig into Liberty/Mitaka releases 16:03:15 done :) 16:03:23 well, fantastic! 16:03:44 #topic Mid-cycle Planning 16:03:46 boom! ahead of the curve 16:03:56 i saw we had an agenda taking shape there in the etherpad 16:04:10 #link Mid-cycle etherpad https://etherpad.openstack.org/p/osa-midcycle-newton 16:04:36 * mhayden nudges galstrom to add himself into the etherpad 16:04:54 mhayden i saw the nudge earlier.. roger wilco 16:05:05 everyone: if you have input on the agenda, please be sure to add it there 16:05:30 Can we time box day 1 a bit more please - rather book work session time slots for day 2... let's try and keep day 1 for status updates and identifying issues to resolve in the work sessions. 16:05:31 i have the main room booked, and i'm working on getting a getaway room or two available for breakouts if needed 16:05:59 the $9/night hotel discount requires a bunch of paperwork, which i can do if the group thinks it's worth it 16:06:09 mhayden meh 16:06:17 * mhayden shuffles papers 16:06:54 mhayden: i'll probably have to book through corporate travel anyway 16:07:10 average high temp in San Antonio is 101.5F / 38.6C so prepare yourself :) 16:07:17 ouch 16:07:21 but the building is ice cold year round, so again, prepare yourself 16:07:24 :) 16:07:37 So... like... jeans with a swimsuit on underneath? 16:07:43 I just added a section for the outing, day and food choices. 16:07:52 Ohhhh thank spotz ! 16:07:53 Does anyone know of a venue that has a pool and poolside bar. I'd like to propose that be the location for after work session R&R. 16:07:54 thanks* 16:07:58 ah yes, if you have input on foods, please help spotz! 16:08:05 +++ odyssey4me 16:08:10 should we discuss and takes decisions on long term matters? 16:08:17 i have a kiddie pool and a hose 16:08:18 like discuss what we mean about stable branches 16:08:48 or bring serious upgrades from version x to z 16:08:50 and we put galstrom_zzz to sleep 16:08:51 mhayden: dude I love those 16:09:03 I'm probably going on a limb here :D 16:09:27 evrardjp: you wanna toss that into the etherpad 16:09:42 evrardjp while the mid-cycle should be work session orientated rather than ideas orientated, I wouldn't mind trying to set aside some time for us to pitch longer term strategies 16:09:44 before tossing, just asking about the general ideas 16:09:58 i always like talking long term strategy 16:10:03 I agree with odyssey4me 16:10:13 this is kept for later then 16:10:17 might be worthwhile to take a quick dive into what other similar projects are doing to see if we can learn from them 16:10:18 stuff that can perhaps be discussed more between N3 and the Summit, and hopefully finalised at the summit 16:10:26 I'll add containers CoW on it 16:10:39 evrardjp: i'm interested in that topic 16:10:39 odyssey4me: could come out to Gruene and have dinner (wine/beer maybe bar) next to the river but it'll be a 30 minute drive out. Or the Riverwalk? 16:10:52 yeah, please propose a session evrardjp - perhaps one on upgrades too 16:11:00 yup that's linked 16:11:13 we should have plenty of locals with cars, so traveling to an evening event shouldn't be a big deal 16:11:19 and we have uber/lyft here 16:11:46 anything else on the mid-cycle for now? 16:12:51 If folks need a ride I can drive. 16:12:55 same here 16:13:14 we can sort the transportation stuff out when everyone's here 16:13:19 ++ 16:13:23 anyone object to moving to the next topic? 16:13:31 ++ next topic 16:13:44 #topic Backport of OVS work to stable/mitaka 16:13:46 AND THEN! 16:13:48 * mhayden passes the mic to automagically 16:13:58 Huh…did I have something on the agenda 16:14:07 automagically: WE'RE WAITING! 16:14:25 Ah, that backport agenda item was discussed last week 16:14:29 No need to discuss today 16:14:32 oh nice 16:14:35 I have the info/feedback I need 16:14:39 boom! handled. 16:14:41 good stuff 16:14:44 man, we're on our game today 16:14:50 either that or i'm working off bad data :) 16:15:02 #topic Removal of venv_enabled switches 16:15:07 logan-: anything on this one? 16:15:22 i saw that the changes for neutron were already proposed 16:15:31 it has a major impact on how I deploy for 2 reasons: 16:15:54 #link https://review.openstack.org/#/q/topic:bp/only-install-venvs 16:16:38 1) http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2016-02-05.log.html#t2016-02-05T03:57:38 it increases my compute node image size by 25% 16:16:38 2) the upgrade implications of venvs (overwriting all files in the venv, rather than pulling only the necessary pip upgrades) is a big problem for me. i need disk to be as static as possible 16:16:51 so unnecessary overwrites of files takes them out of the compressed read only image and into uncompressed ram 16:17:16 so I relied heavily on the configurability of OSA and opted to deploy without venvs on my compute nodes 16:17:44 is there a major need requiring that this functionality be removed? 16:18:00 logan- mainly because it's code overhead, and an untested path 16:18:05 The belief was that no one was using it, and it unnecessarily complicated the roles 16:18:32 #link spec -> https://specs.openstack.org/openstack/openstack-ansible-specs/specs/newton/only-install-venvs.html 16:18:34 it may be plausible to make an exception for some roles - but it also may be useful to get a little more creative there to find a better solution 16:19:11 it seems like containers with overlayfs would give some space back 16:19:15 I just found the spec about 30 minutes ago when the patches start coming, sorry! I would have commented earlier 16:19:17 I'd like to see if it's possible for us to find a way to reduce the overhead, and also to remove unnecessary file overwrites. 16:19:23 also the pain from going kilo->liberty, had to destroy containers to clean up and resolve errors after moving between system and venvs installs 16:19:25 we could cleanup the code to be a one liner thing, but we still have to test it at some point 16:20:06 logan- something to note is that venvs were implemented in the first place due to interference from host apt packages, specifically on compute nodes 16:20:38 i'm curious if 2 could be resolved by pip installing modules inside the venv instead of overwriting the whole thing 16:21:11 logan- so the only reason to ever overwrite it is if the venv changes, which happens per tag 16:21:42 And we have the pip install inside the venv option, its just not easily used instead of the venv unzip right now 16:21:58 logan- I'd like to perhaps discuss your use case in a bit more detail in the channel after the meeting. I think we can find a solution here. 16:21:59 Its a fallback, rather than a deployer selectable choice 16:22:17 would this upgrade an existing venv as long as you're not using the prebuilt tar? https://github.com/openstack/openstack-ansible-os_nova/blob/master/tasks/nova_install.yml#L205-L223 16:22:27 I think we need to have a proper analysis of logan- 's case, but I'm not sure we can do that in the timeframe of this meeting 16:22:38 and keep nova_venv_bin consistent 16:23:19 i agree with evrardjp 16:23:21 yes jmccrory if that was run against existing venvs that might work 16:23:56 let's prepare the work with logan- 's on the openstack-ansible chan, and then come up with a plan for approval for next meeting? 16:23:59 I see the task right above that appears to do this 16:24:00 Ok thanks. I wanted to raise the concern but I just found this 30 minutes ago so I'm still sorting thru possible workarounds and gauging the impact. Thanks for the insight 16:24:17 Thanks for catching it logan- 16:24:22 Better to deal with it now than after 16:24:24 awesome feedback logan- Looking forward to finding a way to solve for your use case 16:24:29 palendae: +1 16:24:31 ++ 16:24:48 and +1 on automagically too 16:25:00 alrighty, are we good on this topic for the moment? 16:25:06 automagically: ++ 16:25:27 yep mhayden. thanks! 16:25:35 sweet! 16:25:40 thanks for bringing that up, logan- 16:25:52 #topic Ubuntu 16.04 LTS support 16:26:07 #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04 16:26:40 anything critical to bring up here? anyone need help? 16:26:57 i've found that no one is working on horizon and ubuntu1604. 16:27:03 i would like to try 16:27:07 ++ 16:27:11 .doit() 16:27:23 I’d appreciate reviews on https://review.openstack.org/#/c/338541/ from the neutron experts 16:27:24 eil397: get on that thing! :) 16:27:27 eil397, Go for it 16:27:29 note that some changes were done to support multi-os without really going through with everything... so please lookout for more cleanup like was needed in https://review.openstack.org/330231 16:27:38 ok.will start 16:27:44 DVR cool 16:27:55 eil397 assign yourself in the etherpad so that everyone else knows that it's taken 16:28:25 I live dvr, but I had a vision of deploying known network configs 16:28:48 odyssey4me: ok. will mark it in doc 16:28:50 so, possibly ml2.lxb.dvr ml2.ovs.dvr 16:28:50 michaelgugino: Would appreciate your comments on that then 16:29:22 #topic Open floor 16:29:27 interesting idea 16:29:29 ovs only I guess :D 16:29:30 (since we were already opening it up anyway) 16:29:36 evrardjp yep, unfortunately 16:29:54 ie, let's track the deployment scenarios that are documented: http://docs.openstack.org/mitaka/networking-guide/deploy.html 16:30:17 michaelgugino: Oh, agreed there, but I think that is more of a config doc challenge for the neutron role docs 16:31:02 automagically michaelgugino yeah, it'd be great to simply flip a switch to enable each scenario - but a good starting point would be to figure out the known working config for the scenario 16:31:09 from there the next step is to optimise it 16:31:27 well, similar with what we did with ovs vs lxb, specifying the 'type' I think would be handy, but perhaps those things don't need to be together 16:31:31 odyssey4me: The problem is that selective hash override stinks for deployers 16:32:03 what do you mean? 16:32:55 evrardjp: Overriding a var like neutron_plugins[‘ml2.lxb’].driver_firewall 16:33:19 my question is, do you think it's inconvenient, or it's good? 16:33:32 And also doesn’t work with the deprecation filter 16:33:36 I didn't understand the point we're trying to solve here 16:33:41 I think its inconvenient 16:33:46 automagically yeah, the intend with the hashes is not to require that 16:34:03 ansible 2 | combine? 16:34:07 I think it's fine, for the vast majority of deployments, those settings are going to be adequate 16:34:38 the idea is that something must be activated somewhere else, as michaelgugino has suggested, then the hash is used to flip all the switches needed elsewhere 16:34:58 if anything needs a tweak var, then that should be a non-hash var that perhaps can be used by the hash 16:35:55 Good feedback, I think I get the gist of it 16:35:55 I don't have a problem making people specify the whole hash either, it's not a huge deal. But most variables can be mined from other values inside the defaults file 16:36:19 I’ll finish testing what I’ve got for DVR now and perhaps propose an adjustment 16:36:55 we can do a similar thing like we did in nova https://github.com/openstack/openstack-ansible-os_nova/blob/master/tasks/nova_post_install.yml#L16-L26 which takes a hash and converts the keys into set facts? 16:37:17 regarding the "do all the things hash table topic" 16:37:34 I definitely don't think we should do that if at all possibke 16:37:35 as evrardjp I think the hash override pain for deployers will be mitigated by the combine filter 16:37:46 as evrardjp said* 16:38:12 I vastly prefer a method similar to this one: https://github.com/openstack/openstack-ansible-os_neutron/blob/master/defaults/main.yml#L93-L100 16:38:16 yes, we can think of recursive combine and union filters 16:38:35 michaelgugino: these aren't mutually exclusive :D 16:38:41 or I missed the conversation 16:38:55 what is the decision to be taken? 16:39:15 considering our current stance is to maintain 1.9 and 2.1 compatibility this cycle, those aren't really options just yet... 16:39:28 evrardjp: In testing the combine and union filters I've found that they're kinda incomplete. w/ this test https://github.com/ansible/ansible/pull/12555 combine resulted in missing data. 16:39:37 but I'd like us to discuss how much value that brings us at the mid cycle 16:39:40 I would rather see the variables written out instead of generating facts dynamically 16:39:50 michaelgugino: +++ 16:39:53 sorry its a long comment / discussion but at the bottom i mentioned the results of using combine 16:39:54 cloudnull: good that you tested that 16:40:19 note "Upon inspection of the rendered files it seems the recursive combine filter results in missing data." 16:40:53 we seriously need to do a better liaison with ansible guys :D 16:41:05 those variables could be written like this: https://github.com/openstack/openstack-ansible-os_neutron/blob/30439c262c1d991a4243a66ea505dd032d4f59a2/templates/plugins/ml2/openvswitch_agent.ini.j2#L13 16:41:23 ++ good to know cloudnull 16:41:26 I mean how long for config template... We are close to one year now 16:41:31 but that's another topic 16:41:39 yeah, I'm quite fond of the relatively simple mechanism we're using in the os_neutron role and think we can do a lot more of that to cleverly apply defaults and allow tuning where appropriate... with the fallback of the config override always being an option for deployers 16:41:59 evrardjp: i think im going to abandon that commit. they seem impossible to work with being that I'm not apart of their club. 16:42:31 that's the saddest story I heard today cloudnull 16:42:33 cloudnull The fact of the matter is that we have a plugin which we're happy to carry and is easily shared with other projects that want to use it. 16:42:50 :( 16:42:55 its just easier to carry a core module until we get someone part of their good'ol boy network. 16:43:03 odyssey4me: ++ 16:43:10 we could talk to the community folks at ansible for some help 16:43:15 yeah, we can ship that module to another repo, put it in galaxy, and fetch it with galaxy 16:43:29 when it's gonna be the first one ever used, maybe they will think about it 16:43:42 cloudnull: would you wanna pair up on reaching out to ansible? 16:43:44 mhayden, It seems near impossible to provide patches to Ansible without being at Ansible, Inc :( 16:43:49 mhayden: sure. 16:43:56 palendae: i don't give up easily 16:44:03 Fair enough 16:44:04 you wlil in a year or so 16:44:07 And you know Robin ;) 16:44:13 He's Major!!!:) 16:44:17 #action cloudnull and major to reach out to ansible about merging some things 16:44:21 mhayden: I agree with you, we should try 16:44:23 spotz: pfft 16:44:30 put me in 16:44:36 anything left for the mtg today? we have 15 min left 16:44:39 evrardjp: ok 16:44:42 robin and greg are on the community side. sadly ansible core is not exactly tied to the community side. 16:44:44 yeah, I think their concerns are valid but I'd like to see them make a bit more effort to find common ground. So far that has not been done. 16:45:04 cloudnull, Yeah. There seem to be some internal communicaton issues there 16:45:05 cloudnull do you have the PR link handy, for the context of others 16:45:11 if we could get an extension for action plugins into ansible extras it'd be a lot easier. 16:45:28 https://github.com/ansible/ansible/pull/12555 16:45:48 cloudnull / evrardjp: just started a thread via email 16:45:52 oh, silly me - it was linked before... 16:45:54 good 16:45:56 any other topics to discuss? :) 16:45:58 crazy seeing how receptive lxc was to PRs compared to ansible 16:46:01 nothing to see here... move along citizen :p 16:46:04 https://github.com/ansible/ansible-modules-core/pull/2171 16:46:10 https://github.com/ansible/ansible-modules-core/pull/1517 16:46:55 jmccrory: that was in the community modules. 16:47:05 acceptance into extras is a lot easier. 16:47:07 okay, i'll close this up now unless there are any objections 16:47:38 going once 16:47:47 cloudnull: oh i mean the few patches odyssey4me submitted to lxc/lxc 16:48:01 twice 16:48:08 closed! 16:48:15 ah. yea. i dont believe they have a club quite yet. :) 16:48:18 thanks everyone! 16:48:21 #endmeeting