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.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....@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.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 [ <suro.p...@gmail.com>mailto:suro.p...@gmail.com >>> <suro.p...@gmail.com>] >>> *Sent:* July-29-15 4:03 PM >>> *To:* Jay Lau >>> *Cc:* <s...@yahoo-inc.com>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.p...@gmail.com> >>> 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> >>> https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] - >>> <https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114> >>> 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:unsubscribehttp://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 >>> >>> >> >> >> -- >> 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:unsubscribehttp://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 > > -- 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
