Cool, Suro! It's great that we finally reach an agreement on this ;-) 2015-08-03 20:43 GMT-04:00 SURO <suro.p...@gmail.com>:
> Thanks Jay/Kennan/Adrian for chiming in! > > From this, I conclude that we have enough consensus to have 'magnum > service-list' and 'magnum coe-service-list' segregated. I will capture > extract of this discussion at the blueprint and start implementation of the > same. > > Kennan, > I would request you to submit a different bp/bug to address the staleness > of the state of pod/rc. > > > Regards, > SURO > irc//freenode: suro-patz > > On 8/3/15 5:33 PM, Kai Qiang Wu wrote: > > 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! > > [image: 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-l]Jay 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> <jay.lau....@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> <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.p...@gmail.com>*suro.p...@gmail.com > <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* > <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* > <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 <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 > <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>*https://wiki.openstack.org/wiki/Meetings/Containers > <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 > > <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 > > <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>*openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > <openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>* > > > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* > > <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* > > <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* > <openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* > <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* > <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: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
