08:00:11 <oanson> #startmeeting Dragonflow
08:00:12 <openstack> Meeting started Mon Jan  8 08:00:11 2018 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:15 <openstack> The meeting name has been set to 'dragonflow'
08:00:19 <snapiri> Hi
08:00:29 <dimak> Good morning
08:00:32 <lihi> Hi
08:01:04 <oanson> irenab, are you in?
08:01:10 <oanson> leyal-, are you in?
08:01:15 <irenab> hi
08:01:35 <leyal-> Hi
08:01:52 <oanson> #info snapiri dimak lihi irenab leyal- in meeting
08:01:55 <oanson> #topic Roadmap
08:02:17 <oanson> Let's stick to the things there's progress:
08:02:19 <oanson> DNS
08:02:48 <oanson> the spec is up and there's some discussion there
08:02:53 <oanson> Is there something we need to raise here?
08:03:21 <oanson> #link DNS spec https://review.openstack.org/#/c/527956/
08:04:08 <lihi> I don't think there are major issues. irenab and snapiri asked I'll add the DB definition with more details
08:04:49 <oanson> Do you think it is doable by end of February?
08:04:54 <oanson> lihi, ^^^ ?
08:05:05 <lihi> Yes
08:05:27 <oanson> All right. Then let's try to close the spec as soon as possible (say, this week)?
08:06:10 <lihi> Sure
08:06:15 <oanson> Cool!
08:06:26 <oanson> Upgrades - there is some discussion on the spec
08:06:46 <oanson> #link Upgrade spec https://review.openstack.org/#/c/500647/
08:07:06 <oanson> There are two options on the spec
08:07:16 <dimak> Zuul's unhappy ;)
08:07:39 <oanson> I sent a recheck. I don't think it's me... :D
08:07:43 <irenab> Of the spec?
08:07:53 <oanson> yes
08:08:25 <oanson> So there are two options: two migration scripts, or a migration + online upgrade
08:08:36 <oanson> Or two migration script, and then online upgrade.
08:08:58 <oanson> I don't have a problem saying that upgrades that can't be done with migration scripts are not supported.
08:09:11 <irenab> oanson, such as?
08:09:12 <oanson> Since I *really* don't want online upgrades
08:09:27 <dimak> Voted on spec
08:09:28 <oanson> irenab, such as anything requiring IPAM
08:10:04 <irenab> oanson, what is the case with IPAM?
08:10:17 <oanson> Basically, everything we have today (including DHCP) can be done that way
08:10:28 <oanson> irenab, none yet that I know of
08:11:06 <lihi> Why will it require IPAM?
08:11:11 <oanson> It won't
08:11:15 <oanson> I think there's a mixup
08:11:35 <oanson> currently, all upgrades we need can be done with two migration scripts. We don't need e.g. IPAM or other such services.
08:11:59 <oanson> If ever we will need IPAM during upgrade, it won't be supported by our upgrade method.
08:11:59 <leyal-> irenab. let assume that we will have a topology change that will require a new port , we will need to assign an ip to this port
08:12:52 <irenab> oanson, so with 2 migration, dev will provide neutron and df scripts each to be invoked during neutron/df db migration process. Correct?
08:12:58 <snapiri> oanson: none of the terms you use here (upgrade / migration) is from Neutron DB, right?
08:13:04 <oanson> irenab, yes
08:13:40 <oanson> snapiri, 'alembic migration' is the Neutron upgrade process
08:13:48 <oanson> s/Neutron/Neutron DB/
08:13:49 <irenab> leyal-, I think that use case you raised is more than just DB upgrade
08:14:28 <irenab> I think maybe case like this should be handled as exceptions
08:15:49 <lihi> leyal-, if the neutron server is down (option 1), can we even have topology changes?
08:15:52 <irenab> probably involving dedicated upgrade procedure
08:16:23 <irenab> oanson, what about changing subnet to become core df model entity?
08:16:48 <oanson> irenab, what about it?
08:17:07 <oanson> The upgrade code is here: https://review.openstack.org/#/c/527717
08:17:09 <leyal-> lihi , yes , i talked about topology changes that caused by the upgrade , like virtual ports for apps ..
08:17:53 <oanson> leyal-, I think this is the part that will need specialised changes anyway.
08:17:56 <irenab> oanson, so it Noop for neutron and the script in the change for df?
08:18:18 <oanson> I think lihi also meant that you can't do that in a Neutron-only upgrade (i.e. Neutron doesn't support that feature)
08:18:25 <oanson> irenab, yes
08:18:40 <oanson> The only upgrade script we have that needs Neutron DB changes is DHCP
08:19:23 <oanson> #link DHCP upgrade https://review.openstack.org/#/c/527716
08:19:28 <oanson> I added the relevant comment
08:20:16 <irenab> oanson, leyal- so looks like DHCP/Topology change can be resolved by 2 scripts
08:20:26 <oanson> irenab, yes
08:20:27 <oanson> leyal-, are you convinced?
08:20:32 <leyal-> I think that the  currently dhcp app is to only app that use neutron for creating new object..
08:21:13 <oanson> leyal-, yes. But even that is solvable with offline scripts
08:22:04 <leyal-> oanson, i will go with majority decision :)
08:22:36 <oanson> All right. So do we have consensus on option 1: Two offline scripts?
08:22:42 <oanson> Speak now or forever hold your pieces
08:22:46 <irenab> +1
08:22:52 <lihi> +1
08:23:02 <dimak> aye
08:23:08 <snapiri> yes
08:23:14 <oanson> Hooray!
08:23:27 <oanson> I'll update the spec today and start cracking
08:23:50 <oanson> Anything else for roadmap?
08:24:13 <leyal-> yep
08:24:21 <oanson> leyal-, shoot!
08:25:12 <leyal-> still working on the comment's on the kuryr df drivers . hope that i will came with primitive IPAM patch -  today or tommarow ..
08:25:51 <oanson> #link Kuryr-Dragonflow patch https://review.openstack.org/#/c/529971/
08:25:57 <oanson> Cool
08:26:22 <oanson> Anything else for roadmap?
08:27:05 <oanson> #topic Bugs
08:27:08 <oanson> So
08:27:16 <oanson> The end of the cycle is coming fast
08:27:24 <irenab> oanson, date?
08:27:26 <oanson> And I think now would be a good time to start tackling bugs
08:27:36 <oanson> End of February, if I recall.
08:28:07 <oanson> 28th of February
08:28:30 <oanson> So that gives us almost two months to tackle bugs, and we have quite a few
08:28:48 <snapiri> There is the biggie with the SG...
08:29:00 <oanson> Yes. We'll get to that in a minute
08:29:23 <oanson> Basically, so we don't step on each other's toes, if you start looking at a bug, assign it to yourself.
08:29:39 <oanson> Don't feel bad about unassigning it later if you feel it's boring
08:30:16 <oanson> We have 14 High bugs. I think we can manage it. Except the ZMQ active-port bug, which I want to demote.
08:30:23 <oanson> (Unless there are objections?)
08:30:28 <irenab> link?
08:30:30 <oanson> I speak of https://bugs.launchpad.net/dragonflow/+bug/1716933
08:30:31 <openstack> Launchpad bug 1716933 in DragonFlow "ZMQ and Active Port Detection app try to bind to the same port" [High,New]
08:31:20 <snapiri> oanson: is this the one failing the devstack?
08:31:39 <oanson> Basically it is the entire issue we're having with the 'multiproc' direction. I think the correct solution is to move to broker-only pub/sub.
08:31:51 <oanson> snapiri, No. We disabled these tests
08:32:38 <snapiri> oanson: I meant is this the one I encountered when I tried to deploy devstack on my VM...
08:32:44 <oanson> Yes
08:32:48 <oanson> Yes it is.
08:33:22 <snapiri> Any solution to that would be appreciated as it is super annoying
08:33:31 <oanson> There was a lot of research done here and many ideas already thrown around. But I think it is a. not so important due to the etcd pub/sub mechanism, and b. a lot of work, so I think it can wait for R cycle
08:33:45 <oanson> snapiri, yes: Use the etcd pub/sub and not ZMQ
08:33:51 <oanson> Or use redis
08:34:26 <oanson> Now for the really interesting bug:
08:34:38 <irenab> oanson, about this baug
08:34:42 <oanson> #link Security groups + FIP bug https://bugs.launchpad.net/dragonflow/+bug/1740739
08:34:43 <openstack> Launchpad bug 1740739 in DragonFlow "Security group mismatch for floating IP" [High,New]
08:34:52 <oanson> irenab, yes?
08:35:24 <irenab> Can you please update in the bug about the etc/redis alternatives and and reason why reducing the priority or making this non issue
08:35:36 <oanson> Sure. Will do
08:36:45 <oanson> irenab, Done
08:36:56 <oanson> Re bug 1740739
08:36:57 <openstack> bug 1740739 in DragonFlow "Security group mismatch for floating IP" [High,New] https://launchpad.net/bugs/1740739
08:37:23 <oanson> Basically, the issue is that today security groups takes the private IP of the VMs when building the OpenFlow rules.
08:37:44 <oanson> Even for Security Group based rules (i.e. saying 'allow for ports in Security Group B')
08:38:14 <oanson> This breaks when using FIP, since the packet arrives with the floating IP (external) and not the VM's IP
08:38:21 <oanson> There's a proposed solution on the bug
08:38:32 <oanson> And I'm reading the code to understand how Neutron does it.
08:38:45 <oanson> I should be able to update the bug with that as well by EOW
08:39:23 <oanson> Anything else for this bug?
08:39:35 <oanson> Anything else for bugs, in general?
08:40:15 <oanson> #topic Open Discussion
08:40:20 <oanson> The floor is for the taking
08:41:24 <oanson> LAst chance?
08:41:30 <oanson> Last*
08:41:55 <oanson> Cool.
08:42:08 <oanson> Thanks everyone for coming.
08:42:20 <snapiri> cheers
08:42:29 <oanson> #endmeeting