<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 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 class="">
    <div>On 7/29/15 2:21 PM, Hongbin Lu wrote:<br>
    </div>
    </span><blockquote type="cite">
      
      
      
      <div><span class="">
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Suro,<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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.<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best
            regards,<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hongbin<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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">mailto:suro.patz@gmail.com</a>]
                <br><span class="">
                <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">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<u></u><u></u></span></span></p>
          </div>
        </div><span class="">
        <p class="MsoNormal"><u></u> <u></u></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>
          <u></u><u></u></p>
        <pre>Regards,<u></u><u></u></pre>
        <pre>SURO<u></u><u></u></pre>
        <pre>irc//freenode: suro-patz<u></u><u></u></pre>
        <div>
          <p class="MsoNormal">On 7/28/15 7:59 PM, Jay Lau wrote:<u></u><u></u></p>
        </div>
        </span><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><span class="">
          <div>
            <div>
              <div>
                <p class="MsoNormal" style="margin-bottom:12.0pt">Hi
                  Suro,<u></u><u></u></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.<u></u><u></u></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?<u></u><u></u></p>
            </div>
            <p class="MsoNormal">Thanks<u></u><u></u></p>
          </div>
          </span><div><div class="h5"><div>
            <p class="MsoNormal"><u></u> <u></u></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>>:<u></u><u></u></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>
                    <u></u><u></u></p>
                <pre>Regards,<u></u><u></u></pre>
                <pre>SURO<u></u><u></u></pre>
                <pre>irc//freenode: suro-patz<u></u><u></u></pre>
                <pre><u></u> <u></u></pre>
                <pre>[1] - <a href="https://wiki.openstack.org/wiki/Meetings/Containers" target="_blank">https://wiki.openstack.org/wiki/Meetings/Containers</a><u></u><u></u></pre>
                <table border="0" cellpadding="0">
                  <tbody>
                    <tr>
                      <td style="padding:.75pt .75pt .75pt .75pt">
                        <p class="MsoNormal">2015-07-28 <u></u><u></u></p>
                      </td>
                      <td style="padding:.75pt .75pt .75pt .75pt">
                        <p class="MsoNormal">UTC 2200 Tuesday <u></u><u></u></p>
                      </td>
                    </tr>
                  </tbody>
                </table>
                <div>
                  <div>
                    <pre> <u></u><u></u></pre>
                    <div>
                      <p class="MsoNormal">On 7/21/15 4:54 PM, SURO
                        wrote: <u></u><u></u></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 -
                        <u></u><u></u></p>
                      <ul type="disc">
                        <li class="MsoNormal">
                          'magnum service-list' should be similar to
                          'nova service-list'<u></u><u></u></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'<u></u><u></u></li>
                      </ul>
                      <p class="MsoNormal">As I dug some details, I find
                        - <u></u><u></u></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.<u></u><u></u></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.<u></u><u></u></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.
                          <u></u><u></u></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">
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">
https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114</a>
                        <u></u><u></u></p>
                      <pre>-- <u></u><u></u></pre>
                      <pre>Regards,<u></u><u></u></pre>
                      <pre>SURO<u></u><u></u></pre>
                      <pre>irc//freenode: suro-patz<u></u><u></u></pre>
                    </blockquote>
                  </div>
                </div>
              </div>
            </div>
            <p class="MsoNormal"><br>
              <br clear="all">
              <br>
              -- <u></u><u></u></p>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <p class="MsoNormal" style="margin-bottom:12.0pt">Thanks,<u></u><u></u></p>
                    </div>
                    <p class="MsoNormal">Jay Lau (Guangya Liu)<u></u><u></u></p>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div></div></blockquote>
        <p class="MsoNormal"><u></u> <u></u></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 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>