<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Rushi, <br>
    <br>
    Thank you for the response. I totally understand the effort and your
    problems with getting it through at the time. Your design is
    completely inline with what's currently present in Nova for EC2, no
    doubt about that. I did whatever I could to review your patches and
    consider if it's worth to go forward with them in current
    circumstances. I believe it'll add more complications than value if
    we go on with them.<br>
    <br>
    The main design problems, introduced before you, won't go away:<br>
    1. User isolation for shared objects is close to impossible to
    implement in this model.<br>
    2. Marked resources listing when describing tags, will require going
    to all of the possible different APIs and their databases eventually
    and then compiling the result. <br>
    <br>
    The stackforge/ec2-api implementation fortunately had no constraints
    or previously implemented code with some conceptual problems. So it
    could and did store the tags and their associations with resources
    separately. It allowed efficient searching for both describing tags
    and resources. <br>
    <br>
    Strategically if, as I understand, eventual aim is to switch to
    separate ec2-api solution, it makes little sense (to me) to add more
    functionality, especially partial functionality (no
    describe_volumes, describe_snapshots and even if added, no tagging
    for other resources), to current nova code. If the decision was made
    to enhance nova with new features like this, I'd still be for a
    separate table in DB for all of the tags and their associations - it
    would've made universal, complete and efficient solution with one
    effort.<br>
    <br>
    And again, I more than agree with this:<br>
    "<br>
    <div>...I can only wish that the patches got more attention when it
      was possible to get them merged :)</div>
    <div>"<br>
      <br>
      But that's a different story.<br>
      <br>
      Best regards,<br>
        Alex Levine<br>
    </div>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/4/15 4:32 PM, Rushi Agrawal wrote:<br>
    </div>
    <blockquote
cite="mid:CAEtC-YsPmTVDf+FwYTPfArnD7CMgCQfQASPJBghObXqj9GD7_A@mail.gmail.com"
      type="cite">
      <div dir="ltr">Thanks Alex for your detailed inspection of my
        work. Comments inline..
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 3 February 2015 at 21:32,
            Alexandre Levine <span dir="ltr"><<a
                moz-do-not-send="true"
                href="mailto:alevine@cloudscaling.com" target="_blank">alevine@cloudscaling.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> I'm writing this in
                regard to several reviews concering tagging
                functionality for EC2 API in nova.<br>
                The list of the reviews concerned is here:<br>
                <pre><a moz-do-not-send="true" href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ec2-volume-and-snapshot-tags,n,z" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ec2-volume-and-snapshot-tags,n,z</a>
</pre>
                I don't think it's a good idea to merge these reviews.
                The analysis is below:<br>
                <br>
                <b>Tagging in AWS</b><br>
                <br>
                Main goal for the tagging functionality in AWS is to be
                able to efficiently distinguish various resources based
                on user-defined criteria:<br>
                <br>
                <span
style="color:rgb(0,0,0);font-family:verdana,arial,sans-serif;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">"Tags
                  enable you to categorize your AWS resources in
                  different ways, for example, by purpose, owner, or
                  environment.<span> <br>
                    ...</span></span><br>
                <span
style="color:rgb(0,0,0);font-family:verdana,arial,sans-serif;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">You
                  can search and filter the resources based on the tags
                  you add."<br>
                  <br>
                  (quoted from here: <a moz-do-not-send="true"
href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html"
                    target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html</a>)<br>
                </span><br>
                It means that one of the two main use-cases is to be
                able to use Tags as filter when you describe something.
                Another one is to be able to get information about
                particular tag with all of the resources tagged by it.<br>
                Also there is a constraint:<br>
                <p
