<div dir="ltr"><div><div><div>Hi Suro,<br><br></div>Yes, I did not see a strong reason for adding "service-list" to show all of magnum system services, but it is nice to have.<br><br></div>But I did see a strong reason to rename "service-list" to "coe-service-list" or others which might be more meaningful as I was often asked by someone why does "magnum service-list" is showing some services in kubernetes but not magnum system itself? This command always make people confused.<br><br></div>Thanks!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-03 15:36 GMT-04:00 SURO <span dir="ltr"><<a href="mailto:suro.patz@gmail.com" target="_blank">suro.patz@gmail.com</a>></span>:<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 Jay, <br>
<br>
Thanks for clarifying the requirements further.<br>
<br>
I do agree with the idea of having 'magnum service-list' and 'magnum
coe-service-list' to distinguish that coe-service is a different
concept. BUT, in openstack space, I do not see 'service-list' as a
standardized function across other APIs -<br>
<ol>
<li> 'nova service-list' => Enlists services like api,
conductor etc. <br>
</li>
<li> neutron does not have this option.</li>
<li> 'heat service-list' => Enlists available engines.</li>
<li> 'keystone service-list' => Enlists services/APIs who
consults keystone.</li>
</ol>
Now in magnum, we may choose to model it after nova, but nova really
has a bunch of backend services, viz. nova-conductor, nova-cert,
nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum
not.<br>
<br>
For magnum, at this point creating 'service-list' only for
api/conductor - do you see a strong need?<br>
<br>
<pre cols="72">Regards,
SURO
irc//freenode: suro-patz
</pre><div><div class="h5">
<div>On 8/3/15 12:00 PM, Jay Lau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Suro and others, comments on this? Thanks.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-07-30 5:40 GMT-04:00 Jay Lau <span dir="ltr"><<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi Suro,<br>
<br>
</div>
In my understanding, even other CoE might have
service/pod/rc concepts in future, we may still want
to distinguish the "magnum service-list" with
"magnum coe-service-list".<br>
<br>
</div>
service-list is mainly for magnum native services,
such as magnum-api, magnum-conductor etc.<br>
</div>
coe-service-list mainly for the services that running
for the CoEs in magnum.<br>
<br>
</div>
Thoughts? Thanks.<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-07-29 17:50 GMT-04:00
SURO <span dir="ltr"><<a href="mailto:suro.patz@gmail.com" target="_blank">suro.patz@gmail.com</a>></span>:<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 Hongbin,<br>
<br>
What would be the value of having COE-specific
magnum command to go and talk to DB? As in that
case, user may use the native client itself to
fetch the data from COE, which even will have
latest state.<br>
<br>
In a pluggable architecture there is always
scope for common abstraction and driver
implementation. I think it is too early to
declare service/rc/pod as specific to k8s, as
the other COEs may very well converge onto
similar/same concepts.<br>
<br>
<pre cols="72">Regards,
SURO
irc//freenode: suro-patz
</pre>
<span>
<div>On 7/29/15 2:21 PM, Hongbin Lu wrote:<br>
</div>
</span>
<blockquote type="cite">
<div><span>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Suro,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
think service/pod/rc are k8s-specific.
+1 for Jay’s suggestion about renaming
COE-specific command, since the new
naming style looks consistent with
other OpenStack projects. In addition,
it will eliminate name collision of
different COEs. Also, if we are going
to support pluggable COE, adding
prefix to COE-specific command is
unavoidable.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best
regards,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hongbin</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</span>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext" lang="EN-US">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext" lang="EN-US"> SURO [<a href="mailto:suro.patz@gmail.com" target="_blank"></a><a href="mailto:suro.patz@gmail.com" target="_blank">mailto:suro.patz@gmail.com</a>]
<br>
<span> <b>Sent:</b> July-29-15 4:03
PM<br>
<b>To:</b> Jay Lau<br>
<b>Cc:</b> <a href="mailto:suro@yahoo-inc.com" target="_blank"></a><a href="mailto:suro@yahoo-inc.com" target="_blank">suro@yahoo-inc.com</a>;
OpenStack Development Mailing List
(not for usage questions)<br>
<b>Subject:</b> Re:
[openstack-dev]
[magnum][blueprint]
magnum-service-list</span></span></p>
</div>
</div>
<span>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Hi Jay,<br>
<br>
'service'/'pod'/'rc' are conceptual
abstraction at magnum level. Yes, the
abstraction was inspired from the same
in kubernetes, but the data stored in DB
about a 'service' is properly abstracted
and not k8s-specific at the top level. <br>
<br>
If we plan to change this to
'k8s-service-list', the same applies for
even creation and other actions. This
will give rise to COE-specific command
and concepts and which may proliferate
further. Instead, we can abstract
swarm's service concept under the
umbrella of magnum's 'service' concept
without creating k8s-service and
swarm-service.<br>
<br>
I suggest we should keep the
concept/abstraction at Magnum level, as
it is. <br>
<br>
</p>
<pre>Regards,</pre>
<pre>SURO</pre>
<pre>irc//freenode: suro-patz</pre>
<div>
<p class="MsoNormal">On 7/28/15 7:59 PM,
Jay Lau wrote:</p>
</div>
</span>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><span>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi
Suro,</p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Sorry
for late. IMHO, even the "magnum
service-list" is getting data from
DB, but the DB is actually
persisting some data for
Kubernetes service, so my thinking
is it possible to change "magnum
service-list" to "magnum
k8s-service-list", same for pod
and rc.</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I
know this might bring some trouble
for backward compatibility issue,
not sure if it is good to do such
modification at this time.
Comments?</p>
</div>
<p class="MsoNormal">Thanks</p>
</div>
</span>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">2015-07-27
20:12 GMT-04:00 SURO <<a href="mailto:suro.patz@gmail.com" target="_blank"></a><a href="mailto:suro.patz@gmail.com" target="_blank">suro.patz@gmail.com</a>>:</p>
<div>
<p class="MsoNormal">Hi all,<br>
As we did not hear back
further on the requirement of
this blueprint, I propose to
keep the existing behavior
without any modification.<br>
<br>
We would like to explore the
decision on this blueprint on
our next weekly IRC
meeting[1].<br>
</p>
<pre>Regards,</pre>
<pre>SURO</pre>
<pre>irc//freenode: suro-patz</pre>
<pre> </pre>
<pre>[1] - <a href="https://wiki.openstack.org/wiki/Meetings/Containers" target="_blank">https://wiki.openstack.org/wiki/Meetings/Containers</a></pre>
<table border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<p class="MsoNormal">2015-07-28
</p>
</td>
<td style="padding:.75pt .75pt .75pt .75pt">
<p class="MsoNormal">UTC
2200 Tuesday </p>
</td>
</tr>
</tbody>
</table>
<div>
<div>
<pre> </pre>
<div>
<p class="MsoNormal">On
7/21/15 4:54 PM, SURO
wrote: </p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi
all, [special attention:
Jay Lau] The bp[1]
registered, asks for the
following implementation
- </p>
<ul type="disc">
<li class="MsoNormal">
'magnum service-list'
should be similar to
'nova service-list'</li>
<li class="MsoNormal">
'magnum service-list'
should be moved to be
' magnum
k8s-service-list'.
Also similar holds
true for
'pod-list'/'rc-list'</li>
</ul>
<p class="MsoNormal">As I
dug some details, I find
- </p>
<ul type="disc">
<li class="MsoNormal">
'magnum service-list'
fetches data from
OpenStack DB[2],
instead of the COE
endpoint. So
technically it is not
k8s-specific. magnum
is serving data for
objects modeled as
'service', just the
way we are catering
for 'magnum
container-list' in
case of swarm bay.</li>
<li class="MsoNormal">
If magnum provides a
way to get the COE
endpoint details,
users can use native
tools to fetch the
status of the
COE-specific objects,
viz. 'kubectl get
services' here.</li>
<li class="MsoNormal">
nova has lot more
backend services, e.g.
cert, scheduler,
consoleauth, compute
etc. in comparison to
magnum's conductor
only. Also, not all
the api's have this
'service-list'
available. </li>
</ul>
<p class="MsoNormal">With
these arguments in view,
can we have some more
explanation/clarification
in favor of the ask in
the blueprint? [1] - <a href="https://blueprints.launchpad.net/magnum/+spec/magnum-service-list" target="_blank">
</a><a href="https://blueprints.launchpad.net/magnum/+spec/magnum-service-list" target="_blank">https://blueprints.launchpad.net/magnum/+spec/magnum-service-list</a>
[2] - <a href="https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114" target="_blank">
</a><a href="https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114" target="_blank">https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114</a>
</p>
<pre>-- </pre>
<pre>Regards,</pre>
<pre>SURO</pre>
<pre>irc//freenode: suro-patz</pre>
</blockquote>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Thanks,</p>
</div>
<p class="MsoNormal">Jay Lau
(Guangya Liu)</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"> </p>
</div>
<br>
<fieldset></fieldset>
<br>
<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>
</pre>
</blockquote>
<br>
</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">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Thanks,<br>
<br>
</div>
Jay Lau (Guangya Liu)<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Thanks,<br>
<br>
</div>
Jay Lau (Guangya Liu)<br>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<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>
</pre>
</blockquote>
<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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks,<br><br></div>Jay Lau (Guangya Liu)<br></div></div></div></div>
</div>