<div dir="ltr">+ 1 to vikas.<div><br></div><div>As we have monitor framework only to docker swarm COE at present and we are pushing other COE drivers in future. So it is better to have component status for one COE at first and will push other COEs support later. Correct me if I am wrong.</div><div><br></div><div>Regards</div><div>Bharath T</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 9:26 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@ Eli ,<div><br></div><div>I will look into how to support this feature for other COEs also(mesos and swarm). But anyways Magnum's goal is to provide users *atleast* what other coes are providing (if not something extra). All coes dont have common features, so we cant be very strict on providing common interface apis for all coes. For example "magnum container" commands work only with swarm not k8s or mesos. </div><div>It will not be justified if k8s is providing a way to monitor at more granular level but magnum will not allow user to use it just beacuse other coes does not provide this feature.</div><div><br></div><div>Agree that it will be nice if could support this feature for all. I will prefer to start with k8s first and if similar feature is supported by mesos and swarm also, incrementally will implement that also.</div><div><br></div><div>Regards </div><span class="HOEnZb"><font color="#888888"><div>Vikas Choudhary </div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong <span dir="ltr"><<a href="mailto:liyong.qiao@intel.com" target="_blank">liyong.qiao@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
hi Vikas,<br>
thanks for propose this changes, I wonder if you can show some
examples for other coes we currently supported:<br>
swarm, mesos ?<br>
<br>
if we propose a public api like you proposed, we'd better to support
all coes instead of coe specific.<br>
<br>
thanks<br>
Eli.<div><div><br>
<br>
<div>On 2015年10月20日 18:14, Vikas Choudhary
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div dir="ltr">Hi Team,
<div><br>
</div>
<div>I would appreciate any opinion/concern regarding
"coe-component-status" feature implementation [1].</div>
<div><br>
</div>
<div>For example in k8s, using API<span style="background-color:rgb(255,255,255)"><font color="#000000"> <span style="font-family:sans-serif;font-size:12px;line-height:18px">api/v1/</span><span style="font-family:sans-serif;font-size:12px;line-height:18px">namespaces/</span><span style="font-family:sans-serif;font-size:12px;line-height:18px">{namespace}</span><span style="font-family:sans-serif;font-size:12px;line-height:18px">/componentstatu</span><font face="sans-serif"><span style="font-size:12px;line-height:18px">ses, status of
each k8s component can be queried. My approach would
be to provide a command in magnum like "magnum
coe-component-status" leveraging coe provided rest api
and result will be shown to user.</span></font></font></span></div>
<div><span style="background-color:rgb(255,255,255)"><font color="#000000"><span style="font-family:sans-serif;font-size:12px;line-height:18px"><br>
</span></font></span></div>
<div>[1] <a href="https://blueprints.launchpad.net/magnum/+spec/coe-component-status" target="_blank">https://blueprints.launchpad.net/magnum/+spec/coe-component-status</a><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-Vikas Choudhary</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<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><span><font color="#888888">
</font></span></pre><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br>
<pre cols="72">--
BR, Eli(Li Yong)Qiao</pre>
</font></span></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></div>
</div></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></div>