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 <[email protected]
<mailto:[email protected]>>:
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 <[email protected]
<mailto:[email protected]>>:
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] <mailto:[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
<mailto:[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://[email protected]?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: [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
