Hi Suro and others, comments on this? Thanks. 2015-07-30 5:40 GMT-04:00 Jay Lau <[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]>: > >> 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] <[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]> >> [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:unsubscribehttp://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 >> >> > > > -- > 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
