Open Stack

Hi Stdake and Vilobh,

If I get what you proposed below, you means pod/rc/service would not be
stored in magnum side, Just retrieved and updated in k8s side ?

For now, if magnum not add any specific logic to pod/rc/service, that can
be OK.


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:	"Steven Dake (stdake)" <stdake at cisco.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	08/12/2015 11:52 PM
Subject:	Re: [openstack-dev] [Magnum] Obtain the objects from the bay
            endpoint





From: Akash Gangil <akashg1611 at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Date: Wednesday, August 12, 2015 at 1:37 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum] Obtain the objects from the bay
endpoint

      Hi,

      I have a few questions. inline.


        Problem :-

        Currently objects (pod/rc/service) are read from the database. In
        order for native clients to work, they must be read from the ReST
        bay endpoint. To execute native clients, we must have one truth of
        the state of the system, not two as in its current state of art.


      What is meant by the "native" clients here? Can you give an example?

Native client is docker binary or kubectl from those various projects.  We
also need to support python-magnumclient operations to support further Heat
integration, which allows Magnum to be used well with proprietary software
implementations that may be doing orchestration via Heat.



        A]  READ path needs to be changed :

        1. For python clients :-


        python-magnum client->rest api->conductor->rest-endpoint-k8s-api
        handler


        In its present state of art this is python-magnum client->rest
        api->db


        2. For native clients :-

        native client->rest-endpoint-k8s-api



      If native client can get all the info through the rest-endpoint-k8s
      handler, why in case of magnum client do we need to go through
      rest-api-> conductor? Do we parse or modify the k8s-api data before
      responding to the python-magnum client?



Kubernetes has a rest API endpoint running in the bay.  This is different
from the Magnum rest API.  This is what is referred to above.

        B] WRITE operations need to happen via the rest endpoint instead of
        the conductor.

      If we completely bypass the conductor, is there any way to keep a
      track of trace of how a resource was modified? Since I presume now
      magnum doesn't have that info, since we talk to k8s-api directly? Or
      is this irrelevant?
        C] Another requirement that needs to be satisfied is that data
        returned by magnum should be the same whether its created by native
        client or python-magnum client.

      I don't understand why is the information duplicated in the magnum db
      and k8s data source in first place? From what I understand magnum has
      its own database which is with k8s-api responses?

The reason it is duplicated is because when I wrote the original code, I
didn’t forsee this objective.  Essentially I’m not perfect ;)

        The fix will make sure all of the above conditions are met.


        Need your input on the proposed approach.



ACK accurate of my understanding of the proposed approach :)
        -Vilobh


        [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay
        __________________________________________________________________________

        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




      --
      Akash
      __________________________________________________________________________

      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/20150813/0a1cf2e0/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/20150813/0a1cf2e0/attachment.gif>