16:07:00 #startmeeting OpenStack-Ansible 16:07:01 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:07:04 The meeting name has been set to 'openstack_ansible' 16:07:17 #topic Agenda & rollcall 16:08:09 here 16:08:28 o\ 16:08:46 o/ 16:08:49 o/ 16:08:51 o/ 16:09:52 o/ 16:10:38 hi everyone - sorry for the late start, I was busy and all these DST changes confused me too 16:10:54 #topic Release notes in IRRs 16:11:00 Is palendae around? 16:11:11 Am - I have not made much progress o nthis 16:11:45 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 :) 16:11:52 Yeah 16:11:55 Brief summary 16:12:21 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 So the file will be duplicated, but the process of copying it will be automated. Approvals are still necessary though 16:13:14 o/ sorry was chatting:) 16:13:51 yeah, that's the gist of what's possible with no tooling changes to reno 16:14:16 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 odyssey4me: Sure thing 16:14:56 Mostly focused on upgrade testing right now, but I'll try to poke at this/priortize it when I have downtime 16:15:15 I'll start with a demo script that pulls the necessary stuff out of a git commit and go from there 16:15:24 #topic Mitaka release decisions 16:15:48 palendae: that sounds excellent, thanks 16:16:22 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 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 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 ++ 16:18:45 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 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 This is release critical: https://review.openstack.org/300025 16:20:04 I think that is an easy merge 16:20:06 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 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 When we do have the branch, should that be announced on the ML? 16:22:18 ++ 16:22:55 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 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 Right, was wondering if that would be automated 16:24:00 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 +1 16:25:24 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 Any thoughts, comments or questions? 16:25:50 I'll be there 16:25:53 maybe we need to do this on an etherpad 16:26:00 good idea 16:26:02 Sounds like a good plan, etherpad is good too 16:26:03 that way we can track whats what 16:26:08 note also that we still have several bugs sitting: https://launchpad.net/openstack-ansible/+milestone/13.0.0 16:26:24 we'll need to decide whether to deal with them, or move them along 16:26:49 :LINK https://etherpad.openstack.org/p/osa-release-reviews 16:26:56 thanks cloudnull 16:27:30 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 thanks spotz 16:30:36 sorry - saw a squirrel on the etherpad :p 16:30:51 odyseey4me I know right! 16:30:59 #topic Blueprint work 16:31:12 I thought it might be nice to do a quick catch up on the blueprint stuff. 16:31:46 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 Any thoughts or questions relating to that? 16:32:07 I added some comments to the review 16:32:10 potential backport to mitaka? 16:32:31 We'll be backporting it to liberty locally, I believe. 16:32:37 #link https://review.openstack.org/298765 16:33:32 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 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 my only concern is that would potentially break backwards compatibility with older inventories. 16:34:41 ++ 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 hmm, that's a good question 16:34:44 or, just provide additional files in env.d such as 'nova-ovs.yml' etc 16:35:08 inventory changes would be bad for a backport to mitaka. 16:35:13 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 But then yes, a backport would not be possible. 16:36:21 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 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 I'm leaning more towards the extra files in the env.d 16:37:09 that might be smoother 16:37:16 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 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 cleaner seems better than smoother in this case 16:38:00 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 I suppose it could. I'll have to rework some things to ensure that only one or the other is implemented 16:38:28 I think I have a good idea how to do that 16:38:30 seems like there would be no need for a structural change if we went that route 16:38:37 well, both groups can be there - it doesn't have to be one or the other in terms of the inventory 16:38:39 it could follow something similar to the lbaas agent 16:39:04 someone said lbaas 16:39:14 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 the lbaas agent is conditionally included and we can make the lxb / ovs agent do a similar thing 16:39:45 mhayden: dont you worry none 16:39:48 :) 16:39:56 hehe 16:40:06 something like inventory_hostname in groups[neutron_services['{{ l2plugin_agent }}']['group']] 16:41:13 +1 i think something like that would work well without having to worry about inventory issues if we backport 16:41:37 i think 16:41:40 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 my preference is a single user variable to deploy OVS or LxB 16:42:00 +1 16:42:27 yep, the ironic and nuage plugins are kinda needing the same thing - a single var change that actions other var changes 16:43:07 +1 16:43:22 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 Then, based on that we set all the appropriate drivers and such. 16:44:09 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 I want to try to match upstream's wording as closely as we can 16:44:41 +1 16:44:43 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 michaelgugino sure - the name was just a suggestion 16:44:57 don't we already have that, in neutron_plugin_type 16:45:11 as long as it's namespaced :) 16:45:19 ml2 is one plugin, plumgrid is another plugin 16:45:22 you're right, we do :) 16:45:33 ml2 implements various agents, at least that's how it looks to me 16:45:41 so the trouble is now that we need ml2.openvswitch :p 16:46:09 so maybe thats the type 16:46:16 ml2.linuxbridge 16:46:18 ml2.ovs 16:46:18 you add another mls-ovs struct to the neutron_plugins list, with the relevant configs 16:46:20 etc 16:46:27 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 ml2-ovs* etc 16:46:41 ^ +1 16:47:11 here: https://github.com/openstack/openstack-ansible/blob/liberty/playbooks/roles/os_neutron/defaults/main.yml#L87-L95 16:47:58 I'm still thinking it should be neutron_ml2_type 16:48:47 that dict doesn't really implement specific to OVS or LxB 16:49:08 Well, have a go at it the way you think, and let's continue in review. 16:49:45 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 but, now I'm leaning the otherway, it might be a clean place to implement it, if not a little redundant. 16:50:25 michaelgugino you should give whatever you think is best a try, we can help review 16:50:32 javeriak ++ 16:50:32 ok, will do. 16:50:43 the mechanism drivers and such can go their too 16:50:45 https://github.com/openstack/openstack-ansible/blob/liberty/playbooks/roles/os_neutron/defaults/main.yml#L271-L272 16:50:48 michaelgugino also, there's nothing stopping you from doing two reviews to compare approaches 16:51:42 The biggest thing about 16.04 is the containers 16:51:44 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 *ways 16:51:58 ++ 16:52:31 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 we can do away with a lot of logic in tasks and templates by using javeriak's clever mechanism 16:53:22 I'm not familiar with javeriak's mechanism. 16:54:14 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 alright, we're almost out of time 16:54:36 #topic Open discussion 16:54:49 Does anyone have anything specific they want to mention before we close. 16:55:12 Or question? 16:56:01 has anyone implemented a simple inventory cmdb for this project? Or using one? 16:56:14 hah 16:56:18 michaelgugino: no. 16:56:23 not that im aware of 16:56:28 great idea though 16:56:31 it would be nice to have an api I can call to get my inventory instead of the giant json file. 16:56:34 but that is our oldest blueprint 16:56:55 michaelgugino: stevelle odyssey4me and i pondered using etcd for that at the ops summit 16:56:59 alright, let's move that to the channel (or the summit inventory revisit session) 16:57:03 but i've not done anything with it as of yet 16:57:17 we need to move on - thank you all for attending! 16:57:26 o/ 16:57:26 #endmeeting