Open Stack

Jay makes a good point here. The service-list output is specific to the “service” abstraction in the COE, not the system services that are part of magnum. The suggested rename from service-list to coe-service-list would make this distinction more clear.

Adrian

On Jul 30, 2015, at 2:40 AM, Jay Lau <jay.lau.513 at gmail.com<mailto:jay.lau.513 at gmail.com>> wrote:

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<mailto: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<mailto: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 <<mailto:suro.patz at gmail.com>suro.patz at gmail.com<mailto: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<mailto: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://OpenStack-dev-request@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<mailto: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/20150803/264f35ad/attachment.html>