15:02:36 <ihrachys> #startmeeting neutron_upgrades
15:02:37 <openstack> Meeting started Mon Oct 17 15:02:36 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:40 <openstack> The meeting name has been set to 'neutron_upgrades'
15:02:43 <ihrachys> sorry for the late start, was distracted :)
15:02:45 <korzen> hello
15:02:54 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:03:13 <sshank> Hello
15:03:37 <ihrachys> #topic Announcements
15:03:50 <ihrachys> not much to update about, ocata-1 is some time in mid-Nov
15:03:57 <dasanind_> o/
15:04:10 <ihrachys> we'll have a summit next week, so we'll cancel the meeting there and I think the week after it
15:04:39 <electrocucaracha> o/
15:04:39 <ihrachys> any objections to that?
15:05:37 <ihrachys> prolly not.
15:05:48 <ihrachys> #action ihrachys  to send an email to openstack-dev@ cancelling next two meetings
15:05:49 <manjeets__> o/
15:06:27 <ihrachys> before we get into technical bits, let's talk summit through
15:06:33 <ihrachys> #topic Barcelona summit
15:07:14 <ihrachys> we won't have any separate design session for upgrade matters. that said, we have a general session on server side next steps.
15:07:17 * dasm late o/
15:07:24 <ihrachys> that I will (co-)chair with kevinbenton
15:07:37 <ihrachys> #link https://etherpad.openstack.org/p/ocata-neutron-server-next design session etherpad
15:08:19 <ihrachys> as you can see, the session will cover the database side work we track as a team
15:08:32 <ihrachys> please update the etherpad with comments if you have anything specific missing there
15:08:46 <ihrachys> please set/type in your nicknames there if you do
15:08:53 <ihrachys> so that we can track who said what :)
15:09:40 <ihrachys> the session in the schedule is:
15:09:44 <ihrachys> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16903/neutron-neutron-server-retrospective-and-next-steps
15:09:56 <ihrachys> Friday morning it is
15:10:01 <electrocucaracha> ihrachys: I heard that given that this release is too short, mainly it will focused to hardening or refactoring, that affects our plans or we are the exception?
15:10:27 <ihrachys> electrocucaracha: OVO is a high visibility effort for the cycle, so we are good
15:11:05 <ihrachys> online-upgrades - not yet, but since it's related, I don't think it will be a pushback to get that in assuming we have the code
15:11:47 <ihrachys> speaking of online-upgrades, I posted a draft of a spec for that that should cover the next steps in more details
15:11:53 <ihrachys> #link https://review.openstack.org/386685 online-upgrades spec
15:12:23 <ihrachys> it's still draft and lacks a lot of details, I plan to work on it this week so that we have a clear written picture till the summit
15:12:32 <ihrachys> reviews are welcome
15:12:38 <ihrachys> even if it's not ready yet :)
15:12:40 <korzen> ihrachys, nice
15:13:07 <electrocucaracha> +1
15:13:24 <manjeets__> cool
15:13:54 <ihrachys> btw if you are at the summit, don't forget to register for the neutron social
15:14:22 <ihrachys> mlavalle sent an email to openstack-dev@ with the topic "[Neutron] Neutron team social event in Barcelona"
15:14:31 <ihrachys> just +1 so that he can count heads in advance
15:14:52 <electrocucaracha> maybe he'll need to find another bigger place
15:15:11 <ihrachys> yea, it's already more than 25 originally planned by him :)
15:15:40 * manjeets__ will miss this summit :(
15:15:43 <ihrachys> before we move on, can we count hands, who's going to Barcelona?
15:15:44 <ihrachys> o/
15:15:54 <ihrachys> manjeets__: :( that's sad
15:16:08 <korzen> o/
15:16:11 <electrocucaracha> o/
15:16:55 <ihrachys> ack. not much, but it's still good to have what we have.
15:17:35 <ihrachys> we'll update the team after the summit. I may push a status update on the mailing list, or other venue. stay tuned.
15:17:56 <ihrachys> #action ihrachys to update the team about summit progress
15:18:27 <ihrachys> #topic Partial Multinode Grenade
15:19:21 <electrocucaracha> ihrachys: I'd like to start helping somehow in this topic, what I can do or where I can start
15:19:49 * electrocucaracha obviously having knowledge of grenade
15:20:03 <ihrachys> electrocucaracha: I was passing some info on that to jschwarz|ooo but he seems busy this time of year. I guess it's good to have you look into it.
15:20:23 <ihrachys> electrocucaracha: basically, we already have a linuxbridge multinode grenade job in experimental queue
15:20:45 <ihrachys> electrocucaracha: the first step would be triggering it with 'check experimental' on some patch, then analyzing failure logs.
15:20:58 <electrocucaracha> ihrachys: do I need a special setup?
15:21:17 <ihrachys> electrocucaracha: if we would have a list of issues seen on a latest check, that would be already some progress
15:21:28 <ihrachys> electrocucaracha: well, it's gate thing, so any neutron patch will do
15:21:39 <ihrachys> electrocucaracha: well not any, but any that e.g. touches neutron/db/...
15:22:07 <ihrachys> electrocucaracha: once we have logs, we can check which tests fail and maybe split the load
15:22:23 <electrocucaracha> ihrachys: ack
15:22:31 <ihrachys> so the first step is collecting the current state of affairs, to understand how far we are from passing.
15:22:45 <ihrachys> electrocucaracha: cool. feel free to ask me in irc on details, and we'll sync during the summit.
15:22:52 <ihrachys> electrocucaracha: thanks for stepping in!
15:23:02 <korzen> speaking of multinode, we should also take a look at multiple neutron server
15:23:26 <ihrachys> korzen: same version? we kinda cover it via api workers don't we?
15:23:45 <korzen> different version
15:24:45 <ihrachys> korzen: well it won't work until online-upgrades is implemented will it?
15:24:46 <korzen> is there any cross project session on multinode testing?
15:25:31 <ihrachys> korzen: but I probably agree that since the goal is to block any unsafe alembic scripts in Ocata, we can just set the job gating right away because there are (hopefully) no new scripts in the tree so far.
15:26:33 <manjeets__> i am interested in helping for grenade jobs but need to start on that
15:26:44 <manjeets__> any documentation I can get started with ?
15:27:17 <ihrachys> manjeets__: you can start with http://docs.openstack.org/developer/grenade/
15:27:44 <ihrachys> manjeets__: there is also https://github.com/openstack-infra/devstack-gate/blob/master/multinode_setup_info.txt that should give you an idea how we deploy multinode in gate
15:27:57 <manjeets__> ihrachys: cool thanks
15:28:18 <korzen> manjeets__, it is also good to know: https://github.com/openstack-infra/devstack-gate
15:28:35 <ihrachys> yeah; specifically that script that deploys everything: https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh
15:28:57 <ihrachys> the script has lots of if-branches for different setups that influence the neutron configuration at test.
15:29:51 <ihrachys> korzen: actually, it's good you asked
15:30:01 <ihrachys> I just found some session that seems very relevant to us
15:30:03 <ihrachys> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16942/cross-project-workshops-rolling-upgrades-and-the-road-to-zero-downtime
15:30:46 <korzen> must have missed it
15:30:48 <ihrachys> I will definitely be there :)
15:30:52 <korzen> yeap
15:30:57 <ihrachys> korzen++
15:31:15 <ihrachys> ok, let's run thru the state of OVO
15:31:16 <ihrachys> #topic Object implementation
15:31:44 <ihrachys> first, re model relocations, it seems like it's all good now right?
15:32:07 <manjeets__> ihrachys: all patches I guess merged
15:32:19 <ihrachys> great. should we close that bug?
15:32:34 <manjeets__> https://review.openstack.org/#/q/topic:bug/1597913
15:32:47 <ihrachys> right, I guess we may close bug 1597913 ?
15:32:49 <openstack> bug 1597913 in neutron "refactor model definitions" [Wishlist,Fix committed] https://launchpad.net/bugs/1597913 - Assigned to Manjeet Singh Bhatia (manjeet-s-bhatia)
15:32:50 <manjeets__> ihrachys: yes we can do that
15:32:58 <ihrachys> ok lemme do it now
15:33:04 <electrocucaracha> mmm not sure
15:33:25 <electrocucaracha> the integration phase hasn't completed
15:33:42 <ihrachys> electrocucaracha: what do you mean?
15:33:52 <ihrachys> electrocucaracha: the bug is just to move models. what's more?
15:34:38 <electrocucaracha> I'm just thinking that maybe we can find another missing model to move when we complete the integration phase
15:34:56 <electrocucaracha> but even in that case, we can reopen that bug right?
15:34:58 <ihrachys> electrocucaracha: if we do, we'll attach it to the bug.
15:35:19 <ihrachys> electrocucaracha: I don't think it's worth keeping it open now that the effort is done for the most part
15:35:38 <electrocucaracha> ihrachys: ok, makes sense
15:36:19 <ihrachys> ok, I moved the bug to Fix Released and Ocata-1.
15:36:29 <ihrachys> so we can now focus on:
15:36:30 <ihrachys> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:36:50 <ihrachys> I know I still owe you all a lot of reviews. sorry for that.
15:37:17 <ihrachys> I think we landed just the SubnetRoute integration, plug RouterRoute object.
15:37:18 <electrocucaracha> ihrachys: last friday, I tried to update the spreadsheet not sure if you want to use it?
15:37:30 <electrocucaracha> https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112
15:37:47 <ihrachys> electrocucaracha: it's nice to have it synced eventually I guess, but I usually just open the topic and see what I may land in the time I have for review.
15:39:10 <manjeets__> ihrachys: i ripped one() from https://review.openstack.org/#/c/381333/ and a separate patch with UT for making landing faster
15:39:13 <manjeets__> https://review.openstack.org/#/c/386875/
15:39:36 <liujiong> names
15:40:12 <ihrachys> manjeets__: ack
15:40:49 <electrocucaracha> ihrachys: I was thinking a way to find OVO dependencies,  I've seen that many depends on Router and Agent ovo
15:41:40 <manjeets__> and electrocucaracha what about joins ?
15:42:13 <manjeets__> is there any decision on how to deal with joins ?
15:43:06 <ihrachys> you mean custom filters that would filter on data from other tables?
15:43:17 <electrocucaracha> manjeets__: our last discussion about those were to create class methods, but I've seen that blogan and asingh_ has been dealing with some classes
15:44:24 <asingh_> https://review.openstack.org/#/c/377114/
15:46:50 <ihrachys> electrocucaracha: asingh_: blogan: just wondering, let's say there is that _ipam_get_subnets. would it be hard to make get_objects support host= and service_type= filters and then reuse get_objects as a single entry point for all possible filtering for an object?
15:47:24 * blogan just got to his compute and booting his brain
15:48:13 <blogan> ihrachys: keep ipam_get_subnets in teh ipam backend mixin module?
15:48:48 <ihrachys> blogan: could be that the ipam logic (exceptions etc.) would indeed belong to the mixin while the get/filtering part would stay in the object.
15:49:14 <ihrachys> so in that case, probably _find_candidate_subnets would stay in the object, and _ipam_get_subnets would be outside.
15:50:02 <blogan> ihrachys: i feel like we tried that, but it didnt work, but i can't remember why at this point, that was the first thing asingh_ tried i believe
15:50:28 <electrocucaracha> blogan: wasn't the make dict method?
15:50:32 <ihrachys> ok, I will probably need to dig previous PSs.
15:50:50 <blogan> ihrachys: im digging too to refresh my memory, ill get back to you on that
15:51:44 <korzen> yes it was make_subnet_dict
15:51:48 <electrocucaracha> but regarding the manjeets__ question, should we continue using the same criteria, try to create class methods
15:51:53 <blogan> ihrachys: oh i think the problem was that _ipam_get_subnets would then have to call into the SUbnet object for the other methods, but those otehr methods return a single SA query, and each method builds upon that query
15:52:09 <blogan> electrocucaracha: that was a possibility, but pretty sure its a lot more work than we want
15:52:51 <ihrachys> blogan: well, the calling code could instead set query filters upfront and then pass all needed into get_objects, instead of passing sqla query around.
15:52:54 <blogan> ihrachys: so technically those methods that return the query object would have to be public methods on the Subnet object, and them returning queries makes no sense
15:53:08 <ihrachys> anyhow, I would need to read the thing thru not to make myself look sillier than I am
15:53:29 <blogan> ihrachys: yeah we can discuss on the review, i'm sure i'm looking silly
15:53:32 <ihrachys> blogan: yes, returning any sqla primitives from objects is not what we want :)
15:54:08 <ihrachys> ok, one thing to mention is, HenryG is working on transitioning all objects in tree to project_id field: https://review.openstack.org/#/c/382659/
15:54:22 <ihrachys> his work is blocked because we have a fix to do in base class though
15:54:33 <ihrachys> korzen has a patch for that: https://review.openstack.org/#/c/384949/
15:54:49 <ihrachys> I haven't reviewed the latest version just yet though
15:55:11 <korzen> ihrachys, yes so I have to fix one test
15:55:24 <ihrachys> looking at the test case, it seems like it does the job neatly, keeping tenant_id behaviour identical to project_id one
15:55:32 <korzen> since the test is requiring to have the project-id in API out
15:56:17 <korzen> and qos policy do not have project-id
15:56:21 <ihrachys> korzen: ack, I guess it's test issue?
15:57:16 <ihrachys> korzen: oh I think I see what's going on. that's because you dropped the populate_project_info() call
15:57:22 <korzen> yes
15:57:26 <ihrachys> korzen: maybe keep it to qos policy class for now
15:57:34 <ihrachys> and it will go away with the HenryG's patch merged
15:57:34 <korzen> qos and trunk
15:57:38 <korzen> ok
15:58:04 <ihrachys> cool, awesome sauce
15:58:26 <ihrachys> #topic Other patches on review
15:58:41 <manjeets__> https://review.openstack.org/#/c/338625/
15:58:48 <manjeets__> ihrachys: ^
15:59:07 <ihrachys> anything specific apart from reviews needed?
15:59:42 <ndahiwade> https://review.openstack.org/#/c/382567/10
16:00:01 <ndahiwade> ihrachys: Could you confirm the approach is correct here?
16:00:11 <ihrachys> ok, no need to raise each patch, it's a matter of reviewers sucking :)
16:00:14 <ihrachys> ndahiwade: ack, will check
16:00:17 <ihrachys> we are running out of time
16:00:22 <dasanind_> ihrachys: Integration of Vlanallocation, Vxlanallocation, GeneveAllocation and GreAllocation is dependent upon these OVOs.
16:00:22 <ihrachys> just one thing before I end the meeting
16:00:40 <ihrachys> armax started to assess stadium projects: https://review.openstack.org/#/q/project:openstack/neutron-specs+branch:master+topic:stadium-implosion
16:00:44 <dasanind_> ihrachys: It will be good to have these merged before proceeding with the integration
16:00:46 <ndahiwade> ihrachys:thanks
16:00:50 <ihrachys> it's nice to see grenade testing being a criteria for inclusion.
16:00:59 <ihrachys> ok need to call it a day
16:01:01 <ihrachys> thanks everyone
16:01:03 <ihrachys> #endmeeting