<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi, </div><div><br></div><div>I have a few questions. inline.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5"><font size="3" face="Georgia"></font><font size="3" face="Georgia">Problem :-</font><br>
<br>
<font size="3" face="Georgia">C</font><font size="3" color="#333333" face="Georgia">urrently 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.</font><br>
<br></div></div></div></blockquote><div><br></div><div>What is meant by the "native" clients here? Can you give an example?</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5">
<font size="3" color="#333333" face="Georgia">A]  READ path needs to be changed :</font><br>
<br>
<font size="3" color="#333333" face="Georgia">1. For python clients :-</font>
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">python-magnum client->rest api->conductor->rest-endpoint-k8s-api handler </font>
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">In its present state of art this is python-magnum client->rest api->db</font>
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">2. For native clients :-</font><br>
<br>
<font size="3" face="Georgia">native client->rest-endpoint-k8s-api</font>
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia"></font></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5"><font size="3" face="Georgia">B] WRITE operations need to happen via the rest endpoint instead of the conductor.</font></div></div></div></blockquote><div><br></div><div>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? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5">
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">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.</font></div></div></div></blockquote><div><br></div><div>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?  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="h5">
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">The fix will make sure all of the above conditions are met.</font>
</div></div><p></p><div><div class="h5"><font size="3" face="Georgia">Need your input on the proposed approach.</font>
</div></div><p>
</p><p><font size="3" face="Georgia">-Vilobh</font>
</p><p><font size="3" face="Georgia">[1] </font><a href="https://blueprints.launchpad.net/magnum/+spec/objects-from-bay" target="_blank"><font size="3" color="#0000FF" face="Georgia"><u>https://blueprints.launchpad.net/magnum/+spec/objects-from-bay</u></font></a><tt><font size="2">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt>
</p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Akash<br></div>
</div></div>