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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
