Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/237388f9/attachment.html>