Open Stack

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160203/7c46dc7a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liyong_qiao.vcf
Type: text/x-vcard
Size: 123 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160203/7c46dc7a/attachment.vcf>