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