Hi Salvatore and Kevin, I'm sorry for replying so late. I wanted to see whether the community had considered data sync for these two style(agent and controller) integration. To solve integrating multiple vendor's controllers, I need some help from community. That's the original purpose of this thread. In another word, I had no idea when I sent this message and I just asked some help.
Anyway, the issues I mentioned last mail are exists. We still need face them. I have some rough ideas for your reference. 1.try best to keep the source is correct. Think about CREATE operation, if the backend was be in exception and Neutron is timeout, then the record should be destroyed or marked ERROR to warn the operator. If Neutron was be in exception, the backend will has an extra record. To avoid this, Neutron could store and mark a record CREATE_PENDING before push it to backend, then scan data and check with the backend after restarting when exception occurs. If the record in Neutron is extra, destroy or mark ERROR to warn the operator. UPDATE and DELETE need similar logic. Currently in Neutron, some objects have defined XX_PENDING and some not. 2.check each other when they restart. After restarting, the backend should report the states of all objects and may re-load data from Neutron to rebuild or check local data. When Neutron restarting, it should get data from backend and check it. Maybe, it can notify backend, and backend act as it just restarted. All in all, I think it's enough that keeping the data be correct when you write(CUD) it and check it when restarting. About implementation, I think a common frame is best. Plugins or even drivers just provide methods for backend to load data, update state and etc. As I mentioned earlier, this is just a rough and superficial idea. Any comment please. Thanks, Germy . On Tue, Oct 13, 2015 at 3:28 AM, Kevin Benton <blak...@gmail.com> wrote: > >*But there is no such a feature in Neutron. Right? Will the community > merge it soon? And can we consider it with agent-style mechanism together?* > > The agents have their own mechanisms for getting information from the > server. The community has no plans to merge a feature that is going to be > different for almost every vendor. > > We tried to come up with some common syncing stuff in the recent ML2 > meeting, the various backends had different methods of detecting when they > were out of sync with Neutron (e.g. headers in hashes, recording errors, > etc), all of which depended on the capabilities of the backend. Then the > sync method itself was different between backends (sending deltas, sending > entire state, sending a replay log, etc). > > About the only thing they have in common is that they need a way detect if > they are out of sync and they need a method to sync. So that's two abstract > methods, and we likely can't even agree on when they should be called. > > Echoing Salvatore's comments, what is it that you want to see? > > On Mon, Oct 12, 2015 at 12:29 AM, Germy Lure <germy.l...@gmail.com> wrote: > >> Hi Kevin, >> >> *Thank you for your response. Periodic data checking is a popular and >> effective method to sync info. But there is no such a feature in Neutron. >> Right? Will the community merge it soon? And can we consider it with >> agent-style mechanism together?* >> >> Vendor-specific extension or coding a periodic task private by vendor is >> not a good solution, I think. Because it means that Neutron-Sever could not >> integrate with multiple vendors' controller and even the controller of >> those vendors that introduced this extension or task could not integrate >> with a standard community Neutron-Server. >> That is just the tip of the iceberg. Many of the other problems >> resulting, such as fixing bugs,upgrade,patch and etc. >> But wait, is it a vendor-specific feature? Of course not. All software >> systems need data checking. >> >> Many thanks. >> Germy >> >> >> On Sun, Oct 11, 2015 at 4:28 PM, Kevin Benton <blak...@gmail.com> wrote: >> >>> You can have a periodic task that asks your backend if it needs sync >>> info. >>> Another option is to define a vendor-specific extension that makes it >>> easy to retrieve all info in one call via the HTTP API. >>> >>> On Sat, Oct 10, 2015 at 2:24 AM, Germy Lure <germy.l...@gmail.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> After restarting, Agents load data from Neutron via RPC. What about >>>> 3-rd controller? They only can re-gather data via NBI. Right? >>>> >>>> Is it possible to provide some mechanism for those controllers and >>>> agents to sync data? or something else I missed? >>>> >>>> Thanks >>>> Germy >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Kevin Benton >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev