[openstack-dev] [magnum][blueprint] magnum-service-list
Jay Lau
jay.lau.513 at gmail.com
Tue Aug 4 03:18:57 UTC 2015
Cool, Suro! It's great that we finally reach an agreement on this ;-)
2015-08-03 20:43 GMT-04:00 SURO <suro.patz at 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: wkqwu at 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.513 at gmail.com> <jay.lau.513 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org> <openstack-dev at 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.patz at gmail.com>*suro.patz at gmail.com
> <suro.patz at 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.513 at gmail.com*
> <jay.lau.513 at 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.patz at gmail.com*
> <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 [ <suro.patz at gmail.com>*mailto:suro.patz at gmail.com
> <suro.patz at gmail.com>*]
> * Sent:* July-29-15 4:03 PM
> * To:* Jay Lau
> * Cc:* <suro at yahoo-inc.com>*suro at yahoo-inc.com <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 < <suro.patz at gmail.com>*suro.patz at gmail.com
> <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>*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-request at lists.openstack.org?subject:unsubscribe>*OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <OpenStack-dev-request at 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-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*
> <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-request at lists.openstack.org?subject:unsubscribe*
> <OpenStack-dev-request at 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-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*
> <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?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:unsubscribehttp://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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Thanks,
Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/9d911d38/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/9d911d38/attachment.gif>
More information about the OpenStack-dev
mailing list