style="font-family:verdana,arial,sans-serif;font-size:12px;color:rgb(0,0,0);margin-bottom:1em;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">"You


                  can tag public or shared resources, but the tags you
                  assign are available only to your AWS account and not
                  to the other accounts sharing the resource."</p>
                The important part here is "shared resources" which are
                visible to different users but tags are not shared -
                each user sees his own.<br>
                <b><br>
                </b><b>Existing implementation in nova<br>
                  <br>
                </b>Existing implementation of tags in nova's EC2 API
                covers only instances. But it does so in both areas:<br>
                1. Tags management (create, delete, describe,...)<br>
                2. Instances filtering (describe_instances with
                filtering by tags).<br>
                The implementation is based on storing tags in each
                instance's metadata. And nova DB sqlalchemy level uses
                "tag:" in queries to allow instances describing with tag
                filters.<br>
                <br>
                I see the following design flaws in existing
                implementation:<br>
                <br>
                1. It uses instance's own metadata for storing
                information about assigned tags.<br>
                Problems:<br>
                - it doesn't scale when you want to start using tags for
                other resources. Following this design decision you'll
                have to store tags in other resources metadata, which
                mean different services APIs and other databases. So
                performance for searching for tags or tagged resources
                in main use cases should suffer. You'll have to search
                through several remote APIs, querying different
                metadatas to collect all info and then to compile the
                result.<br>
                - instances are not shared resources, but images are. It
                means that, when developed, metadata for images will
                have to store different tags for different users
                somehow.<br>
                <br>
                2. EC2-specific code ("tag:" searching in novaDB
                sqlalchemy) leaked into lower layers of nova.<br>
                - layering is violated. There should be no EC2-specifics
                below EC2 API library in nova, ideally.<br>
              </div>
            </blockquote>
            <div>All of the Nova-EC2 mapping happens in Nova's DB
              currently. See InstanceIdMapping model in
              nova/db/sqlalchemy/models.py. EC2 API which resides in
              Nova will keep using the Nova database as long as it is
              functional.</div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> - each other
                service will have to implement the same solution in its
                own DB level to support tagging for EC2 API.<br>
                <br>
                <b>Proposed review changes</b><b><br>
                </b><br>
                The review in question introduces tagging for volumes
                and snapshots. It follows design decisions of existing
                instance tagging implementation, but realizes only one
                of the two use cases. It provides "create", "delete",
                "describe" for tags. But it doesn't provide
                describe_volumes or describe_snapshots for filtering.<br>
              </div>
            </blockquote>
            <div>I honestly forgot about those two methods. I can
              implement them. </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> <br>
                It suffers from the design flaws I listed above. It has
                to query remote API (cinder) for metadata. It didn't
                implement filtering by "tag:" in cinder DB level so we
                don't see implementation of describe_volumes with tags
                filtering.<br>
              </div>
            </blockquote>
            <div>Cinder do support filtering based on tags, and I marked
              the work as TODO in <a moz-do-not-send="true"
                href="https://review.openstack.org/#/c/112325/23/nova/volume/cinder.py">https://review.openstack.org/#/c/112325/23/nova/volume/cinder.py</a>
              . This was not the reason why I didn't implement
              describe_volumes and describe_snapshots. Those two methods
              just missed my attention :)</div>
            <div><br>
            </div>
            <div>Nova's EC2 API's tag filtering is also done in-memory
              presently if I'm correct, as Nova's API doesn't support
              filtering only on the basis of tag names or tag values
              alone..</div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> <br>
                <b>Current stackforge/ec2-api tagging implementation</b><b><br>
                  <br>
                </b>In comparison, the implementation of tagging in
                stackforge/ec2-api, stores all of the tags and their
                links to resources and users in a separate place. So we
                can efficiently list tags and its resources or filter by
                tags during describing of some of the resources. Also
                user-specific tagging is supported.<br>
                <br>
                <b>Conclusion<br>
                  <br>
                </b>Keeping in mind all of the above, and seeing your
                discussion about deprecation of EC2 API in nova, I don't
                feel it's a good time to add such a half-baked code with
                some potential problems into nova.<b><br>
                </b>I think it's better to concentrate on cleaning up,
                fixing, reviving and making bullet-proof whatever
                functionality is currently present in nova for EC2 and
                used by clients.<br>
              </div>
            </blockquote>
            <div>EC2 API already shares database with Nova's, so the
              tight coupling between EC2 API and Nova's database is not
              going to go away till the time EC2 API server/controller
              is present in Nova. Nova instance metadata is being used
              as EC2 instance tags, and what the above-referenced spec
              is doing is is very similar: Cinder volume metadata is
              being used as EC2 volume tags, and similarly for volume
              snapshots. I don't see a difference between instances and
              volumes and volume snapshots in the sense that they all
              are non-share-able (yet).</div>
            <div><br>
            </div>
            <div>I completely understand that these patches look like
              feature additions. I started working on them first in
              January 2014 ( <a moz-do-not-send="true"
                href="https://review.openstack.org/#/c/64690/">https://review.openstack.org/#/c/64690/</a>
              ), and at that time it was just a sincere effort to
              improve EC2 API using the first possible way I could find
              out. Since we have not deprecated the in-Nova EC2 support
              yet, and we are yet to reach a concrete plan to move
              forward, I am tempted to ask for allowing this patch to be
              considered for review..</div>
            <div><br>
            </div>
            <div>I am fine if people think these patches shouldn't be
              allowed to go in. I can only wish that the patches got
              more attention when it was possible to get them merged :)</div>
            <div><br>
            </div>
            <div>Regards,</div>
            <div>Rushi Agrawal</div>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> <br>
                Best regards,<br>
                  Alex Levine<br>
                <br>
              </div>
              <br>
__________________________________________________________________________<br>
              OpenStack Development Mailing List (not for usage
              questions)<br>
              Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
              <a moz-do-not-send="true"
                href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              <br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>