[openstack-dev] [magnum][blueprint] magnum-service-list
Kai Qiang Wu
wkqwu at cn.ibm.com
Tue Aug 4 00:33:47 UTC 2015
Hi Suro and Jay,
I checked discussion below, and I do believe we also need service-list(for
just magnum-api and magnum-conductor), but not so emergent requirement.
I also think service-list should not bind to k8s or swarm etc. (can use
coe-service etc.)
But I have more for below:
1) For k8s or swarm or mesos, I think magnum can expose through the
coe-service-list.
But if right now, we fetched status from DB for pods/rcs status, It seems
not proper to do that, as DB has old data. We need to fetch that through
k8s/swarm API endpoints.
2) It can also expose that through k8s/swarm/mesos client tools. If users
like that.
Thanks
Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强 Kennan）
IBM China System and Technology Lab, Beijing
E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!
From: Jay Lau <jay.lau.513 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 08/04/2015 05:51 AM
Subject: Re: [openstack-dev] [magnum][blueprint] magnum-service-list
Hi Suro,
Yes, I did not see a strong reason for adding "service-list" to show all of
magnum system services, but it is nice to have.
But I did see a strong reason to rename "service-list" to
"coe-service-list" or others which might be more meaningful as I was often
asked by someone why does "magnum service-list" is showing some services in
kubernetes but not magnum system itself? This command always make people
confused.
Thanks!
2015-08-03 15:36 GMT-04:00 SURO <suro.patz at gmail.com>:
Hi Jay,
Thanks for clarifying the requirements further.
I do agree with the idea of having 'magnum service-list' and 'magnum
coe-service-list' to distinguish that coe-service is a different concept.
BUT, in openstack space, I do not see 'service-list' as a standardized
function across other APIs -
1. 'nova service-list' => Enlists services like api, conductor etc.
2. neutron does not have this option.
3. 'heat service-list' => Enlists available engines.
4. 'keystone service-list' => Enlists services/APIs who consults
keystone.
Now in magnum, we may choose to model it after nova, but nova really has
a bunch of backend services, viz. nova-conductor, nova-cert,
nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not.
For magnum, at this point creating 'service-list' only for api/conductor
- do you see a strong need?
Regards,
SURO
irc//freenode: suro-patz
On 8/3/15 12:00 PM, Jay Lau wrote:
Hi Suro and others, comments on this? Thanks.
2015-07-30 5:40 GMT-04:00 Jay Lau <jay.lau.513 at gmail.com>:
Hi Suro,
In my understanding, even other CoE might have service/pod/rc
concepts in future, we may still want to distinguish the "magnum
service-list" with "magnum coe-service-list".
service-list is mainly for magnum native services, such as
magnum-api, magnum-conductor etc.
coe-service-list mainly for the services that running for the CoEs
in magnum.
Thoughts? Thanks.
2015-07-29 17:50 GMT-04:00 SURO <suro.patz at gmail.com>:
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:suro.patz at gmail.com]
Sent: July-29-15 4:03 PM
To: Jay Lau
Cc: suro at yahoo-inc.com; 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 <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 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:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Jay Lau (Guangya Liu)
--
Thanks,
Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/68df6675/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/68df6675/attachment.gif>
More information about the OpenStack-dev
mailing list
