16:07:00 <odyssey4me> #startmeeting OpenStack-Ansible
16:07:01 <openstack> Meeting started Thu Mar 31 16:07:00 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:07:04 <openstack> The meeting name has been set to 'openstack_ansible'
16:07:17 <odyssey4me> #topic Agenda & rollcall
16:08:09 <michaelgugino> here
16:08:28 <prometheanfire> o\
16:08:46 <serverascode> o/
16:08:49 <jmccrory_> o/
16:08:51 <stevelle> o/
16:09:52 <cloudnull> o/
16:10:38 <odyssey4me> hi everyone - sorry for the late start, I was busy and all these DST changes confused me too
16:10:54 <odyssey4me> #topic Release notes in IRRs
16:11:00 <odyssey4me> Is palendae around?
16:11:11 <palendae> Am - I have not made much progress o nthis
16:11:45 <odyssey4me> well, you did in that we had a discussion with dhellmann about it and came to an understanding that it should be possible to do the roll-up
16:11:48 <odyssey4me> :)
16:11:52 <palendae> Yeah
16:11:55 <palendae> Brief summary
16:12:21 <palendae> We're going to look at making a post merge job for the IRRs that will copy out the release notes and submit them as a new patch to openstack-ansible
16:12:40 <palendae> So the file will be duplicated, but the process of copying it will be automated. Approvals are still necessary though
16:13:14 <spotz> o/ sorry was chatting:)
16:13:51 <odyssey4me> yeah, that's the gist of what's possible with no tooling changes to reno
16:14:16 <odyssey4me> thanks palendae - let me know if you need any help on it, we'll keep the topic on the agenda for follow up if that's ok?
16:14:35 <palendae> odyssey4me: Sure thing
16:14:56 <palendae> Mostly focused on upgrade testing right now, but I'll try to poke at this/priortize it when I have downtime
16:15:15 <palendae> I'll start with a demo script that pulls the necessary stuff out of a git commit and go from there
16:15:24 <odyssey4me> #topic Mitaka release decisions
16:15:48 <stevelle> palendae: that sounds excellent, thanks
16:16:22 <odyssey4me> A bit of feedback first. The short of it is that if we want to be included as part of the 'Mitaka' release, then we need to release on time with the rest of the OpenStack projects. We don't really have the ability to delay.
16:16:59 <odyssey4me> That prety much means that we should be looking to branch, and therefore declare an RC today - and we'll tag the first release next week.
16:18:07 <odyssey4me> I think we're in reasonable shape. There is a lot that perhaps we should be doing to clean a few things up, but those are things we could easily backport if we feel they're really necessary.
16:18:29 <cloudnull> ++
16:18:45 <spotz> odyssey4me We're still good to clean up though right? Cause I don't think we can not put out a RC
16:19:06 <odyssey4me> Therefore I'd like to ask that all cores look specifically only to merge absolutely essential reviews, and to only workflow patches that are necessary. Docs patches and release notes can go through as normal, but nothing must change code unless it needs to.
16:19:29 <odyssey4me> This is release critical: https://review.openstack.org/300025
16:20:04 <stevelle> I think that is an easy merge
16:20:06 <odyssey4me> Anything that improves tests is good in my books, so the awesome work that mattt's being putting in to normalise how the tests are done and to make them work better is good in my books.
16:21:51 <odyssey4me> I'd like us to branch tonight, so that master can progress and we can get on with merging anything we'd like. That said, the focal point would ideally be for us to be first finding anything that may be a release critical bug, and second to prepare reviews for things we want to propose and discuss at the summit.
16:22:08 <stevelle> When we do have the branch, should that be announced on the ML?
16:22:18 <cloudnull> ++
16:22:55 <odyssey4me> I can do that, although part of using the release team is that there are automated announcements. I'll discuss the way it works with them.
16:23:15 <odyssey4me> I think we may be missing the right gate job to automate the announcement, so I may have to do it manually anyway.
16:23:22 <stevelle> Right, was wondering if that would be automated
16:24:00 <odyssey4me> One of the benefits of releasing as an OpenStack project is that we can make use of the release team. That gets us a lot more awareness and formalised support.
16:24:39 <spotz> +1
16:25:24 <odyssey4me> I'd like us to look through the review queue in the channel after the meeting and itemise reviews that are high priority.
16:25:45 <odyssey4me> Any thoughts, comments or questions?
16:25:50 <stevelle> I'll be there
16:25:53 <cloudnull> maybe we need to do this on an etherpad
16:26:00 <odyssey4me> good idea
16:26:02 <spotz> Sounds like a good plan, etherpad is good too
16:26:03 <cloudnull> that way we can track whats what
16:26:08 <odyssey4me> note also that we still have several bugs sitting: https://launchpad.net/openstack-ansible/+milestone/13.0.0
16:26:24 <odyssey4me> we'll need to decide whether to deal with them, or move them along
16:26:49 <cloudnull> :LINK https://etherpad.openstack.org/p/osa-release-reviews
16:26:56 <odyssey4me> thanks cloudnull
16:27:30 <spotz> I can eithre work on my 2 or tackle reviews just let me know what you need me to work on in the background of my day to days
16:30:28 <odyssey4me> thanks spotz
16:30:36 <odyssey4me> sorry - saw a squirrel on the etherpad :p
16:30:51 <spotz> odyseey4me I know right!
16:30:59 <odyssey4me> #topic Blueprint work
16:31:12 <odyssey4me> I thought it might be nice to do a quick catch up on the blueprint stuff.
16:31:46 <odyssey4me> michaelgugino I see you've got an OVS patch in the works. It looks in reasonable shape and seems likely that we may get a patch merged early in Newton. :)
16:31:59 <odyssey4me> Any thoughts or questions relating to that?
16:32:07 <michaelgugino> I added some comments to the review
16:32:10 <cloudnull> potential backport to mitaka?
16:32:31 <michaelgugino> We'll be backporting it to liberty locally, I believe.
16:32:37 <odyssey4me> #link https://review.openstack.org/298765
16:33:32 <michaelgugino> In any case, I need some direction on the implementation.  We can either implement the pattern we have now, or change linuxbridge_agent to something like l2plugin_agent
16:33:49 <odyssey4me> Personally, I think that considering it's an opt-in feature we could backport to Mitaka quite happily before milestone-1 assuming that this is what our stakeholders/cores are keen on.
16:34:02 <michaelgugino> my only concern is that would potentially break backwards compatibility with older inventories.
16:34:41 <cloudnull> ++ i like the idea of doing something like "l2plugin_agent" which can be made as a child to the neutron_agent group.
16:34:41 <odyssey4me> hmm, that's a good question
16:34:44 <michaelgugino> or, just provide additional files in env.d such as 'nova-ovs.yml' etc
16:35:08 <stevelle> inventory changes would be bad for a backport to mitaka.
16:35:13 <odyssey4me> I'd prefer to generalise the group name, and if the migration is an issue I'd rather we tool the migration.
16:35:33 <odyssey4me> But then yes, a backport would not be possible.
16:36:21 <cloudnull> or maybe keep the group structure as is and simply do something along the lines of what odyssey4me suggested with a setting of "neutron_network_type" ?
16:36:26 <odyssey4me> That said - if the tooling was done in such a way that it's completely transparent, then it probably would be backportable. It all depends... but stevelle has raised a good point in that it would make the reviewers nervous.
16:36:36 <michaelgugino> I'm leaning more towards the extra files in the env.d
16:37:09 <stevelle> that might be smoother
16:37:16 <odyssey4me> michaelgugino I'm not fond of that idea at all. Our last resort should be to add more configuration files in user space.
16:37:32 <cloudnull> michaelgugino: couldnt neutron_ovs_agent be added to https://github.com/openstack/openstack-ansible/blob/master/etc/openstack_deploy/env.d/neutron.yml#L51
16:37:41 <stevelle> cleaner seems better than smoother in this case
16:38:00 <cloudnull> and with the component in here https://github.com/openstack/openstack-ansible/blob/master/etc/openstack_deploy/env.d/neutron.yml#L16
16:38:15 <michaelgugino> I suppose it could.  I'll have to rework some things to ensure that only one or the other is implemented
16:38:28 <michaelgugino> I think I have a good idea how to do that
16:38:30 <cloudnull> seems like there would be no need for a structural change if we went that route
16:38:37 <odyssey4me> well, both groups can be there - it doesn't have to be one or the other in terms of the inventory
16:38:39 <cloudnull> it could follow something similar to the lbaas agent
16:39:04 <mhayden> someone said lbaas
16:39:14 <odyssey4me> but yes - perhaps we should review the inventory for more specifics like this that should become generics - then we build some tooling around it
16:39:17 <cloudnull> the lbaas agent is conditionally included and we can make the lxb / ovs agent do a similar thing
16:39:45 <cloudnull> mhayden: dont you worry none
16:39:48 <cloudnull> :)
16:39:56 <spotz> hehe
16:40:06 <michaelgugino> something like inventory_hostname in groups[neutron_services['{{ l2plugin_agent }}']['group']]
16:41:13 <cloudnull> +1 i think something like that would work well without having to worry about inventory issues if we backport
16:41:37 <cloudnull> i think
16:41:40 <odyssey4me> also note that the inventory issue is simply a cosmetic one anyway - the name of the group seems wrong
16:41:44 * cloudnull could be super off base
16:41:52 <michaelgugino> my preference is a single user variable to deploy OVS or LxB
16:42:00 <cloudnull> +1
16:42:27 <odyssey4me> yep, the ironic and nuage plugins are kinda needing the same thing - a single var change that actions other var changes
16:43:07 <cloudnull> +1
16:43:22 <odyssey4me> that's why I suggested using a var like 'neutron_network_type' which has a known set of values - something like linuxbridge, openvswitch, plumgrid or nuage.
16:43:37 <odyssey4me> Then, based on that we set all the appropriate drivers and such.
16:44:09 <michaelgugino> well, I don't prefer to call them neutron_network_type because it's really the ml2 plugin agent, not necessarily the network type
16:44:34 <michaelgugino> I want to try to match upstream's wording as closely as we can
16:44:41 <cloudnull> +1
16:44:43 <odyssey4me> This could be done in a task using set_fact, but I'm not all that fond of that approach. I kinda like the way that the dict is being use din the neutron role to provide access in a simple way to the config files, etc.
16:44:56 <odyssey4me> michaelgugino sure - the name was just a suggestion
16:44:57 <javeriak> don't we already have that, in neutron_plugin_type
16:45:11 <odyssey4me> as long as it's namespaced :)
16:45:19 <michaelgugino> ml2 is one plugin, plumgrid is another plugin
16:45:22 <odyssey4me> you're right, we do :)
16:45:33 <michaelgugino> ml2 implements various agents, at least that's how it looks to me
16:45:41 <odyssey4me> so the trouble is now that we need ml2.openvswitch :p
16:46:09 <cloudnull> so maybe thats the type
16:46:16 <cloudnull> ml2.linuxbridge
16:46:18 <cloudnull> ml2.ovs
16:46:18 <javeriak> you add another mls-ovs struct to the neutron_plugins list, with the relevant configs
16:46:20 <cloudnull> etc
16:46:27 <odyssey4me> but yeah, I like that approach and would like to establish a pattern which we can use for other things in other roles
16:46:35 <javeriak> ml2-ovs* etc
16:46:41 <cloudnull> ^ +1
16:47:11 <javeriak> here: https://github.com/openstack/openstack-ansible/blob/liberty/playbooks/roles/os_neutron/defaults/main.yml#L87-L95
16:47:58 <michaelgugino> I'm still thinking it should be neutron_ml2_type
16:48:47 <michaelgugino> that dict doesn't really implement specific to OVS or LxB
16:49:08 <odyssey4me> Well, have a go at it the way you think, and let's continue in review.
16:49:45 <odyssey4me> On another topic of interest - I'm told that we should have access to an experimental job to try out Ubuntu Xenial some time soon.
16:49:50 <michaelgugino> but, now I'm leaning the otherway, it might be a clean place to implement it, if not a little redundant.
16:50:25 <javeriak> michaelgugino you should give whatever you think is best a try, we can help review
16:50:32 <odyssey4me> javeriak ++
16:50:32 <michaelgugino> ok, will do.
16:50:43 <cloudnull> the mechanism drivers and such can go their too
16:50:45 <cloudnull> https://github.com/openstack/openstack-ansible/blob/liberty/playbooks/roles/os_neutron/defaults/main.yml#L271-L272
16:50:48 <odyssey4me> michaelgugino also, there's nothing stopping you from doing two reviews to compare approaches
16:51:42 <michaelgugino> The biggest thing about 16.04 is the containers
16:51:44 <odyssey4me> cloudnull yeah, I think some of the clean up work we should do in the next cycle can also include doing things like this in smarter way
16:51:46 <odyssey4me> *ways
16:51:58 <cloudnull> ++
16:52:31 <michaelgugino> until we get that solved, it's going to be hard.  After we solve the containers, that checks a lot of boxes for systemd support, and makes the support for CentOS much easier.
16:52:32 <odyssey4me> we can do away with a lot of logic in tasks and templates by using javeriak's clever mechanism
16:53:22 <michaelgugino> I'm not familiar with javeriak's mechanism.
16:54:14 <odyssey4me> the use of the predictable dict and reference to it is what I was referring to - basically what we've been discussing as a possible approach for the last 15 mins was implemented by javeriak  :)
16:54:31 <odyssey4me> alright, we're almost out of time
16:54:36 <odyssey4me> #topic Open discussion
16:54:49 <odyssey4me> Does anyone have anything specific they want to mention before we close.
16:55:12 <odyssey4me> Or question?
16:56:01 <michaelgugino> has anyone implemented a simple inventory cmdb for this project?  Or using one?
16:56:14 <stevelle> hah
16:56:18 <cloudnull> michaelgugino: no.
16:56:23 <cloudnull> not that im aware of
16:56:28 <stevelle> great idea though
16:56:31 <michaelgugino> it would be nice to have an api I can call to get my inventory instead of the giant json file.
16:56:34 <cloudnull> but that is our oldest blueprint
16:56:55 <cloudnull> michaelgugino: stevelle odyssey4me and i pondered using etcd for that at the ops summit
16:56:59 <odyssey4me> alright, let's move that to the channel (or the summit inventory revisit session)
16:57:03 <cloudnull> but i've not done anything with it as of yet
16:57:17 <odyssey4me> we need to move on - thank you all for attending!
16:57:26 <spotz> o/
16:57:26 <odyssey4me> #endmeeting