[openstack-dev] [magnum][blueprint] magnum-service-list

Kai Qiang Wu wkqwu at cn.ibm.com
Tue Aug 4 00:33:47 UTC 2015


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!



From:	Jay Lau <jay.lau.513 at gmail.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <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>:
  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>:
         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>:
           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; 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
                       >:


                       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

                 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://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
        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://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/68df6675/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/68df6675/attachment.gif>


More information about the OpenStack-dev mailing list