16:00:00 <mhayden> #startmeeting OpenStack-Ansible
16:00:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <evrardjp> o/
16:00:05 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:10 <mhayden> ooh, i hit it right on 11:00:00 :)
16:00:13 <palendae> Hello
16:00:19 <mhayden> #topic Roll call
16:00:19 <asettle> Nice job mhayden
16:00:21 <cloudnull> o/
16:00:22 <asettle> o/
16:00:25 <automagically> o/
16:00:25 <andymccr> o/
16:00:28 <mhayden> or perhaps i should have said 16:00 :P
16:00:31 <andymccr> you're the best mhayden.
16:00:37 <evrardjp> congrats mhayden you're as good as a swiss watch :D
16:00:37 * mhayden hugs andymccr
16:00:41 <logan-> o/
16:00:43 <ametts> o/
16:00:55 <jmccrory> o/
16:01:02 <mhayden> howdy ametts
16:01:20 * ametts waves
16:01:38 <spotz> \o/
16:01:47 <thorst> o/
16:01:50 <eil397> o/
16:02:03 <bgmccollum> \/°\
16:02:10 <rromans> .
16:02:20 <automagically> bgmccollum: You doing the worm there?
16:02:31 <bgmccollum> lol
16:02:44 <odyssey4me> o/
16:02:51 <mhayden> okay, got a good crows here
16:02:57 <mhayden> #topic Action items from last week
16:03:08 <mhayden> the only i found was for odyssey4me to dig into Liberty/Mitaka releases
16:03:15 <odyssey4me> done :)
16:03:23 <mhayden> well, fantastic!
16:03:44 <mhayden> #topic Mid-cycle Planning
16:03:46 <cloudnull> boom! ahead of the curve
16:03:56 <mhayden> i saw we had an agenda taking shape there in the etherpad
16:04:10 <mhayden> #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 <galstrom> mhayden i saw the nudge earlier.. roger wilco
16:05:05 <mhayden> everyone: if you have input on the agenda, please be sure to add it there
16:05:30 <odyssey4me> 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 <mhayden> 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 <mhayden> 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 <odyssey4me> mhayden meh
16:06:17 * mhayden shuffles papers
16:06:54 <jmccrory> mhayden: i'll probably have to book through corporate travel anyway
16:07:10 <mhayden> average high temp in San Antonio is 101.5F / 38.6C so prepare yourself :)
16:07:17 <odyssey4me> ouch
16:07:21 <mhayden> but the building is ice cold year round, so again, prepare yourself
16:07:24 <mhayden> :)
16:07:37 <asettle> So... like... jeans with a swimsuit on underneath?
16:07:43 <spotz> I just added a section for the outing, day and food choices.
16:07:52 <asettle> Ohhhh thank spotz !
16:07:53 <odyssey4me> 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 <asettle> thanks*
16:07:58 <mhayden> ah yes, if you have input on foods, please help spotz!
16:08:05 <automagically> +++ odyssey4me
16:08:10 <evrardjp> should we discuss and takes decisions on long term matters?
16:08:17 <mhayden> i have a kiddie pool and a hose
16:08:18 <evrardjp> like discuss what we mean about stable branches
16:08:48 <evrardjp> or bring serious upgrades from version x to z
16:08:50 <mhayden> and we put galstrom_zzz to sleep
16:08:51 <asettle> mhayden: dude I love those
16:09:03 <evrardjp> I'm probably going on a limb here :D
16:09:27 <mhayden> evrardjp: you wanna toss that into the etherpad
16:09:42 <odyssey4me> 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 <evrardjp> before tossing, just asking about the general ideas
16:09:58 <mhayden> i always like talking long term strategy
16:10:03 <evrardjp> I agree with odyssey4me
16:10:13 <evrardjp> this is kept for later then
16:10:17 <mhayden> 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 <odyssey4me> stuff that can perhaps be discussed more between N3 and the Summit, and hopefully finalised at the summit
16:10:26 <evrardjp> I'll add containers CoW on it
16:10:39 <mhayden> evrardjp: i'm interested in that topic
16:10:39 <spotz> 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 <odyssey4me> yeah, please propose a session evrardjp - perhaps one on upgrades too
16:11:00 <evrardjp> yup that's linked
16:11:13 <mhayden> we should have plenty of locals with cars, so traveling to an evening event shouldn't be a big deal
16:11:19 <mhayden> and we have uber/lyft here
16:11:46 <mhayden> anything else on the mid-cycle for now?
16:12:51 <cloudnull> If folks need a ride I can drive.
16:12:55 <mhayden> same here
16:13:14 <mhayden> we can sort the transportation stuff out when everyone's here
16:13:19 <cloudnull> ++
16:13:23 <mhayden> anyone object to moving to the next topic?
16:13:31 <automagically> ++ next topic
16:13:44 <mhayden> #topic Backport of OVS work to stable/mitaka
16:13:46 <cloudnull> AND THEN!
16:13:48 * mhayden passes the mic to automagically
16:13:58 <automagically> Huh…did I have something on the agenda
16:14:07 <mhayden> automagically: WE'RE WAITING!
16:14:25 <automagically> Ah, that backport agenda item was discussed last week
16:14:29 <automagically> No need to discuss today
16:14:32 <mhayden> oh nice
16:14:35 <automagically> I have the info/feedback I need
16:14:39 <cloudnull> boom! handled.
16:14:41 <mhayden> good stuff
16:14:44 <mhayden> man, we're on our game today
16:14:50 <mhayden> either that or i'm working off bad data :)
16:15:02 <mhayden> #topic Removal of venv_enabled switches
16:15:07 <mhayden> logan-: anything on this one?
16:15:22 <mhayden> i saw that the changes for neutron were already proposed
16:15:31 <logan-> it has a major impact on how I deploy for 2 reasons:
16:15:54 <mhayden> #link https://review.openstack.org/#/q/topic:bp/only-install-venvs
16:16:38 <logan-> 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 <logan-> 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 <logan-> so unnecessary overwrites of files takes them out of the compressed read only image and into uncompressed ram
16:17:16 <logan-> so I relied heavily on the configurability of OSA and opted to deploy without venvs on my compute nodes
16:17:44 <logan-> is there a major need requiring that this functionality be removed?
16:18:00 <odyssey4me> logan- mainly because it's code overhead, and an untested path
16:18:05 <automagically> The belief was that no one was using it, and it unnecessarily complicated the roles
16:18:32 <mhayden> #link spec -> https://specs.openstack.org/openstack/openstack-ansible-specs/specs/newton/only-install-venvs.html
16:18:34 <odyssey4me> 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 <mhayden> it seems like containers with overlayfs would give some space back
16:19:15 <logan-> I just found the spec about 30 minutes ago when the patches start coming, sorry! I would have commented earlier
16:19:17 <odyssey4me> 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 <jmccrory> 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 <evrardjp> we could cleanup the code to be a one liner thing, but we still have to test it at some point
16:20:06 <odyssey4me> 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 <logan-> i'm curious if 2 could be resolved by pip installing modules inside the venv instead of overwriting the whole thing
16:21:11 <odyssey4me> logan- so the only reason to ever overwrite it is if the venv changes, which happens per tag
16:21:42 <automagically> 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 <odyssey4me> 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 <automagically> Its a fallback, rather than a deployer selectable choice
16:22:17 <jmccrory> 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 <evrardjp> 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 <jmccrory> and keep nova_venv_bin consistent
16:23:19 <andymccr> i agree with evrardjp
16:23:21 <logan-> yes jmccrory if that was run against existing venvs that might work
16:23:56 <evrardjp> 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 <logan-> I see the task right above that appears to do this
16:24:00 <logan-> 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 <palendae> Thanks for catching it logan-
16:24:22 <palendae> Better to deal with it now than after
16:24:24 <automagically> awesome feedback logan- Looking forward to finding a way to solve for your use case
16:24:29 <evrardjp> palendae: +1
16:24:31 <odyssey4me> ++
16:24:48 <evrardjp> and +1 on automagically too
16:25:00 <mhayden> alrighty, are we good on this topic for the moment?
16:25:06 <eil397> automagically: ++
16:25:27 <logan-> yep mhayden. thanks!
16:25:35 <mhayden> sweet!
16:25:40 <mhayden> thanks for bringing that up, logan-
16:25:52 <mhayden> #topic Ubuntu 16.04 LTS support
16:26:07 <mhayden> #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:26:40 <mhayden> anything critical to bring up here? anyone need help?
16:26:57 <eil397> i've found that no one is working on horizon and ubuntu1604.
16:27:03 <eil397> i would like to try
16:27:07 <cloudnull> ++
16:27:11 <cloudnull> .doit()
16:27:23 <automagically> I’d appreciate reviews on https://review.openstack.org/#/c/338541/ from the neutron experts
16:27:24 <mhayden> eil397: get on that thing! :)
16:27:27 <palendae> eil397, Go for it
16:27:29 <odyssey4me> 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 <eil397> ok.will start
16:27:44 <evrardjp> DVR cool
16:27:55 <odyssey4me> eil397 assign yourself in the etherpad so that everyone else knows that it's taken
16:28:25 <michaelgugino> I live dvr, but I had a vision of deploying known network configs
16:28:48 <eil397> odyssey4me: ok. will mark it in doc
16:28:50 <michaelgugino> so, possibly ml2.lxb.dvr ml2.ovs.dvr
16:28:50 <automagically> michaelgugino: Would appreciate your comments on that then
16:29:22 <mhayden> #topic Open floor
16:29:27 <odyssey4me> interesting idea
16:29:29 <evrardjp> ovs only I guess :D
16:29:30 <mhayden> (since we were already opening it up anyway)
16:29:36 <odyssey4me> evrardjp yep, unfortunately
16:29:54 <michaelgugino> ie, let's track the deployment scenarios that are documented:  http://docs.openstack.org/mitaka/networking-guide/deploy.html
16:30:17 <automagically> michaelgugino: Oh, agreed there, but I think that is more of a config doc challenge for the neutron role docs
16:31:02 <odyssey4me> 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 <odyssey4me> from there the next step is to optimise it
16:31:27 <michaelgugino> 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 <automagically> odyssey4me: The problem is that selective hash override stinks for deployers
16:32:03 <evrardjp> what do you mean?
16:32:55 <automagically> evrardjp: Overriding a var like neutron_plugins[‘ml2.lxb’].driver_firewall
16:33:19 <evrardjp> my question is, do you think it's inconvenient, or it's good?
16:33:32 <automagically> And also doesn’t work with the deprecation filter
16:33:36 <evrardjp> I didn't understand the point we're trying to solve here
16:33:41 <automagically> I think its inconvenient
16:33:46 <odyssey4me> automagically yeah, the intend with the hashes is not to require that
16:34:03 <evrardjp> ansible 2 | combine?
16:34:07 <michaelgugino> I think it's fine, for the vast majority of deployments, those settings are going to be adequate
16:34:38 <odyssey4me> 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 <odyssey4me> 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 <automagically> Good feedback, I think I get the gist of it
16:35:55 <michaelgugino> 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 <automagically> I’ll finish testing what I’ve got for DVR now and perhaps propose an adjustment
16:36:55 <cloudnull> 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 <cloudnull> regarding the "do all the things hash table topic"
16:37:34 <michaelgugino> I definitely don't think we should do that if at all possibke
16:37:35 <logan-> as evrardjp I think the hash override pain for deployers will be mitigated by the combine filter
16:37:46 <logan-> as evrardjp said*
16:38:12 <michaelgugino> 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 <evrardjp> yes, we can think of recursive combine and union filters
16:38:35 <evrardjp> michaelgugino: these aren't mutually exclusive :D
16:38:41 <evrardjp> or I missed the conversation
16:38:55 <evrardjp> what is the decision to be taken?
16:39:15 <odyssey4me> 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 <cloudnull> 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 <odyssey4me> but I'd like us to discuss how much value that brings us at the mid cycle
16:39:40 <michaelgugino> I would rather see the variables written out instead of generating facts dynamically
16:39:50 <automagically> michaelgugino: +++
16:39:53 <cloudnull> sorry its a long comment / discussion but at the bottom i mentioned the results of using combine
16:39:54 <evrardjp> cloudnull: good that you tested that
16:40:19 <cloudnull> note "Upon inspection of the rendered files it seems the recursive combine filter results in missing data."
16:40:53 <evrardjp> we seriously need to do a better liaison with ansible guys :D
16:41:05 <michaelgugino> 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 <logan-> ++ good to know cloudnull
16:41:26 <evrardjp> I mean how long for config template... We are close to one year now
16:41:31 <evrardjp> but that's another topic
16:41:39 <odyssey4me> 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 <cloudnull> 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 <evrardjp> that's the saddest story I heard today cloudnull
16:42:33 <odyssey4me> 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 <spotz> :(
16:42:55 <cloudnull> its just easier to carry a core module until we get someone part of their good'ol boy network.
16:43:03 <cloudnull> odyssey4me: ++
16:43:10 <mhayden> we could talk to the community folks at ansible for some help
16:43:15 <evrardjp> yeah, we can ship that module to another repo, put it in galaxy, and fetch it with galaxy
16:43:29 <evrardjp> when it's gonna be the first one ever used, maybe they will think about it
16:43:42 <mhayden> cloudnull: would you wanna pair up on reaching out to ansible?
16:43:44 <palendae> mhayden, It seems near impossible to provide patches to Ansible without being at Ansible, Inc :(
16:43:49 <cloudnull> mhayden: sure.
16:43:56 <mhayden> palendae: i don't give up easily
16:44:03 <palendae> Fair enough
16:44:04 <cloudnull> you wlil in a year or so
16:44:07 <palendae> And you know Robin ;)
16:44:13 <spotz> He's Major!!!:)
16:44:17 <mhayden> #action cloudnull and major to reach out to ansible about merging some things
16:44:21 <evrardjp> mhayden: I agree with you, we should try
16:44:23 <mhayden> spotz: pfft
16:44:30 <evrardjp> put me in
16:44:36 <mhayden> anything left for the mtg today? we have 15 min left
16:44:39 <mhayden> evrardjp: ok
16:44:42 <cloudnull> robin and greg are on the community side. sadly ansible core is not exactly tied to the community side.
16:44:44 <odyssey4me> 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 <palendae> cloudnull, Yeah. There seem to be some internal communicaton issues there
16:45:05 <odyssey4me> cloudnull do you have the PR link handy, for the context of others
16:45:11 <cloudnull> if we could get an extension for action plugins into ansible extras it'd be a lot easier.
16:45:28 <cloudnull> https://github.com/ansible/ansible/pull/12555
16:45:48 <mhayden> cloudnull / evrardjp: just started a thread via email
16:45:52 <odyssey4me> oh, silly me - it was linked before...
16:45:54 <evrardjp> good
16:45:56 <mhayden> any other topics to discuss? :)
16:45:58 <jmccrory> crazy seeing how receptive lxc was to PRs compared to ansible
16:46:01 <odyssey4me> nothing to see here... move along citizen :p
16:46:04 <cloudnull> https://github.com/ansible/ansible-modules-core/pull/2171
16:46:10 <cloudnull> https://github.com/ansible/ansible-modules-core/pull/1517
16:46:55 <cloudnull> jmccrory:  that was in the community modules.
16:47:05 <cloudnull> acceptance into extras is a lot easier.
16:47:07 <mhayden> okay, i'll close this up now unless there are any objections
16:47:38 <mhayden> going once
16:47:47 <jmccrory> cloudnull: oh i mean the few patches odyssey4me submitted to lxc/lxc
16:48:01 <mhayden> twice
16:48:08 <palendae> closed!
16:48:15 <cloudnull> ah. yea. i dont believe they have a club quite yet. :)
16:48:18 <mhayden> thanks everyone!
16:48:21 <mhayden> #endmeeting