18:03:02 <SumitNaiksatam> #startmeeting networking_policy 18:03:03 <openstack> Meeting started Thu Jan 7 18:03:02 2016 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:06 <openstack> The meeting name has been set to 'networking_policy' 18:03:24 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Jan_7th.2C_2016 18:03:43 <SumitNaiksatam> pretty short agenda at might end 18:04:00 <SumitNaiksatam> #topic Liberty Sync 18:04:14 <SumitNaiksatam> #link https://review.openstack.org/#/q/topic:liberty-sync 18:04:21 <SumitNaiksatam> rkukura: thanks for reviewing the patches 18:04:26 <rkukura> These all look good to me, and have my +2s 18:04:36 <SumitNaiksatam> rkukura: thanks 18:04:50 <SumitNaiksatam> i think magesh reviewed the patches as well and he said he would join the meeting to discuss 18:05:02 <SumitNaiksatam> i dont see any negative comments 18:05:27 <SumitNaiksatam> but i wanted to discuss during this meeting before we go ahead and merge these patches 18:05:28 <rkukura> SumitNaiksatam: I had a couple, but you addressed them 18:05:36 <SumitNaiksatam> rkukura: okay, thanks 18:05:51 <SumitNaiksatam> so my plan is to release L1 with this change 18:06:13 <SumitNaiksatam> we can then test that, and shortly after cut the stable/liberty 18:06:26 <rkukura> SumitNaiksatam: That sounds reasonable to me 18:06:30 <SumitNaiksatam> rkukura: okay 18:06:54 <rkukura> Any idea how much additinal work would then be needed to make our master work with the other projects’ masters? 18:06:55 <SumitNaiksatam> i have also created some temporarry branches for the vendor projects which were dependencies for GBP 18:07:29 <SumitNaiksatam> rkukura: i intend to take up aligning master with other openstack master immediately after this 18:07:40 <rkukura> SumitNaiksatam: +2 18:07:40 <SumitNaiksatam> rkukura: unfrotunately i have not evaluated this yet 18:07:56 <SumitNaiksatam> while on that 18:08:39 <SumitNaiksatam> i have not changed the DB migration scheme for GBP 18:09:00 <SumitNaiksatam> meaning we are still following the same scheme as Juno and Kilo for Liberty 18:09:35 <SumitNaiksatam> other projects, Neutron most notably, has moved to using two separate chains for upgrade and downgrade 18:09:48 <SumitNaiksatam> this is something we should consider for the M release 18:09:57 <rkukura> Aren’t these for expand and contract rather than upgrade and downgrade? 18:10:09 <rkukura> I thought we no longer to downgrades 18:10:16 <SumitNaiksatam> rkukura: yeah i meant expand and contract 18:10:26 <SumitNaiksatam> rkukura: you are right neutron doesnt support downgrade 18:10:38 <rkukura> My vague understanding is that these are intended to support rolling upgrades 18:10:44 <SumitNaiksatam> rkukura: exactly 18:11:07 <SumitNaiksatam> so i definitely think this will be useful for us 18:11:15 <rkukura> agreed 18:11:37 <SumitNaiksatam> however given that we want to keep GBP liberty code base closer to juno/kilo i did not incorporate this change 18:12:07 <SumitNaiksatam> we still have some downgrade constructs in our migration 18:12:33 <SumitNaiksatam> when we move to expand/contract we should remove the downgrad constrcuts 18:13:22 <SumitNaiksatam> rkukura: hopefully we can move quickly to stable/liberty and then you will have a version that you can work with 18:13:30 <rkukura> ok 18:13:55 <SumitNaiksatam> rkukura: also, we will probably be having new stable releases for juno and kilo shortly (since we did all those backports) 18:14:08 <rkukura> My goal for this year is to get GBP into RDO/delorean ;) 18:14:15 <SumitNaiksatam> rkukura: probably end of this week or early next week 18:14:26 <SumitNaiksatam> rkukura: cool, so i will try to get these to you at the earliest 18:14:44 <rkukura> OK, I’ll be ready to update fedora/kilo once those are ready. I don’t think juno is maintained anymore 18:14:47 <SumitNaiksatam> rkukura: i think we might be pretty “stable” now (hopefully!) :-) 18:14:55 <SumitNaiksatam> rkukura: ah you are right about juno 18:15:25 <SumitNaiksatam> #topic Stable branches 18:15:35 <SumitNaiksatam> since we are discussing this 18:16:03 <SumitNaiksatam> tbachman: you are working with the kilo branch, anything that you noticed needed to be fixed, or its looking good for now? 18:16:25 <tbachman> SumitNaiksatam: just using ML2 for now 18:16:31 <tbachman> will be using GBP soon 18:16:33 <SumitNaiksatam> tbachman: ah ok 18:16:45 <SumitNaiksatam> tbachman: looking forward to that :-) 18:16:54 <tbachman> FWIW, I’ve run a devstack setup with GBP on stable/kilo, but that was about a month ago 18:17:02 <SumitNaiksatam> tbachman: great work so far though! 18:17:08 <SumitNaiksatam> tbachman: okay 18:17:20 <tbachman> yup. But no tempest/rally. Just user testing. 18:17:24 <tbachman> (and simple at that) 18:17:37 <SumitNaiksatam> regarding devstack, we also liberty devstack now, if anyone wants to try 18:17:44 <SumitNaiksatam> tbachman: okay thanks 18:17:48 <rkukura> speaking of devstacks, is anyone doing there GBP development on CentOS 7? 18:18:33 <SumitNaiksatam> rkukura: i know amit was using CentOS but not sure he was specifically using it for developing GBP related stuff 18:18:43 <SumitNaiksatam> rkukura: anything specific you were looking for? 18:18:55 <SumitNaiksatam> #topic GBP devstack 18:19:03 <rkukura> OK, devstack master no longer support fedora 20, so I need to move off that, probably to CentOS 18:19:05 <tbachman> rkukura: anything you think might be a potential issue there? 18:19:13 <tbachman> ah 18:20:00 <rkukura> One minor issue is our devstack patch does “service apache2 restart”, which needs to be “service httpd restart” on Red Hat systems 18:20:16 <SumitNaiksatam> rkukura: okay, i am not sure that restart is still needed 18:20:21 <tbachman> rkukura: FWIW, I’ve had issues with that on 14.04 ubuntu as well 18:20:29 <rkukura> Would be best to drop it if possible 18:20:31 <SumitNaiksatam> tbachman: i recall you mentioning that you had removed that restart? 18:20:39 <tbachman> (not with the actual command, but that it didn’t seem to work) 18:20:44 <tbachman> yeah — haven’t debugged it tho 18:21:02 <tbachman> you need it for sure for a clean install 18:21:19 <tbachman> b/c that brings down apache so that it can pick up the UI chnages after restarting 18:21:19 <SumitNaiksatam> rkukura: before you do stack.sh can you comment it out and check if it works on CentOS? 18:21:26 <tbachman> which is presumably why that’s in there 18:21:35 <tbachman> but I was seeing failures in the restart on subsequent restacks 18:21:36 <SumitNaiksatam> tbachman: that was the original intent 18:21:45 <tbachman> so, after initial install, it can/should be removed. 18:21:52 <SumitNaiksatam> tbachman: okay 18:22:07 <tbachman> seems like there should be a “generic” way to do this in devstack 18:22:07 <SumitNaiksatam> on ubuntu it works with subsequent restacks as well 18:22:15 <rkukura> doesn’t devstack to the restart for us? Not clear why GBP would need an additional restart 18:22:18 <SumitNaiksatam> tbachman: yes there is more than one way 18:22:35 <tbachman> rkukura: it may be where we’ve hooked in our UI changes 18:22:38 <SumitNaiksatam> rkukura: tbachman so that brings us to the next point while we are still on this topic 18:23:07 <SumitNaiksatam> so devstack has now evolved into a out-of-tree plugin based model 18:23:21 <SumitNaiksatam> we also need to move in that direction 18:23:37 <SumitNaiksatam> i am not sure doing that is going to solve this horizon specific issue 18:24:13 <SumitNaiksatam> but nevertheless we need to have our devstack plugin which can be in-tree in GBP 18:24:22 <SumitNaiksatam> that way we dont have to do the patching we are doing now 18:24:47 <SumitNaiksatam> and we can hopefully use the same devstack plugin for our gate jobs as well as for installation on dev setup 18:25:11 <rkukura> SumitNaiksatam: I recall at least heat and maybe horizon wanting our code to move into their trees, even if contrib, rather than in separate repos 18:25:13 <SumitNaiksatam> currently we have slightly different patches for them 18:25:38 <SumitNaiksatam> rkukura: yes, i think it was Heat which specifically mentioned that 18:26:06 <SumitNaiksatam> rkukura: and you are right, i think Horizon has accepted quite a bit of code in contrib 18:26:09 <rkukura> SumitNaiksatam: Mentioned it because doing that might simplify things in devstack a bit 18:26:42 <SumitNaiksatam> rkukura: agree 18:27:12 <SumitNaiksatam> #topic Open Discussion 18:27:24 <SumitNaiksatam> anything else we wanted to discuss today? 18:27:54 <rkukura> what was the conclusing regarding the liberty sync patches? 18:28:10 <SumitNaiksatam> rkukura: i think we can merge them 18:28:25 <rkukura> I wasn’t clear whether magesh had some specific issue or not 18:28:38 <SumitNaiksatam> rkukura: i dont think so, but i will ping him again later today 18:28:49 <SumitNaiksatam> he said he would comment and join the meeting 18:28:53 <rkukura> ok, and then lets get a 2nd core reviewer 18:29:05 <SumitNaiksatam> rkukura: yeah he can be that one 18:29:15 <rkukura> good 18:29:25 <SumitNaiksatam> rkukura: tbachman: igordcard_ do you know of any tool that can be used to generate API documentation from the python code? 18:29:31 <rkukura> I’ll be ready to re-review if needed 18:29:37 <SumitNaiksatam> rkukura: great thanks 18:29:44 <tbachman> SumitNaiksatam: google? ;) 18:29:53 <SumitNaiksatam> tbachman: sure :-) 18:29:57 <tbachman> lol 18:30:32 <SumitNaiksatam> i dont think its as straight forward since we use a home grown framework for defining the API layer 18:30:51 <tbachman> I’ve used swagger for ODL 18:30:54 <SumitNaiksatam> by we, i mean the framework defined in neutron (resource attribute map, etc) 18:31:35 <tbachman> SumitNaiksatam: I guess it also depends on how deep you want to go with API documentation 18:31:39 <tbachman> given python’s lack of typing 18:31:45 <SumitNaiksatam> tbachman: very true 18:32:02 <SumitNaiksatam> for now i am just thinking we will have a RST doc 18:32:10 <rkukura> SumitNaiksatam: You are asking about the REST API right? 18:32:19 <SumitNaiksatam> it wil be better than what we have now (which is just CLI examples) 18:32:20 <tbachman> ah 18:32:23 <SumitNaiksatam> rkukura: yes 18:32:33 * tbachman recalls his last comment 18:32:56 <rkukura> Probably wouldn’t be hard to write a bit of python code that spit out a skeleton based on the attribute maps 18:33:16 <tbachman> do they do something like that for this: http://developer.openstack.org/api-ref-networking-v2-ext.html 18:33:24 <SumitNaiksatam> tbachman: exactly 18:33:39 <SumitNaiksatam> tbachman: but i think they use WADL to write that 18:33:51 <SumitNaiksatam> tbachman: and that is pretty cumbersome to deal with 18:34:13 <SumitNaiksatam> i had to deal with it when doing the fwaas documentation 18:34:18 <tbachman> seems like openstack should have a unified solution to this 18:34:28 <SumitNaiksatam> tbachman: i think that is the preferred one 18:34:54 <SumitNaiksatam> but then for the established projects doc teams have worked on this 18:35:03 <SumitNaiksatam> we havent had resources like that 18:35:16 <SumitNaiksatam> so if we are able to generate the content, perhaps in RST 18:35:20 <tbachman> SumitNaiksatam: I see — thx 18:35:28 <rkukura> we need https://wiki.openstack.org/wiki/Neutron/API/WADL 18:35:41 <SumitNaiksatam> at some later point someone proficient in these markup languages can pick it up 18:35:57 <SumitNaiksatam> rkukura: thanks 18:36:15 <rkukura> was this implemented? 18:36:17 <SumitNaiksatam> its a mechanical process, but it takes a long time to write 18:36:39 <rkukura> This talks about a script generating it from the attribute maps 18:37:11 <SumitNaiksatam> rkukura: i dont think so, but i might be wrong 18:37:22 <SumitNaiksatam> rkukura: i have seen people manually write this up 18:37:38 <SumitNaiksatam> usually you take an existing document and hack it to suite your new API spec :-) 18:37:56 <tbachman> :( 18:38:06 <tbachman> folks have a high threshold for pain 18:38:16 <SumitNaiksatam> tbachman: yeah, painful 18:38:35 <SumitNaiksatam> alright, if nothing else, lets wrap it up for today 18:38:47 <SumitNaiksatam> hopefully people will be back from vacation next week 18:38:57 <SumitNaiksatam> rkukura: tbachman igordcard_: thanks for joining 18:39:06 <tbachman> SumitNaiksatam: thank you! 18:39:08 <SumitNaiksatam> btw there was an update from OSM 18:39:11 <rkukura> ok, thanks SumitNaiksatam! 18:39:17 <tbachman> SumitNaiksatam: see you next week! 18:39:24 <SumitNaiksatam> “NSF design is done. we started implementing. “ 18:39:26 <tbachman> (in SJ) 18:39:40 <SumitNaiksatam> tbachman: oh wow! 18:39:51 <SumitNaiksatam> we will need to close on the NSF spec 18:40:03 <SumitNaiksatam> #link https://review.openstack.org/239743 18:40:17 <SumitNaiksatam> thanks all 18:40:18 <SumitNaiksatam> bye 18:40:21 <SumitNaiksatam> #endmeeting