08:00:57 <oanson> #startmeeting Dragonflow
08:00:58 <openstack> Meeting started Mon Dec 25 08:00:57 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:01 <openstack> The meeting name has been set to 'dragonflow'
08:01:19 <irenab> hi
08:01:21 <dimak> hey
08:01:26 <oanson> Roll call! Lift your hands, say yeah!
08:01:26 <oanson> o/
08:01:35 <dimak> \o/
08:01:43 <leyal> HI
08:01:54 <oanson> Let's give lihi a second to join the party
08:02:21 <lihi> Hi
08:02:25 <oanson> All right!
08:02:35 <oanson> #info irenab dimak leyal lihi in the meeting
08:02:39 <oanson> #topic Roadmap
08:02:49 <oanson> LBaaS - no progress
08:02:52 <oanson> DNS - lihi ?
08:03:38 <lihi> I uploaded yesterday an update to the spec
08:03:55 <irenab> link?
08:04:03 <oanson> You must have a bug - it fails the gate :(
08:04:12 <oanson> #link DNS as a service spec https://review.openstack.org/#/c/527956/
08:04:35 <dimak> Must be too controversial
08:05:09 <irenab> maybe recheck will fix
08:05:26 <lihi> Christmas fails the gate :(
08:06:19 <oanson> Do we have a decision on how to implement? virtual port (like metadata) or hijack DNS packet?
08:07:20 <dimak> Is performance comparable?
08:07:30 <leyal> oanson , did we must to bind between the virtual-port and external-app ?
08:07:49 <lihi> Currently the virtual port is the prefered option
08:08:03 <oanson> dimak, theoretically, the service (metadata-like) option should be more performant. But for actual numbers, we need to run tests.
08:08:11 <oanson> leyal, sorry?
08:08:33 <oanson> irenab, I don't see your vote on the spec. Do you have an opinion?
08:08:59 <irenab> oanson, I missed the spec. Just added it to the queue, will rview and vote
08:09:00 <leyal> oanson, can we do virtual-port , but still run in context of the controller process ?
08:09:34 <oanson> leyal, yes. We can have the controller listen on the tap device.
08:09:38 <irenab> I wonder what are the benefits to have it as a separate service
08:10:37 <oanson> irenab, 1. if one process crashes, it doesn't take the other with it. 2. If one process hogs the CPU, the other can still do its thing (since we use cooperative threading)
08:11:02 <oanson> 3. separation of responsibilities: control (DF Controller) vs. data (DNS service)
08:11:35 <irenab> oanson, so why other Apps are not spearated?
08:11:42 <irenab> separated
08:12:19 <oanson> metadata is the only other app that has this behaviour (i.e. needing to parse the packets outside of OVS/OpenFlow). And metadata is separated.
08:12:39 <leyal> dhcp ..
08:12:42 <irenab> once we go for IGMP, it will be the third?
08:12:55 <oanson> LBaaS is also planned to be separated for anything stronger than OpenFlow can provide
08:13:05 <irenab> I just think we should have proper pattern to decide which way to go
08:13:13 <oanson> irenab, I think IGMP is a special case, since IGMP packets will control the installed flows.
08:13:44 <oanson> leyal, yes, dhcp is the odd one out. It was written before the metadata-like pattern was invented
08:15:08 <irenab> I am afraid we may end up with many services per compute node, need proper mechanisms to keep them alive and decide if compute is functional
08:15:25 <oanson> I'm willing to put DHCP as a special case too, since it's broadcast based (not unicast) and happens before the network is strictly set up
08:16:01 <oanson> irenab, true. But I'm not sure moving this instability into the DF controller is the correct solution
08:16:27 <oanson> We have systemd. We have service self-notification. We can leverage these to build something
08:16:37 <irenab> oanson, me too. We should see the whole picture. Lets continue discussion over the patch?
08:16:53 <oanson> Yes and no. I want to separate the two things
08:17:02 <oanson> I don't want this to block DNS
08:17:20 <oanson> If we agree that a separate service, regardless of this issue, is the correct way to go, let's run with that.
08:17:32 <oanson> In parallel, let's see how we construct a services framework
08:17:39 <irenab> I still need to review the spec, will vote asap
08:18:01 <oanson> Sure. I just meant that I don't want this issue to block DNS.
08:18:09 <irenab> sure, agreed
08:18:15 <oanson> Are we done for DNS?
08:18:55 <oanson> Upgrades
08:19:04 <oanson> #link Upgrades spec https://review.openstack.org/#/c/500647/14/doc/source/specs/database_migration_and_upgrade.rst
08:19:30 <oanson> This is another voting thing
08:19:30 <dimak> I still owe a comment there
08:19:38 <oanson> First of, lihi, dimak, you both have to vote
08:19:50 <oanson> (So does snapiri, but they're PTO)
08:20:32 <lihi> 👍🏿
08:20:43 <oanson> leyal, you want to take a minute to raise your concerns with two offline migration scripts?
08:21:09 <leyal> well not more that what i wrote in the patch.
08:21:57 <leyal> the main issue is that we use neutron for things like IPAM
08:22:01 <leyal> MAC allocation
08:22:31 <oanson> I agree this shouldn't happen offline
08:22:46 <leyal> segmentation allocation and maybe more - and if upgrade need to create a new port or new network it's can be an issue
08:22:50 <oanson> But is there a scenario for this? In e.g. DHCP, we remove ports, not create ports
08:23:27 <oanson> And if such a scenario exists, how do Neutron solve it?
08:23:41 <leyal> DHCP create new ports per lswitch .
08:24:25 <oanson> The upgrade script can reuse the first port (since now there are ports per subnet). If no such port exists, then there's no dhcp enabled subnet, and we don't need an lswitch dhcp lport
08:24:25 <leyal> if we delete and add the ports to neutron when neutron is alive it's will done all that for us ..'
08:25:15 <leyal> oanson , sure but that a workaround - maybe in future changes it will not fit ..
08:25:45 <oanson> That's why I'm looking for a scenario. I think the benefits of two offline scripts is worth one workaround.
08:25:52 <oanson> But maybe not four
08:27:27 <oanson> I suggest we try and understand how Neutron solves this issue. I'm sure they have. At the moment, I don't think DHCP is blocking the two offline migration scripts solution, and I stand by my preference to that option.
08:27:28 <leyal> oanson , i don't sure that we could predict if this issue will appear in future changes - but i think it defiantly possible ..
08:27:41 <leyal> definitely*
08:27:44 <oanson> True
08:28:37 <oanson> But there will always be a limit to what we can support. Is supporting this worth the trade-off?
08:29:10 <leyal> well, i vote for the online option :)
08:29:42 <dimak> I'll read the comments and vote
08:29:45 <oanson> All right. This looks like an impass :) Let's keep discussion on the spec. I'll look up how Neutron handles this in their upgrades. And we'll take it from there.
08:29:53 <oanson> Worse comes, we'll vote in two weeks time
08:30:07 <oanson> #action oanson look up how Neutron handles IPAM / port creation during upgrade
08:30:27 <oanson> Deployment - OSA - lihi, you're up
08:31:02 <lihi> It is not stable, but I managed to make the deployment work occasionally
08:31:20 <lihi> The main problem with it that each run takes ~4 hours, so it takes time
08:32:27 <oanson> All right
08:32:41 <oanson> RPM packaging -
08:32:49 <oanson> Gimme a sec to find the bug link
08:33:10 <oanson> Working on getting python-jsonmodels into RDO. ( https://bugzilla.redhat.com/show_bug.cgi?id=1525362 )
08:33:10 <openstack> bugzilla.redhat.com bug 1525362 in distribution "Review Request: python-jsonmodels - Models to make easier to deal with structures that are converted to, or read from JSON in python" [Unspecified,Post] - Assigned to lars
08:33:42 <oanson> It's built. I think we just need someone to push it in.
08:33:56 <oanson> But it's Christmas, so we may need to wait a week or two
08:34:56 <oanson> Dirk Mueller also said he'll look into the suse ci failure - I told him it's jsonmodels missing in suse. I doubt he'll volunteer to add it :)
08:35:04 <oanson> But I'm taking it one step at a time
08:35:16 <oanson> Unless there's a rush I should know about?
08:35:46 <irenab> oanson, is it mandatory for OSA?
08:35:53 <oanson> irenab, no
08:36:01 <oanson> OSA take it from pip or from the git repo
08:36:27 <irenab> good, thanks
08:36:52 <oanson> Migration to Dragonflow - As far as I know, there's no progress.
08:37:08 <oanson> Gates
08:37:13 <oanson> Grenade gate - pending on the spec
08:37:24 <irenab> oanson, is there someone who was interested in the migration?
08:37:40 <dimak> Shachar did some work to split gate configurations
08:37:43 <oanson> irenab, I don't recall that of the top of my head
08:38:02 <oanson> dimak, yes
08:38:09 <oanson> #link Split gate configurations https://review.openstack.org/#/c/529515/
08:38:41 <oanson> I want to add to it a small change - creating a common fullstack file too, so the difference between redis and etcd will only be the db services
08:39:00 <dimak> +1
08:39:05 <dimak> I had some comment as well
08:39:13 <dimak> adding -fullstack suffix to those files
08:39:14 <oanson> I hope I'll get to it... tomorrow.
08:39:25 <oanson> dimak, sure. Add it to the review (so I won't forget) and I'll do that too
08:39:41 <dimak> It's there
08:40:20 <oanson> Cool
08:40:42 <oanson> My understanding is that tempest now only fails on BGP
08:40:51 <oanson> I can't check that now since zuul is completely shot
08:41:10 <oanson> But if that's the case, I'll work with the neutron-dynamic-routing guys to see what we can do
08:41:23 <oanson> I understand it's mostly strange docker disappearing acts.
08:41:37 <oanson> Anything else for gates?
08:42:24 <oanson> Troubleshooting - anything for this?
08:42:49 <oanson> #topic bugs
08:43:30 <oanson> I'm still hacking at bug 1720734
08:43:31 <openstack> bug 1720734 in DragonFlow "Floating IP association to LBaaS VIP supported by Octavia does not work" [Critical,In progress] https://launchpad.net/bugs/1720734 - Assigned to Omer Anson (omer-anson)
08:43:45 <oanson> I have high hopes with https://review.openstack.org/#/c/529692/
08:44:09 <dimak> Will review
08:44:30 <oanson> I still have to test it with kuryr-kubernetes. But as I said, I have high hopes ;)
08:44:35 <irenab> oanson, we can verify in my env
08:44:43 <oanson> irenab, sure. Let's do that.
08:44:48 <oanson> Any other bugs to discuss?
08:46:31 <oanson> #topic Open Discussion
08:46:36 <oanson> Hey! We made it!
08:46:38 <oanson> Anything here?
08:47:00 <oanson> lihi, dimak, I recall you mentioned you have something?
08:47:51 <dimak> We're working on the application decoupling spec/code
08:47:55 <dimak> its out there
08:48:06 <dimak> kind-of starting to work
08:48:26 <dimak> https://review.openstack.org/#/q/status:open+project:openstack/dragonflow+branch:master+topic:bug/1738986
08:48:58 <oanson> Cool!
08:49:01 <leyal> dimak , lihi - it's really cool :)
08:49:31 <irenab> I had a question on the spec regarding the impact on the users (devs, operators)
08:49:59 <dimak> Looking
08:50:41 <dimak> Missed your review, will answer on gerrit
08:50:58 <dimak> But I don't think there should be much impact there
08:51:04 <irenab> please address in the spec, I am concerned if it may complicate day to day for the operators
08:51:21 <dimak> We'll still be shipping the datapath "assembled and ready for use"
08:51:34 <irenab> troubleshooting, debugging
08:51:41 <dimak> Will do
08:51:57 <irenab> thanks
08:52:12 <oanson> Anything else for this?
08:52:26 <leyal> yep -  I Uploaded a patch for POC for kubernetes support - it's still not working . but if anyone interested the patch is here https://review.openstack.org/#/c/529971/ . as we don't using neutron it's can give us good view of what neutron done for us -for DF-api
08:53:10 <oanson> leyal, could you also add a tutorial on how to setup a deployment like this (i.e. k8s without openstack)?
08:53:47 <oanson> It might be interesting in case we want to play around and get a better feel for what's missing
08:54:06 <irenab> oanson, better have something like DF without openstack
08:54:25 <oanson> irenab, I meant with DF :)
08:54:57 <leyal> oanson , I will do when it's work , it's also just POC we still have some missing parts in DF
08:55:42 <oanson> leyal, up to you. But it will help us to understand what's going on, and help if we can
08:56:30 <leyal> sure , thanks :)
08:56:48 <oanson> Anything else on this?
08:57:49 <oanson> Anything else for open discussion? We have two minutes left :)
08:58:46 <oanson> Well, thanks everyone for coming!
08:59:13 <oanson> #endmeeting