Sunday, 2017-08-13

*** yamamoto has quit IRC00:52
*** yamamoto has joined #openstack-dragonflow01:47
*** yamamoto has quit IRC02:11
*** yamamoto has joined #openstack-dragonflow02:15
*** yamamoto has quit IRC02:19
*** yamamoto has joined #openstack-dragonflow02:24
*** yamamoto has quit IRC02:28
*** yamamoto has joined #openstack-dragonflow03:29
*** yamamoto has quit IRC03:35
*** yamamoto has joined #openstack-dragonflow05:09
*** yamamoto has quit IRC05:10
*** yamamoto has joined #openstack-dragonflow05:13
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: Remove leftovers of port status notifier  https://review.openstack.org/49202807:31
*** NatanBro has joined #openstack-dragonflow07:32
*** yamamoto has quit IRC08:20
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: Fix update FIP status  https://review.openstack.org/49204008:20
*** yamamoto has joined #openstack-dragonflow08:30
openstackgerritMerged openstack/dragonflow master: Switch from oslosphinx to openstackdocstheme  https://review.openstack.org/48781008:43
*** yamamoto has quit IRC09:13
openstackgerritMerged openstack/dragonflow master: Add 'rm -f .testrepository/times.dbm' command in testenv  https://review.openstack.org/48779909:35
*** yamamoto has joined #openstack-dragonflow10:14
*** yamamoto has quit IRC10:20
*** yamamoto has joined #openstack-dragonflow10:42
*** NatanBro has quit IRC11:20
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: [05/xx] Change DNAT to rely on Provider app for bridge access  https://review.openstack.org/47536211:42
*** yamamoto has quit IRC12:00
oansondimak, ping12:58
dimakhey12:58
oansonRegarding https://review.openstack.org/#/c/489994/12:58
dimakYes12:59
oansonI think we discussed the 'common' dispatcher code (as used also in bgp service) is to be moved out of df_local_controller, right?12:59
dimakWe did13:00
*** yamamoto has joined #openstack-dragonflow13:00
dimakoanson, you suggest it is related to the above patcH?13:01
oansonYEs13:04
oansonYes*13:04
oansonAs I said, I don't like it that we have 2 different dispatch methods in df controller13:04
dimakWhat 2?13:05
oanson1. Using model events. 2. <action>_<table_name>13:05
oansonThough I'm not sure how to do it differently - the second method promises that code will run *before* application code13:06
oansonIsn't that code a bit overlapping the port locator object logic?13:07
dimakPort locator is just a lookup13:07
dimakcontroller handles port state13:07
oansonWhy not use it to decide which event to fire? The state here is just is_local or is_remove. That exists in port_locator as well13:08
*** yamamoto has quit IRC13:08
oansonI'm just trying to think of an elegant way to do this. If we can remove this code from df controller entirely and put it somewhere else, that would be great13:08
dimakNot sure I understood your idea, what do you want to use to figure out what event should be fired13:10
oansonport_locator already has an is_local and is_remote function. We don't really need _local_ports and _remote_ports in df controller.13:11
oansonThen update_lport (I know you want it removed) or an event handler on df controller just reads the info from there.13:11
dimakI don't want update_lport, it's too early of an entrypoint13:12
dimakI think I can remote _local/remote_ports in the patch that adds port_locator13:13
dimakthough wait, I'm not sure13:13
oansonIt is getting a bit intricate. I am not sure I understand the flow too well13:14
oansonFor instance, how does migration fit in all this? Or do you want to solve migration later?13:14
dimakFirst of all, yes13:14
dimakand my plan is, the app updates the correct binding in port locator, then emits the bind/unbind event13:15
oansonWithout migration, it should be easy enough. You can use port_locator to know what kind of event you need.13:15
dimakthis way binding is stick and the update will not wipe it13:15
dimakthen once update arrives, migration app will clear the binding13:16
oansonThat makes sense - have migration just change the binding without touching the object13:16
dimakYes13:16
oansonMaybe we need to extend migration - make it a full fledged 'port location handling app'.13:16
oansonBut then you have a mandatory app.13:17
dimakI prefer to start with something rather simple13:17
dimakIf its mandatory, why is it an app13:17
oansonBecause it is not the controller's responsibility.13:18
oansonI don't think mandatory apps are a problem. They exist everywhere else.13:18
oanson(All operating systems, agents in Neutron implementations, etc.)13:18
oansonWell, almost all OSes. Maybe not DOS :)13:19
oansonAnd it's only mandatory if you care about port binding. So maybe e.g. L2, L3 don't actually care about it, as long as it's bound.13:20
dimakI can move controller an app, I'll still need port locator lookup13:20
oansonThat's all right13:21
oansonThe app looks up the info in the locator, and then fires the relevant event13:21
dimakAnd I'm still not sold on why its an app13:21
oansonYou agree it shouldn't be in the controller?13:21
dimakKind-ish?13:22
dimakIt depends on what we want to keep in there13:22
oansonIn previous discussions we wanted minimal model-related logic13:22
oansonExcept maybe core models13:22
oansondimak, ?13:25
dimakoanson, yes, sorry13:33
oansonNo worries13:34
dimakWe can move the callbacks elsewhere, it still doesn't mean it has to be an app13:34
oansonSo where will you put them?13:34
dimakdragonflow.controller.not_an_app? :)13:35
dimakThey can be in port_locator13:35
dimakthough not really related13:35
oansonSure. What makes it a non-app?13:35
dimakits a few methods that translate one kind of event into another13:36
oansonI have put it on the model13:36
dimakIt's semantics13:36
oansonNot sure it's the best idea.13:36
oansonSo is the whole software-engineering thing13:36
dimakI don't think it belongs on the model13:36
dimakits strictly controller code13:36
oansonI don't think we have a consensus here :(13:38
oansonLet's do it like this: Keep patch 1 as is. In patch 2, where you introduce port_locator, remove the bound/unbound events in df local controller13:39
oansonWe'll discuss what to do with the base events later.13:40
oansonI am not convinced about removing update_lport, but we can revisit that later13:40
dimakSure, I'll get to it tomorrow, I'm fiddling with DNAT for a bit13:41
dimakWhy do you want to keep update_lport"13:41
dimak?13:41
oansonIt feels a bit strange to fire an event, only to catch it again.13:41
oansonAnd I don't like having to dispatch methods in the same class. It feels overly complex13:42
dimakWhy? maybe some apps will want to listen to update events regardless of locality13:43
oansonEspecially since df controller doesn't need to catch events from applications now that we reuse port_locator13:43
oansonProbably.13:43
dimakafter all, lport implements basic events13:43
oansonSo update_lport can fire the original event as well13:43
oansonI think l2, l3 is a use case for what you're saying13:43
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: [06/xx] Change DNAT to rely on Provider app for bridge access  https://review.openstack.org/47536215:09
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: [WIP][05/xx] Move FIP status updates to L3 plugin  https://review.openstack.org/49335915:09
openstackgerritMerged openstack/dragonflow master: Restore QoS fullstack tests  https://review.openstack.org/49241317:35
openstackgerritMerged openstack/dragonflow master: Don't send a value in delete pubsub event  https://review.openstack.org/49177817:37
openstackgerritMerged openstack/dragonflow master: Remove leftovers of port status notifier  https://review.openstack.org/49202817:37
openstackgerritDima Kuznetsov proposed openstack/dragonflow master: [WIP][05/xx] Move FIP status updates to L3 plugin  https://review.openstack.org/49335918:29
openstackgerritMerged openstack/dragonflow master: BGP service: Register only relevant models  https://review.openstack.org/49221520:58
*** yamamoto has joined #openstack-dragonflow21:09
*** yamamoto has quit IRC21:20
*** yamamoto has joined #openstack-dragonflow21:56
*** yamamoto has quit IRC21:57
*** yamamoto has joined #openstack-dragonflow21:58

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!