Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro and Jay, I checked discussion below, and I do believe we also need service-list(for just magnum-api and magnum-conductor), but not so emergent requirement. I also think service-list should not bind to k8s or swarm etc. (can use coe-service etc.) But I have more for below: 1) For k8s or swarm or mesos, I think magnum can expose through the coe-service-list. But if right now, we fetched status from DB for pods/rcs status, It seems not proper to do that, as DB has old data. We need to fetch that through k8s/swarm API endpoints. 2) It can also expose that through k8s/swarm/mesos client tools. If users like that. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Jay Lau jay.lau@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/04/2015 05:51 AM Subject:Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of magnum system services, but it is nice to have. But I did see a strong reason to rename service-list to coe-service-list or others which might be more meaningful as I was often asked by someone why does magnum service-list is showing some services in kubernetes but not magnum system itself? This command always make people confused. Thanks! 2015-08-03 15:36 GMT-04:00 SURO suro.p...@gmail.com: Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' = Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' = Enlists available engines. 4. 'keystone service-list' = Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin From: SURO [mailto:suro.p...@gmail.com] Sent: July-29-15 4:03 PM To: Jay Lau Cc: s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Thanks Jay/Kennan/Adrian for chiming in! From this, I conclude that we have enough consensus to have 'magnum service-list' and 'magnum coe-service-list' segregated. I will capture extract of this discussion at the blueprint and start implementation of the same. Kennan, I would request you to submit a different bp/bug to address the staleness of the state of pod/rc. Regards, SURO irc//freenode: suro-patz On 8/3/15 5:33 PM, Kai Qiang Wu wrote: Hi Suro and Jay, I checked discussion below, and I do believe we also need service-list(for just magnum-api and magnum-conductor), but not so emergent requirement. I also think service-list should not bind to k8s or swarm etc. (can use coe-service etc.) But I have more for below: 1) For k8s or swarm or mesos, I think magnum can expose through the coe-service-list. But if right now, we fetched status from DB for pods/rcs status, It seems not proper to do that, as DB has old data. We need to fetch that through k8s/swarm API endpoints. 2) It can also expose that through k8s/swarm/mesos client tools. If users like that. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Inactive hide details for Jay Lau ---08/04/2015 05:51:33 AM---Hi Suro, Yes, I did not see a strong reason for adding service-lJay Lau ---08/04/2015 05:51:33 AM---Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of From: Jay Lau jay.lau@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/04/2015 05:51 AM Subject: Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of magnum system services, but it is nice to have. But I did see a strong reason to rename service-list to coe-service-list or others which might be more meaningful as I was often asked by someone why does magnum service-list is showing some services in kubernetes but not magnum system itself? This command always make people confused. Thanks! 2015-08-03 15:36 GMT-04:00 SURO _suro.patz@gmail.com_ mailto:suro.p...@gmail.com: Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' = Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' = Enlists available engines. 4. 'keystone service-list' = Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau _jay.lau.513@gmail.com_ mailto:jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO _suro.patz@gmail.com_ mailto:suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of magnum system services, but it is nice to have. But I did see a strong reason to rename service-list to coe-service-list or others which might be more meaningful as I was often asked by someone why does magnum service-list is showing some services in kubernetes but not magnum system itself? This command always make people confused. Thanks! 2015-08-03 15:36 GMT-04:00 SURO suro.p...@gmail.com: Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' = Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' = Enlists available engines. 4. 'keystone service-list' = Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin *From:* SURO [ suro.p...@gmail.commailto:suro.p...@gmail.com suro.p...@gmail.com] *Sent:* July-29-15 4:03 PM *To:* Jay Lau *Cc:* s...@yahoo-inc.coms...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Cool, Suro! It's great that we finally reach an agreement on this ;-) 2015-08-03 20:43 GMT-04:00 SURO suro.p...@gmail.com: Thanks Jay/Kennan/Adrian for chiming in! From this, I conclude that we have enough consensus to have 'magnum service-list' and 'magnum coe-service-list' segregated. I will capture extract of this discussion at the blueprint and start implementation of the same. Kennan, I would request you to submit a different bp/bug to address the staleness of the state of pod/rc. Regards, SURO irc//freenode: suro-patz On 8/3/15 5:33 PM, Kai Qiang Wu wrote: Hi Suro and Jay, I checked discussion below, and I do believe we also need service-list(for just magnum-api and magnum-conductor), but not so emergent requirement. I also think service-list should not bind to k8s or swarm etc. (can use coe-service etc.) But I have more for below: 1) For k8s or swarm or mesos, I think magnum can expose through the coe-service-list. But if right now, we fetched status from DB for pods/rcs status, It seems not proper to do that, as DB has old data. We need to fetch that through k8s/swarm API endpoints. 2) It can also expose that through k8s/swarm/mesos client tools. If users like that. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! [image: Inactive hide details for Jay Lau ---08/04/2015 05:51:33 AM---Hi Suro, Yes, I did not see a strong reason for adding service-l]Jay Lau ---08/04/2015 05:51:33 AM---Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of From: Jay Lau jay.lau@gmail.com jay.lau@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: 08/04/2015 05:51 AM Subject: Re: [openstack-dev] [magnum][blueprint] magnum-service-list -- Hi Suro, Yes, I did not see a strong reason for adding service-list to show all of magnum system services, but it is nice to have. But I did see a strong reason to rename service-list to coe-service-list or others which might be more meaningful as I was often asked by someone why does magnum service-list is showing some services in kubernetes but not magnum system itself? This command always make people confused. Thanks! 2015-08-03 15:36 GMT-04:00 SURO suro.p...@gmail.com*suro.p...@gmail.com suro.p...@gmail.com*: Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' = Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' = Enlists available engines. 4. 'keystone service-list' = Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau *jay.lau@gmail.com* jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO *suro.p...@gmail.com* suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Jay makes a good point here. The service-list output is specific to the “service” abstraction in the COE, not the system services that are part of magnum. The suggested rename from service-list to coe-service-list would make this distinction more clear. Adrian On Jul 30, 2015, at 2:40 AM, Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com wrote: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.commailto:suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin From: SURO [mailto:suro.p...@gmail.com] Sent: July-29-15 4:03 PM To: Jay Lau Cc: s...@yahoo-inc.commailto:s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO mailto:suro.p...@gmail.comsuro.p...@gmail.commailto:suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin *From:* SURO [mailto:suro.p...@gmail.com suro.p...@gmail.com] *Sent:* July-29-15 4:03 PM *To:* Jay Lau *Cc:* s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - - 'magnum service-list' should be similar to 'nova service-list' - 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - - 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. - If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. - nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Jay, Thanks for clarifying the requirements further. I do agree with the idea of having 'magnum service-list' and 'magnum coe-service-list' to distinguish that coe-service is a different concept. BUT, in openstack space, I do not see 'service-list' as a standardized function across other APIs - 1. 'nova service-list' = Enlists services like api, conductor etc. 2. neutron does not have this option. 3. 'heat service-list' = Enlists available engines. 4. 'keystone service-list' = Enlists services/APIs who consults keystone. Now in magnum, we may choose to model it after nova, but nova really has a bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not. For magnum, at this point creating 'service-list' only for api/conductor - do you see a strong need? Regards, SURO irc//freenode: suro-patz On 8/3/15 12:00 PM, Jay Lau wrote: Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau jay.lau@gmail.com mailto:jay.lau@gmail.com: Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.com mailto:suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin *From:*SURO [mailto:suro.p...@gmail.com] *Sent:* July-29-15 4:03 PM *To:* Jay Lau *Cc:* s...@yahoo-inc.com mailto:s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com mailto:suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] -https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro, In my understanding, even other CoE might have service/pod/rc concepts in future, we may still want to distinguish the magnum service-list with magnum coe-service-list. service-list is mainly for magnum native services, such as magnum-api, magnum-conductor etc. coe-service-list mainly for the services that running for the CoEs in magnum. Thoughts? Thanks. 2015-07-29 17:50 GMT-04:00 SURO suro.p...@gmail.com: Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin *From:* SURO [mailto:suro.p...@gmail.com suro.p...@gmail.com] *Sent:* July-29-15 4:03 PM *To:* Jay Lau *Cc:* s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.comsuro.p...@gmail.com : Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - - 'magnum service-list' should be similar to 'nova service-list' - 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - - 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. - If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. - nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com mailto:suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] -https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin From: SURO [mailto:suro.p...@gmail.com] Sent: July-29-15 4:03 PM To: Jay Lau Cc: s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.commailto:suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and driver implementation. I think it is too early to declare service/rc/pod as specific to k8s, as the other COEs may very well converge onto similar/same concepts. Regards, SURO irc//freenode: suro-patz On 7/29/15 2:21 PM, Hongbin Lu wrote: Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE, adding prefix to COE-specific command is unavoidable. Best regards, Hongbin *From:*SURO [mailto:suro.p...@gmail.com] *Sent:* July-29-15 4:03 PM *To:* Jay Lau *Cc:* s...@yahoo-inc.com; OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', the same applies for even creation and other actions. This will give rise to COE-specific command and concepts and which may proliferate further. Instead, we can abstract swarm's service concept under the umbrella of magnum's 'service' concept without creating k8s-service and swarm-service. I suggest we should keep the concept/abstraction at Magnum level, as it is. Regards, SURO irc//freenode: suro-patz On 7/28/15 7:59 PM, Jay Lau wrote: Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com mailto:suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] -https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro, Sorry for late. IMHO, even the magnum service-list is getting data from DB, but the DB is actually persisting some data for Kubernetes service, so my thinking is it possible to change magnum service-list to magnum k8s-service-list, same for pod and rc. I know this might bring some trouble for backward compatibility issue, not sure if it is good to do such modification at this time. Comments? Thanks 2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com: Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - - 'magnum service-list' should be similar to 'nova service-list' - 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - - 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. - If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. - nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz -- Thanks, Jay Lau (Guangya Liu) __ 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
Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi all, As we did not hear back further on the requirement of this blueprint, I propose to keep the existing behavior without any modification. We would like to explore the decision on this blueprint on our next weekly IRC meeting[1]. Regards, SURO irc//freenode: suro-patz [1] - https://wiki.openstack.org/wiki/Meetings/Containers 2015-07-28 UTC 2200 Tuesday On 7/21/15 4:54 PM, SURO wrote: Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz __ 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-dev] [magnum][blueprint] magnum-service-list
Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the following implementation - * 'magnum service-list' should be similar to 'nova service-list' * 'magnum service-list' should be moved to be ' magnum k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list' As I dug some details, I find - * 'magnum service-list' fetches data from OpenStack DB[2], instead of the COE endpoint. So technically it is not k8s-specific. magnum is serving data for objects modeled as 'service', just the way we are catering for 'magnum container-list' in case of swarm bay. * If magnum provides a way to get the COE endpoint details, users can use native tools to fetch the status of the COE-specific objects, viz. 'kubectl get services' here. * nova has lot more backend services, e.g. cert, scheduler, consoleauth, compute etc. in comparison to magnum's conductor only. Also, not all the api's have this 'service-list' available. With these arguments in view, can we have some more explanation/clarification in favor of the ask in the blueprint? [1] - https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114 -- Regards, SURO irc//freenode: suro-patz __ 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
