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: wk...@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!
Inactive hide details for Jay Lau ---08/04/2015 05:51:33 AM---Hi Suro,
Yes, I did not see a strong reason for adding "service-lJay Lau
---08/04/2015 05:51:33 AM---Hi Suro, Yes, I did not see a strong
reason for adding "service-list" to show all of
From: Jay Lau <jay.lau....@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@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@gmail.com_
<mailto:suro.p...@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@gmail.com_
<mailto:jay.lau....@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@gmail.com_
<mailto:suro.p...@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@gmail.com_] *
Sent:* July-29-15 4:03 PM*
To:* Jay Lau*
Cc:*_suro@yahoo-inc.com_
<mailto:s...@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@gmail.com_
<mailto:suro.p...@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-requ...@lists.openstack.org?subject:unsubscribe_
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe_
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
