[openstack-dev] [magnum][blueprint] magnum-service-list
suro.patz at gmail.com
Wed Jul 29 20:02:37 UTC 2015
'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.
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
> We would like to explore the decision on this blueprint on our
> next weekly IRC meeting.
> irc//freenode: suro-patz
>  -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 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
>> As I dug some details, I find -
>> * 'magnum service-list' fetches data from OpenStack DB,
>> 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'
>> With these arguments in view, can we have some more
>> explanation/clarification in favor of the ask in the blueprint?
>>  -
>>  -
>> irc//freenode: suro-patz
> Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev