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