[openstack-dev] [Magnum] Obtain the objects from the bay endpoint

Steven Dake (stdake) stdake at cisco.com
Wed Aug 12 15:47:55 UTC 2015



From: Akash Gangil <akashg1611 at gmail.com<mailto:akashg1611 at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Akash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150812/16761ceb/attachment.html>


More information about the OpenStack-dev mailing list