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