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 []
Sent: July-29-15 4:03 PM
To: Jay Lau
Cc:; OpenStack Development Mailing List (not for usage 
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 
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 



irc//freenode: suro-patz

[1] -

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] - [2] -




irc//freenode: suro-patz

Jay Lau (Guangya Liu)

OpenStack Development Mailing List (not for usage questions)

Reply via email to