Hi Prasanna, I liked the idea of notifying the applications once the node is reconciled and ready for further configuration. I have few questions about the proposed framework in the context of single node + current master-slave implementation:
(1) I think following is not the case, for sure not for FRM, and i believe for FRM-Sync as well Slide-4: *"If Reconciliation fails the ODL disconnects the switch, and the whole process is repeated by Re-sync and application* *Applications start acting on OF switch which is in “unknown” state, which should be avoided."* (2) Slide-8: *"Application(s) registering with Reconciliation module is encouraged since:* *Applications would know the right Flows and group which needs to be replayed with write operation(Add / delete / update).* *FRM / FRS would not have application view of flows / group, it would blindly replay the flows / groups.* *Also flows having idle / hard timeout can be gracefully handled by application rather than FRM / FRS."* Are we assuming the application won't maintain the correct configuration in the data store ? I believe meter and group always need to be programmed before flow, so is there any other variance of ordering where we want application to do the reconciliation ? If the flows are installed with idle/hard timeout, we should expect application to remove it from data store. Unfortunately data store can't help much here, so application will have to take this burden. So we really keep the clear contract with respect to data store, i don't really see any reason, why we should leave the node reconciliation to application. Plugin should do the reconciliation based on the config state in the data store and once it's done with that reconciliation, it can notify application to reconcile it's business logic. Also in case of controller restart, the only state application will have is in config data store, and until and unless they run their business logic they can't figure out the correct ordering. And they can't run the business logic because there is no node advertized to them yet. (3) If we leave the reconciliation to the applications, and assume that two applications are using the same node, do we expect that both the application will have to use the similar kind of reconciliation mechanism? Assuming one wants to use bundle or one want to use the vanilla reconciliation mechanism that we have? If not, who will win? If yes, how we will implement it at the plugin level, because bundle's like features are provided at the plugin level. So basically i don't see how you can implement different reconciliation methods without depending on the plugin. I can see that you can use one method for reconciling specific node, but then all the application using that node need to use the same method. By doing that we are basically pushing switch specific reconciliation to the application level, and in my opinion that's not a good idea. (4) slide-9 "Check if Reconciliation is needed, if yes, update the DS status of the Switch and go to Step 6" Given that switch is not yet in data store, what really we want to update in the data store? Also i didn't find the step 6 in the slides. (5) slide-10 "9.*Application(s) would also wait for error from switch, for pre-defined time." * Why do we need to wait for pre-define time?, given that the current API-s do return the future and future will fail if the configuration on switch fails. (6) slide -10 *"10.Application(s) would inform the Reconciliation status to Reconciliation module."* How long does plugin wait on the application to notify? (7) Proposal says that if any of the application is not able to reconcile successfully, it should disconnect the device. Assume out of 2 application, one application is able to reconcile and other one failed, how do disconnecting the switch will help here ? is there any scenario where we expect different outcome once switch re-connect? (8) If we push the node reconciliation to applications, are we assuming that they will use the RPC for flow installation during the reconciliation ? Thanks Anil On Wed, Feb 22, 2017 at 9:34 AM, Abhijit Kumbhare <[email protected]> wrote: > Just to clarify - this reconciliation workflow as well as bundles based > reconciliation being discussed is for the next release (Nitrogen) and not > part of Carbon. The basic bundles support can be code reviewed & merged as > it is a stretch goal item in the Carbon release plan - however it will not > be used by reconciliation or any other application in Carbon. > > On Wed, Feb 22, 2017 at 4:35 AM, Prasanna Huddar < > [email protected]> wrote: > >> Hello All, >> >> >> >> Please review the proposed new Reconciliation workflow and provide >> your inputs. >> >> >> >> Link to the document(1st draft): https://wiki.opendaylight.org/ >> view/OpenDaylight_OpenFlow_Plugin:Reconciliation#Future_Enhancements >> >> >> >> Thanks, >> >> Prasanna >> >> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> >> > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
