13:01:34 <mestery> #startmeeting neutron-juno-3-bp-review
13:01:35 <openstack> Meeting started Thu Aug 28 13:01:34 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:38 <openstack> The meeting name has been set to 'neutron_juno_3_bp_review'
13:01:46 <marun> mestery: yes
13:01:46 <mestery> #link https://etherpad.openstack.org/p/neutron-juno-release Etherpad to track reviews for the team
13:01:54 <salv-orlando> I will be around for 30 minutes only
13:02:04 <mestery> salv-orlando: Thanks for joining us, hopefully we can be done in 30 minutes ;)
13:02:20 <mestery> So, the goal of this gathering is to review the BPs listed in that etherpad
13:02:34 <mestery> And to get any high level issues out now to try and ensure we can merge these before feature freeze.
13:02:48 <mestery> I've placed all the reviews I'm aware of for each BP in that etherpad
13:02:54 <mestery> If I've missed any, please go ahead and add them there
13:03:06 <mestery> We can use this to track them given the load on the gate
13:03:08 <marun> I'm going through the l3 ha reviews one-by-one and since I'm in the same tz as assaf hope to contribute to it getting merged
13:03:24 <mestery> marun: Excellent, thank you!
13:03:32 <mestery> marun: Any large systemic issues you've uncovered so far?
13:04:14 <marun> mestery: nothing yet, the difficulty is in testing but amuller has some ideas on how to do more with functional
13:04:25 <mestery> marun amuller: Excellent!
13:04:38 <mestery> If I'm not mistaken, L3 HA plays a role in the DVR story as well, right carl_baldwin?
13:04:41 <carl_baldwin> I’ve been through a round of reviews on them myself.  Uncovered a few bugs but I think they’ve been addressed in recent updates.
13:04:47 <amuller> They have
13:05:01 <mestery> Awesome, thanks for your work on these amuller
13:05:12 * amuller is being paid
13:05:14 <carl_baldwin> mestery: There are some outstanding issues with HA and DVR together.
13:05:15 <amuller> =D
13:05:32 <mestery> carl_baldwin: Are those tracked as bugs? If so, lets add the bugs/reviews to the etherpad
13:05:34 <salv-orlando> carl_baldwin: but DVR does not require HA or vice versa is that right?
13:05:44 <amuller> salv-orlando: no
13:05:51 <amuller> you can create a router as either HA or distributed right now
13:05:59 <amuller> together doesn't work, but it should / is planned
13:06:11 <mestery> amuller: Is there a bug tracking that?
13:06:14 <amuller> mestery: not yet
13:06:20 <mestery> amuller: OK, thanks :)
13:06:25 <carl_baldwin> mestery: I will ensure the bugs exist today and are added to the etherpad.
13:06:31 <mestery> carl_baldwin: Thank you sir!
13:06:44 <amuller> mestery: but it will be my top priority, to integrate HA and DVR, once we get the HA code merged
13:06:44 <mestery> OK, so I feel as if L3 HA is in good shape, anything else to cover for that one?
13:06:49 <mestery> amuller: ack
13:07:13 <mestery> #info L3 HA is in good shape, marun and carl_baldwin are covering reviews from a core perspective
13:07:25 <mestery> #info L3 HA and DVR integration to be tracked by bugs and fixed post L3 HA merge
13:07:48 <mestery> OK, lets move on to the next BP, ipset
13:07:57 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security)
13:08:00 <carl_baldwin> #action carl_baldwin will link bugs to etherpad
13:08:25 <mestery> The ipset work has seen a few revisions on it's patches already as well
13:08:42 <mestery> As near as I can tell, there are 2 reviews active for this BP
13:08:53 * mestery hasn't looked at them this morning yet
13:09:17 <ajo> There's a devstack one that prevents tempest testing from happening yet: https://review.openstack.org/#/c/113453/
13:09:27 <ajo> We need ipset installed when devstack is deployed
13:09:40 <mestery> #link https://review.openstack.org/#/c/113453/ devstack patch for ipset
13:10:01 <ajo> I suppose that's the reason shihanzhang was slowed down on that, also, that work is depending on the RPC changes , so it needs a rebase
13:10:06 <mestery> ajo: Thanks for the link, looks like it has 1 QA +2 already
13:10:23 <ajo> yes, I just saw it, that's good,
13:10:58 <ajo> I will be testing it myself during the start of next week
13:11:01 <salv-orlando> mestery, ajo: so the sg blueprints are pretty much serialized. But I want both of them merged. I think ipsets will go to ffe - and I’d be ok with it
13:11:10 <mestery> salv-orlando: ++
13:11:18 <salv-orlando> anybody feels differently? Perhaps from the testing perspective, is the current coverage deemed sufficient?
13:11:32 <salv-orlando> I mean the tests we run in tempest for security groups
13:11:33 <mestery> ajo: Is there functional testing of ipset? I think I saw that but wanted to confirm.
13:11:55 <mestery> I have one other concern with ipset: Is it allowed to be turned off so you can revert back to iptables?
13:12:11 <ajo> No functional testing for ipset yet, I was waiting on the functional agent framework to be ready to add those.
13:12:12 <salv-orlando> mestery: I discussed this with shinazhang...
13:12:23 <mestery> ajo: ack
13:12:25 <ajo> mestery, it can be switched off
13:12:35 <mestery> ajo: double ack, thanks
13:12:48 <ajo> so I believe it's not an high risk, we may ship it disabled by default if merged for J
13:13:18 <marun> are functional tests planned for ipset bp?
13:13:18 <mestery> ajo: I was talking to markmcclain, and our conclusion was we'd rather have it enabled by default to sort out bugs, we can always revert the default later if we hit issues.
13:13:21 <mestery> Does that sound ok?
13:13:31 <amuller> mestery++
13:13:36 <carl_baldwin> mestery: +1
13:13:48 <ajo> marun, can't remember I think I proposed it, and I believe we must add those
13:13:59 <marun> ajo++
13:14:03 <amuller> I think functional testing would boost our confidence (At least mine) so we could enable it by default
13:14:06 <mestery> ajo: If you have those, can you add the review in the etherpad please?
13:14:12 <mestery> amuller: ++
13:14:30 <salv-orlando> marun: I reckon functional tests are interesting there. ipsets is being developed within the current firewall driver afaict.
13:14:53 <ajo> mestery, don't have them, but I can work on them during the testing process at the start of next week
13:14:57 <salv-orlando> it seems there is no change in RPC API wrt standard iptables based IPset
13:15:04 <mestery> ajo: OK, thanks!
13:15:04 <salv-orlando> beyond the other change from ajo of course
13:15:51 <mestery> OK, so ipset looks to have a bit of work left here I think
13:16:05 <mestery> But looks like we can get a FFE if needed, I would support that as salv-orlando indicated.
13:16:35 <mestery> Shall we move to the next one?
13:16:42 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/security-group-rules-for-devices-rpc-call-refactor) Security Group RPC refactor
13:17:04 <mestery> I think this one needs to merge before ipset, per salv-orlando's comment
13:17:12 <ajo> correct
13:17:19 <mestery> salv-orlando: I think amotoki has some patches which may affect this as well, isn't it so?
13:17:32 <mestery> Starting here: https://review.openstack.org/#/c/115799/
13:17:34 <salv-orlando> mestery: we’re just smotthing the last details there and amotoki’s patches are pretty much a prerequisite
13:17:42 <mestery> #link https://review.openstack.org/#/c/115799/
13:17:54 <mestery> salv-orlando: The first one in amotoki's series failed jenkins, I have rechecked it this morning
13:17:59 <salv-orlando> rpc versioning was a bit messed up - not ajo’s fault. amotoki’s fixed it
13:18:03 <ajo> yes, the versioning issues have been ironed out but need to be reviewed in conjunction with amotoki's patch
13:18:17 <salv-orlando> mestery: yup horizong has been crashing the gate yesterday
13:18:34 <mestery> salv-orlando: ack
13:18:51 <salv-orlando> I think if we keep an eye on both amotoki’s and ajo’s patches we can manage to merge by the end of the week
13:18:59 <ajo> salv-orlando, if it's clear amotoki's patch will merge, I believe we should rebase the SG RPC work on top now
13:19:01 <mestery> salv-orlando: Agreed
13:19:14 <mestery> ajo: His first patch should go in today, I think his other ones are close too
13:19:14 <salv-orlando> ajo: that was an implicit assumption for me ;)
13:19:40 <salv-orlando> 2nd and 3rd were ok for me ; 4th has a few nits, but nothing worrying
13:19:57 <mestery> #info The plan is to merge amotoki's RPC refactor patches and the SG RPC refactor patches by end of the week
13:20:01 <mestery> salv-orlando: ++
13:20:06 <obondarev> actually amotoki's first patch in the series was already merged: https://review.openstack.org/#/c/115798/
13:20:31 <mestery> obondarev: Thanks for the clarification, it's his second one which hit jenkins failure :)
13:20:40 <ajo> salv-orlando, I tested all the scenarios and combinations of neutron-server / openvswitch-agent during upgrades, and all worked
13:21:11 <ajo> The auto-detection of old rpc, and fallback works very well
13:21:19 <mestery> OK, we made it through the list in 20 minutes, nice work team. :)
13:21:27 <mestery> Any other things to discuss in the 10 minutes we have left?
13:21:35 * mestery just made the meeting 30 minutes right there
13:21:36 <ajo> I would like to ask about this: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/agent-child-processes-status,n,z
13:21:48 <mestery> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/agent-child-processes-status,n,z
13:22:04 <mestery> ajo: This is medium priority, and would be a nice enhancement I think
13:22:07 <ajo> I'm happy with the status, and I may only change ProcessesManager class name into ProcessesMonitor
13:22:11 <mestery> Looks to have some core +2s on a few patches already
13:22:52 <salv-orlando> ajo, mestery: I think what we would like to have beyond a process monitor is the ability of reflect failures in processes in object status
13:23:09 <salv-orlando> ie: a subnet with dhcp enabled whose dnsmasq crashes - should be in error state
13:23:13 <salv-orlando> or down or whatever.
13:23:26 <salv-orlando> this is probably orthogonal to ajo’s work. I need to re-read the spec.
13:23:41 <ajo> salv-orlando, I could follow up doing that for K, sounds reasonable
13:23:47 <mestery> ajo: ++
13:23:54 <salv-orlando> anyway I said this because I’m a boring pedant guy
13:24:00 <mestery> salv-orlando: Of course ;)
13:24:11 <ajo> nah, makes sense to have such info centralized at neutron-server ;)
13:24:24 <mestery> #info salv-orlando to re-read process monitor spec and coordinate response with ajo
13:24:30 <salv-orlando> salv-orlando jlibosva and akamishnikova also have worked on a blueprint for consolidate db migrations
13:24:39 <salv-orlando> it’s a lot of code - but it’s easy to review
13:24:53 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/reorganize-migrations
13:24:56 <mestery> salv-orlando: That one?
13:25:01 <salv-orlando> mestery: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/reorganize-migrations,n,z
13:25:03 <salv-orlando> yup that one
13:25:07 <mestery> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/reorganize-migrations,n,z
13:25:20 <mestery> salv-orlando: OK, this one is also something we should strive to merge
13:25:21 <salv-orlando> it basically allows us to get rid of the conditional logic for generating migrations
13:25:28 <mestery> Awesome
13:25:49 <salv-orlando> salv-orlando: I can +2 the patches where I’m not an author. markmcclain has been reviewing them too.
13:26:23 <salv-orlando> we’re addressing a few comments still, but I think they should be ready for the last push by the end of the week.
13:26:27 <salv-orlando> that’s all from me
13:26:27 <mestery> salv-orlando: I'll work to find some other core +2s on those as well.
13:26:30 <mestery> salv-orlando: Thanks!
13:26:39 <obondarev> salv-orlando: I was reviewing some too, will continue
13:26:50 <mestery> OK, anything else or shall we end this 4 minutes early?
13:27:07 * markmcclain demands is goes longer since he showed up late
13:27:12 <mestery> markmcclain: hahahahah
13:27:19 <mestery> markmcclain: That's what logs are for ;)
13:27:20 <ajo> :-)
13:27:21 <markmcclain> sorry… I'll ready the scrollback to catchup
13:27:38 <salv-orlando> what about other high bluepritns such as lbaas improvement, ml2 hierarchial?
13:27:58 * salv-orlando has no idea of how many spelling errors the last word had
13:28:00 <mestery> salv-orlando: ml2 hierachichal is in decent shape, I don't see rkukura here to comment though
13:28:08 * mestery mispelled in a different way
13:28:19 <mestery> LBaaS V2 is likely to land in the incubator salv-orlando
13:28:40 <mestery> Lets keep the focus for the next week and try to merge the features we all discussed here
13:28:52 <haleyb> https://review.openstack.org/#/c/70090/ ?  I know you just moved the blueprint out of J-3 but i'm trying to update the review, just hitting alembic migration issues
13:28:55 <mestery> The gate is under heavy load, lates take advantage of cores in non-US timezones when we can :)
13:29:00 <salv-orlando> mestery: I know that. it’s just that keeping it high in launchpad for j-3 sets expecation in users
13:29:19 <mestery> salv-orlando: Ah, got it, well, once markmcclain and I get the incubator up, we'll adjust things. But I see your point.
13:29:52 <mestery> haleyb: I moved that out of Juno-3 because of the lack of movement, it would be hard for me to move it back in at this point. :(
13:29:54 <salv-orlando> in the last minutes i think that if anybody has a point for raising priority of low blueprints they should make it on the ML ASAP
13:30:27 <salv-orlando> I’m receiving pings from contributors and I keep saying that I need to give priority to medium/high blueprints
13:30:49 <mestery> salv-orlando: I think at this point we need to focus on the medium/high stuff
13:30:56 <haleyb> mestery: well, maybe if i can get it to pass jenkins you'll reconsider?  it's not a big change
13:30:57 <mestery> and spend cycles on low only if time allows
13:31:15 <mestery> haleyb: Lets talk offline, we could do that if you get it moving again
13:31:24 * mestery does not it's a small change.
13:31:27 <salv-orlando> mestery: agreed. This is what I will say the next time I’m invited to give a “final push” to a blueprint ;)
13:31:29 <mestery> haleyb: I think it was medium priority as well
13:31:32 <devvesa> so the place to ask for raising priority is the ML?
13:31:41 <mestery> devvesa: Yes.
13:31:53 <HenryG> I am pretty sure there are some ML2 BPs that they want merged, but you need rkukura to clarify.
13:31:55 * mestery notes salv-orlando and he just opened up the ML to many requests for priority raising now
13:31:56 <devvesa> mestery: ok!
13:32:10 <mestery> OK, thanks everyone!
13:32:16 <salv-orlando> mestery: better the ml2 than direct messages on IRC
13:32:17 <mestery> Lets see what we can do this week with merging these BPs.
13:32:23 <mestery> salv-orlando: ++
13:32:24 <salv-orlando> ahhh I just wrote ml2 instead of ml
13:32:24 <mestery> :)
13:32:29 <mestery> hahahahahahha
13:32:39 <ajo> thank you all
13:32:47 <ajo> the secret ml
13:32:50 <mestery> Also, if people hit large issues while reviewing these BPs, please raise the issues quickly in-channel or on the ML
13:32:56 <ajo> (joking)
13:33:00 <mestery> ajo: :PO
13:33:04 <mestery> ajo: :P
13:33:07 <ajo> :)
13:33:10 <mestery> #endmeeting