<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body 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 wrap=""><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ec2-volume-and-snapshot-tags,n,z">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; orphans: auto; text-align: start; text-indent: 0px;
      text-transform: none; white-space: normal; widows: auto;
      word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
      !important; float: none;">"Tags enable you to categorize your AWS
      resources in different ways, for example, by purpose, owner, or
      environment.<span class="Apple-converted-space"> <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; orphans: auto; text-align: start; text-indent: 0px;
      text-transform: none; white-space: normal; widows: auto;
      word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
      !important; float: none;">You can search and filter the resources
      based on the tags you add."<br>
      <br>
      (quoted from here: <a class="moz-txt-link-freetext"
href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html">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; orphans: auto; text-align: start;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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>
    - 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>
    <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>
    <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>
    <br>
    Best regards,<br>
      Alex Levine<br>
    <br>
  </body>
</html>