I can clarify Eli’s question further. 1) is this by designed that we don't allow magnum-api to access DB directly ？ Yes, that is what it is. Actually, The magnum-api was allowed to access DB directly in before. After the indirection API patch landed [1], magnum-api starts using magnum-conductor as a proxy to access DB. According to the inputs from oslo team, this design allows operators to take down either magnum-api or magnum-conductor to upgrade. This is not the same as nova-api, because nova-api, nova-scheduler, and nova-conductor are assumed to be shutdown all together as an atomic unit.
I think we should make our own decision here. If we can pair magnum-api with magnum-conductor as a unit, we can remove the indirection API and allow both binaries to access DB. This could mitigate the potential performance bottleneck of message queue. On the other hand, if we stay with the current design, we would allow magnum-api and magnum-conductor to scale independently. Thoughts? [1] https://review.openstack.org/#/c/184791/ Best regards, Hongbin From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com] Sent: February-03-16 10:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] API service won't work if conductor down? Corey the one you are talking about has changed to coe-service-*. Eli, IMO we should display proper error message. M-api service should only have read permission. Regards, Madhuri From: Corey O'Brien [mailto:coreypobr...@gmail.com] Sent: Wednesday, February 3, 2016 6:50 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Magnum] API service won't work if conductor down? The service-* commands aren't related to the magnum services (e.g. magnum-conductor). The service-* commands are for services on the bay that the user creates and deletes. Corey On Wed, Feb 3, 2016 at 2:25 AM Eli Qiao <liyong.q...@intel.com<mailto:liyong.q...@intel.com>> wrote: hi Whey I try to run magnum service-list to list all services (seems now we only have m-cond service), it m-cond is down(which means no conductor at all), API won't response and will return a timeout error. taget@taget-ThinkStation-P300:~/devstack$ magnum service-list ERROR: Timed out waiting for a reply to message ID fd1e9529f60f42bf8db903bbf75bbade (HTTP 500) And I debug more and compared with nova service-list, nova will give response and will tell the conductor is down. and deeper I get this in magnum-api boot up: # Enable object backporting via the conductor base.MagnumObject.indirection_api = base.MagnumObjectIndirectionAPI() so in magnum_service api code return objects.MagnumService.list(context, limit, marker, sort_key, sort_dir) will require to use magnum-conductor to access DB, but no magnum-conductor at all, then we get a 500 error. (nova-api doesn't specify indirection_api so nova-api can access DB) My question is: 1) is this by designed that we don't allow magnum-api to access DB directly ？ 2) if 1) is by designed, then `magnum service-list` won't work, and the error message should be improved such as "magnum service is down , please check magnum conductor is alive" What do you think? P.S. I tested comment this line: # base.MagnumObject.indirection_api = base.MagnumObjectIndirectionAPI() magnum-api will response but failed to create bay(), which means api service have read access but can not write it at all since(all db write happened in conductor layer). -- Best Regards, Eli(Li Yong)Qiao Intel OTC China __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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
