Comment 1 for bug 1708178

<irenab> oanson, hi
<oanson> irenab, hi
<irenab> oanson, tired of PTO?
<oanson> I can do both. Cooperative threading! :)
<irenab> oanson, once you have few mins, would like to chat about integration with 3rd party LBaaS providers
<irenab> seems to be broken/not supported now when L3agent is disabled
<oanson> Sure. We can do that now
<irenab> dimak, do you have few mins ^^
<irenab> https://bugs.launchpad.net/dragonflow/+bug/1708178
<openstack> Launchpad bug 1708178 in DragonFlow "LBaaSv2 with 3rd party provider does not work if L3agent is disabled" [Undecided,New]
<dimak> irenab, yes
<oanson> Yes
<irenab> first, please set the priority for this bug
<dimak> I think we'll need to come up with an lb app that forwards packets bound to VIP port into the relevant compute/namespace
<oanson> The truth is I didn't know we support this feature :)
<oanson> irenab, what priority would you like? High?
<irenab> oanson, it worked before (with l3), this is how kuryr implements k8s services
<irenab> oanson, for kuryr integration its critical
<oanson> l3 agent is still supported. So that can be a workaround until this bug is fixed
<oanson> It can also be gated in the Kuryr-Dragonflow integration gate (which we can add to Dragonflow gate), so it will even be gated
<dimak> dnat acts funny with l3
<irenab> I think now with l3 agent we have some conflicts with DNAT, dimak has much more details
<dimak> because both will plug into br-ex and answer arps
<oanson> I'm not sure I want to say we don't support l3 agent.
<oanson> Is there a way we can get to play nice?
<oanson> Unless we do better on all fronts. Then we can do away with it completely.
<oanson> (And then we might do well to remove it from our code base)
<irenab> oanson, I agree with your approach
<oanson> Do we know if we are feature-compatible?
<irenab> lets keep L3agent enabled deployment possible, since it seems to be enabler for 3rd party services integ for now
<irenab> oanson, if DF supports all l3 extensions, I beleive the answer is yes
<dimak> I'll see if l3+ no dnat app works finne
<dimak> fine*
<irenab> is it possible to disable DNAT on l3agent?
<oanson> Is it possible to support l3 extensions in general, or do we have to support one by one? e.g. a single l3 extensions app, or do we need an app for lbaas, and one for e.g. vpn, etc?
<oanson> (I don't remember the API. Someone will have to look it up if we don't know)
<irenab> lbaas, vpnaas, fwaas are not l3 extensiosn
<irenab> each service is a separate extension set, and may have even separate api server (lbaas) is now octavia and not neutron
<oanson> Then l3 extensions is not enough.
<irenab> but they have proper integration into neutron by creating nets, ports, ets
<irenab> etc
<oanson> Sounds like we need to keep l3 agent support, since new extensions may be written to first support it, and if Dragonflow supports it we get it for free
<irenab> oanson, I will try to summarize
<irenab> 1. Keep L3agent support in DF (+fixing the issues to make it work again)
<irenab> 2. Advanced net services, lbaas (and maybe vpn) made working in l3agent enabled deployment
<irenab> 3. Provide DF native advanced services support
<irenab> correct?
<oanson> This is a task-list, or a multiple choice?
<oanson> I guess we want 1 and 3, and let the deployer select what they need.
<irenab> more of ma task list, or plan
<oanson> I figured 2 is a subset of these
<irenab> for 2, we need to make sure it works
<oanson> We prefer DF native services when possible - then we are fully distributed and can reach the scale we want. But realistically, we aren't enough people to keep up with OpenStack.
<irenab> and be able to integrate with 3rd party services proveders is good
<oanson> So yes, I guess we need all the above, and I guess in order, since it will take a while before we will be first-to-market on someone else's advanced network service.
<oanson> Yes, that's also true.
<oanson> So I guess we're in agreement.
<dimak> Well
<oanson> Item 1 and 2 are critical, sadly.
<dimak> Once we'll have DF l3 flavor we'll be able to use both df l3 and l3 agent
<dimak> by flavor I mean neutron side service provider
<oanson> Yes, but that might take time.
<oanson> I don't want it to block kuryr integration if there's a choice
<dimak> Yes
<dimak> maybe we can split our gate jobs
<dimak> to test both l3 app and l3 agent
<oanson> We will have to - this needs to be gated.
<irenab> agree
<oanson> But maybe we can gate the l3 agent with kuryr integration
* openstackgerrit has quit (Remote host closed the connection)
<irenab> in kuryr or df ?
<oanson> This way we also have a real-live scenario of where this is used.
<oanson> irenab, in df.
<irenab> for now we only have deployment gate in kuryr, so this can be great
<oanson> We want to find bugs in Dragonflow and prevent them.
<irenab> oanson, +1
<oanson> If kuryr runs a kuryr-df integration gate to verify kuryr doesn't break Dragonflow, I'm all for it. But I don't expect a different project to gate for our bugs
<irenab> oanson, I am alligned with you
<oanson> irenab, is the integration far enough along to create a non-voting gate? Even if it fails a lot?
<irenab> oanson, speaking of kuryr I am not sure, sicne there is a lot of work dmellado is doing
<irenab> for the testing at the gate
<irenab> on DF side, we will need deployment to include kuryr instead or in addition to nova
<oanson> Like we have for bgp and sfc?
<irenab> probably
<oanson> Doesn't sound like an issue.
<irenab> kury is sort of replacement to novawith regards to container
<irenab> oanson, dimak : cool. Sounds like there is a plan
<oanson> Yes.
<oanson> dimak, irenab, if you need an extra pair of hands, enlist leyal. I think he is working on bugs now, and we said these are critical.
<dimak> sure
<irenab> oanson, thanks
<oanson> Setting the bug to critical, and adding this log.
<dimak> I'll try to stabilize l3 app + no agent + l3 agent + no dnat