[openstack-dev] [magnum][blueprint] magnum-service-list

Hongbin Lu hongbin.lu at huawei.com
Wed Jul 29 21:21:41 UTC 2015


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,

From: SURO [mailto:suro.patz at gmail.com]
Sent: July-29-15 4:03 PM
To: Jay Lau
Cc: suro at 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.



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?

2015-07-27 20:12 GMT-04:00 SURO <suro.patz at gmail.com<mailto:suro.patz at 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].



irc//freenode: suro-patz

[1] - https://wiki.openstack.org/wiki/Meetings/Containers

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




irc//freenode: suro-patz

Jay Lau (Guangya Liu)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150729/578fae5b/attachment.html>

More information about the OpenStack-dev mailing list