Hi Hongbin,
What would be the value of having COE-specific magnum command to go and
talk to DB? As in that case, user may use the native client itself to
fetch the data from COE, which even will have latest state.
In a pluggable architecture there is always scope for common abstraction
and driver implementation. I think it is too early to declare
service/rc/pod as specific to k8s, as the other COEs may very well
converge onto similar/same concepts.
Regards,
SURO
irc//freenode: suro-patz
On 7/29/15 2:21 PM, Hongbin Lu wrote:
Suro,
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,
Hongbin
*From:*SURO [mailto:[email protected]]
*Sent:* July-29-15 4:03 PM
*To:* Jay Lau
*Cc:* [email protected]; 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.
Regards,
SURO
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?
Thanks
2015-07-27 20:12 GMT-04:00 SURO <[email protected]
<mailto:[email protected]>>:
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
--
Thanks,
Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
