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? 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? > 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 fix will make sure all of the above conditions are met. > > Need your input on the proposed approach. > > -Vilobh > > [1] *https://blueprints.launchpad.net/magnum/+spec/objects-from-bay* > <https://blueprints.launchpad.net/magnum/+spec/objects-from-bay> > __________________________________________________________________________ > 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:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Akash
__________________________________________________________________________ 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
