09:00:33 <oanson> #startmeeting Dragonflow
09:00:34 <openstack> Meeting started Mon Jul 10 09:00:33 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:37 <openstack> The meeting name has been set to 'dragonflow'
09:00:42 <dimak> Hey
09:00:47 <leyal> Hi
09:00:48 <lihi> Hi
09:00:54 <oanson> Hello. Who is here for the Dragonflow weekly?
09:01:09 <oanson> Let's wait another minute, and then we'll start.
09:01:17 * yamamoto peeping
09:01:41 <oanson> All right. Let's start.
09:01:49 <oanson> #info dimak leyal lihi in meeting
09:01:55 <oanson> #info yamamoto peeping :)
09:02:09 <oanson> First, some announcements:
09:02:27 <oanson> I changed the teimslot for the Dragonflow weekly.
09:02:39 <itamaro> ין
09:02:41 <oanson> #link Meeting time change https://review.openstack.org/#/c/482034/
09:02:48 <oanson> #info itamaro also in meeting
09:02:53 <itamaro> hi
09:03:13 <dimak> It was already merged?
09:03:16 <oanson> Yes
09:03:18 <dimak> No time to appeal :P
09:03:20 <dimak> ?
09:03:20 <irenab> hi
09:03:31 <oanson> This means that next week we start an hour earlier, and the week after we meet at 1900 UTC
09:03:56 <oanson> dimak, the time was voted on last week and was accepted, but we can always submit a second patch
09:04:02 <oanson> Thierry just didn't waste any time :)
09:04:09 <oanson> #info irenab also in meeting
09:04:12 <oanson> (Hi)
09:04:53 <oanson> It is also possible I got it wrong, and next week we start in the evening, and the week after we move an hour earlier :)
09:05:21 <oanson> I guess the wiki will be updated soon, and I'll verify
09:05:21 <irenab> oanson, maybe worth to add on the DF wiki the date and time for few following weeks
09:05:39 <oanson> Sure
09:05:49 <oanson> I'll also send an email to the mailing list
09:06:49 <oanson> Anything else for announcements?
09:07:10 <oanson> #topic Roadmap
09:07:56 <oanson> So, SFC
09:08:00 <oanson> dimak, any comments?
09:08:23 <dimak> I'll upload a newer version soon with more tests, there are some python3 issues I found
09:08:34 <dimak> but I its nothing major
09:08:54 <oanson> All right. ping lihi and me once you do, and we'll push it in. I think it's in a fairly advanced state
09:09:28 <oanson> LBaaS - sadly no progress :(
09:09:36 <dimak> oanson, alright, will do
09:09:41 <oanson> Thanks.
09:09:42 <oanson> L3 flavour - dimak, you're up again.
09:09:55 <dimak> I didn't get to revise the spec yet
09:10:08 <oanson> Sure
09:10:16 <oanson> etcd publisher - lihi?
09:10:59 <lihi> I have some issues with python-etcd. I'm missing some an important feature from etcd's regular API
09:11:23 <lihi> I'm testing if we can use pyton-etcd3 instead
09:11:42 <oanson> requirements project has an etcd3 package already in - is this what you're testing?
09:12:33 <lihi> No, I want to replace our driver to use etcd3 package instead of etcd
09:12:41 <oanson> #link etcd3 https://python-etcd3.readthedocs.io/en/latest/
09:13:03 <oanson> The question is - are you using something already in requirements (like the link I just posted)
09:14:15 <lihi> I'm sorry I don't understand your question
09:14:45 <oanson> The requirements project unifies all the python requirements used in openstack. They do that for  licensing issues and to make sure no stale packages are used
09:15:06 <oanson> #link Requirements Project https://github.com/openstack/requirements
09:15:12 <lihi> I'm trying to get our DB driver to work with the package, and then build our subscriber on top of it
09:15:38 <oanson> I see. And you are using the etcd3 python library, from here: https://python-etcd3.readthedocs.io/en/latest/ ?
09:15:40 <lihi> Oh
09:15:47 <lihi> Yes this is the one
09:16:05 <oanson> All right. Just wanted to make sure :)
09:16:45 <oanson> Do you have an ETA?
09:18:27 <oanson> lihi, ?
09:18:30 <lihi> Aiming for this week (even though this is was I say last week :|)
09:18:44 <oanson> It's all right. It's not a hard limit :)
09:19:13 <oanson> RPM packaging - I started looking into this. I hope to have a patch up by end of week
09:19:42 <dimak> Cool
09:19:47 <oanson> Skydive has no carrier - so I'll skip it unless someone volunteers?
09:19:55 <oanson> And Ironic support - leyal ?
09:20:09 <dimak> oanson, I want to get to it eventually
09:20:26 <irenab> oanson, can you please post the link to the roadmap items list?
09:20:27 <leyal> I started to read about
09:20:34 <oanson> dimak, doesn't look like anyone is rushing to it, so... :)
09:20:37 <leyal> Ironic
09:20:47 <oanson> irenab, agenda is here: https://wiki.openstack.org/wiki/Meetings/Dragonflow
09:20:49 <oanson> #link Agenda https://wiki.openstack.org/wiki/Meetings/Dragonflow
09:20:51 <irenab> thanks
09:20:59 <oanson> leyal, yes
09:21:03 <leyal> It's looks that it's HAd 2 modes : 1. flat-networks
09:21:49 <leyal> 2. sperated the tenant networks from the provisioning networks
09:22:34 <oanson> What do you mean by 2.?
09:22:41 <oanson> And what about virtual services, e.g. dhcp, metadata, NATs? Do they mention that?
09:23:54 <leyal> It's the second mode - use one network for provision (boot - DHCP - TFTP etc .. )
09:24:07 <irenab> leyal, maybe it will be helpful if you can provide some draft for the Ironic support
09:24:22 <leyal> And other network for regular usage after  vm boot from disk ..
09:25:13 <leyal> i didn't saw that they mention anything about virtual-services..
09:25:21 <oanson> I see
09:25:24 <oanson> I think irenab has the right idea. Writing up a draft would be all right?
09:25:44 <kkxue> +1
09:26:12 <oanson> leyal, ?
09:26:34 <leyal> writing draft about what?
09:26:45 <oanson> About ironic, and its integration with Dragonflow
09:27:00 <oanson> It doesn't have to be a spec. A whitepaper or blog post can also do
09:27:29 <leyal> +1 , but i think that i need to get better understanding of Ironic before that ...
09:27:46 <oanson> Of course.
09:28:13 <oanson> The idea is to synthesize the information that is relevant for the cross-project synergy, and put it somewhere where it's accessible
09:29:33 <oanson> Anything else for roadmap?
09:30:00 <leyal> sure , will do when i will be prepared ..
09:30:20 <irenab> oanson, the spec itamaro posted
09:30:56 <oanson> 1 sec. Let me find it
09:31:08 <oanson> You mean this one? https://review.openstack.org/#/c/481887/
09:31:35 <dimak> Posted some comments ther
09:31:36 <dimak> e
09:32:28 <oanson> dimak, I see your main concern is snat
09:32:46 <itamaro> yes. In my opinion it is best to have a patch identified by the connecting briges for simplicity.
09:32:48 <dimak> snat and provider are the primary users of patches
09:33:15 <itamaro> snat issues can be managed by providing higher priority
09:33:28 <dimak> Then we have coupling
09:33:42 <itamaro> eg SNAT_CLASS_PRIO = 300
09:33:58 <oanson> In general the snat API is lacking. It is configuration based, not in line with Neutron networks, and doesn't have a logical port on which other applications can operate if needed
09:34:22 <oanson> (which in theory breaks the API and General Order of Things we are constructing)
09:34:49 <oanson> Like dnat relies on provider networks, maybe make snat do the same
09:35:12 <oanson> Give snat a port (e.g. like a fip, but for snat not dnat), and let it do its thing from there
09:35:21 <itamaro> I think that ant connectivity with the physical underlay must go through  provider networks
09:35:26 <dimak> Who will allocate those ports?
09:35:58 <oanson> provider networks - they will be responsible for the mapping of network to bridge. Any other apps just sends packets to networks
09:36:11 <oanson> In case of snat and dnat, also natting the packets in the process.
09:36:12 <itamaro> yes
09:36:52 <oanson> And then only provider networks need to handle patch ports. In general, we only need a library for software engineering reasons. provider app should be the only user
09:36:58 <dimak> oanson, my question still stands
09:37:45 <oanson> Let me think a second
09:37:51 <oanson> (Or someone else suggest something (: )
09:38:14 <dimak> Some one needs to allocate ports for 'snat' ports and delete them when hosts die
09:38:18 <oanson> As step 1 - we can do the quick and dirty fix of giving snat higher priority. As step 2 - we give snat a specialised fip or fip network
09:38:18 <irenab> I need to catch up on the spec. Can we have a discussion later
09:38:25 <dimak> Or don't have any ports on chassis
09:38:54 <dimak> I think its more relevant to snat rather than patch ports
09:39:01 <itamaro> if I understand your concern. it is that snap flows may no be considered because of higher prio match.
09:39:18 <oanson> irenab, it's not a long spec. Basically it says, let's have an external library for patch ports. Have a single patch-port-pair between br-int and any external bridge. And let provider networks app manage the patch ports. itamaro, dimak, did I miss anything?
09:39:30 <dimak> Yes
09:39:42 <itamaro> correct
09:39:56 <dimak> I'm just not sure what problem we try to solve if snat works differently
09:40:00 <irenab> oanson, this sounds reasonable approach
09:41:09 <oanson> dimak, one example is an API. If the api is configuration file, you need to restart the controller to change configuration.
09:41:52 <oanson> Secondly, we *have* issues of multiple patch ports and multiple apps trying to reach networks (the dnat problem). I'm hoping this will solve that as well
09:41:55 <itamaro> snat can be solved by having it's own priorities in the global constants  prefixed with SNAT_PRIO, and keep them higher than the higest prio
09:41:57 <dimak> Ok, but bridge mapping to physical network is configuration anyway
09:42:44 <oanson> Yes
09:42:52 <oanson> But snat -> physical network doesn't have to be
09:43:02 <dimak> itamaro, I don't like this solution, because it creates overlap in table=0 for both apps, I'd very much like to avoid that
09:43:06 <itamaro> it's logical mapping. we shall map the mapped (physical: flat/valn) networks names to the patch port
09:43:23 <oanson> The rationale is that if you change the network <-> bridge mapping, there's a hardware change involved. Otherwise, everything is software defined.
09:43:59 <oanson> dimak, in the second phase, only provider app will have a mapping in table=0. snat (like dnat) will take the packet from provider.
09:44:07 <oanson> itamaro, please confirm
09:44:21 <dimak> oanson, what if I want to NAT to another network?
09:44:22 <itamaro> yes, that should be the plan.
09:44:39 <dimak> Current implementation does not restrict you to neutron networks
09:44:45 <oanson> dimak, then the snat app should be extended. If snat is already network based, it should be easy.
09:44:55 <oanson> dimak, that's not a good thing
09:44:57 <itamaro> you will have a mapping  like <name>:bridge
09:45:05 <oanson> (I think it isn't, at least)
09:45:07 <itamaro> name is network name
09:45:10 <dimak> oanson, I can argue otherwise
09:45:33 <dimak> Its an extra flexibility we allow at the moment
09:45:58 <oanson> Yes, extra flexibility means more complex api.
09:46:09 <itamaro> the bridge must be handelded by the providers networks app, which prodes the access to the physical infra
09:46:17 <oanson> Currently, there is no way to control it except going to the node, changing the configuration, and restarting the service
09:46:35 <dimak> At the moment its zero API, egress through the address your host got from the DHCP
09:46:50 <oanson> If you want an API, which can be validated and verified, you need to lay down some ground rules. This also helps the applications "play nice" with each other - there is a limit to what they are allowed to do
09:46:54 <irenab> I think we are mixing the api (usability) part with the implementation part
09:46:58 <dimak> But same for mapping, I see it on the same level
09:47:03 <oanson> yes, definitely
09:47:16 <irenab> maybe worth to keep discussion on implementation first?
09:47:35 <oanson> As I said, the mapping assumes a physical backend. That's why I want things to be network based, not bridge based.
09:48:01 <irenab> oanson, phy network?
09:48:06 <oanson> irenab, I thought that's what we're doing?
09:48:27 <irenab> oanson, just seemed to me 2 parallel discussions, sorry
09:48:32 <oanson> irenab, yes. But that still goes through mapping, which is handled by provider network and hidden for everything else
09:49:34 <oanson> I would be happiest with a solution that let's us phase into it, without breaking too much on the way, and allows us to get things working
09:49:47 <dimak> We can have a provider network based SNAT, and it won't need extra patches. But that's not what chassis SNAT does at the moment.
09:50:00 <itamaro> dimak is right that apps need to play nice with each other
09:50:04 <dimak> We can decide that we drop it but that's something else
09:50:13 <irenab> drop what?
09:50:29 <oanson> dimak, sure. That's a good way to do it
09:50:38 <dimak> chassis snat in favor of neutron managed snat
09:51:01 <dimak> manages as in IPAM and port creation and deletion
09:51:40 <oanson> Sure
09:52:13 <oanson> But if chassis snat works ad-hoc, it's going to be difficult to get it to play nice with other apps
09:52:17 <oanson> e.g. provider networks
09:52:18 <itamaro> i think a full snat solution should include a physical  network/interface mapping  and  even reachability checks,
09:52:26 <oanson> Unless you have another suggestion
09:52:55 <oanson> itamaro, yes to the second, not sure about the first. A more flexible approach will just let you nat between networks
09:52:56 <dimak> oanson, it is super simple, each gets its own patch port
09:53:09 <itamaro> we can use pkt marks
09:53:28 <oanson> Then you can have snat have a patch-port, ignoring that provider app already has one as well
09:53:40 <dimak> That way SNAT can communicate with provider ports as well
09:54:47 <oanson> Possibly, but probably not the only way.
09:54:48 <dimak> (No need for loopback if both apps classify on same patch port in table=0)
09:54:56 <itamaro> pkt-marks
09:55:13 <dimak> Should work both ways, external bridge will flood and learn
09:55:15 <oanson> itamaro, there is only so much you can cover with 'pkt-marks'. :)
09:55:21 <oanson> Please at least explain how to use them?
09:55:57 <itamaro> pkt marks can emulate patch port..
09:56:51 <oanson> that moves the logic to the external bridges.
09:57:00 <itamaro> one can tag snat traffic with it'a mark, so you match on it
09:57:10 <oanson> That might not be too good, since the external bridges might be regular bridges (i.e. not OVS/OpenFlow)
09:57:17 <oanson> normal bridges*
09:58:17 <dimak> I think we're almost out of time
09:58:20 <oanson> Yes
09:58:26 <oanson> I am not convinced either way.
09:59:08 <oanson> dimak, itamaro, please discuss offline and come up with a design everyone is happy, which will support better snat/dnat implementations in the future (as discussed here)
09:59:20 <oanson> And post for us a spec, if possible.
09:59:29 <oanson> That's all our time for today,
09:59:32 <dimak> +1
09:59:33 <oanson> Thanks everyone for coming.
09:59:53 <dimak> Bye
09:59:55 <oanson> #endmeeting