<div>
                    Hi Rossella,
                </div><div><br></div><div>thanks for starting this discussion so promptly.</div>
                 
                <p style="color: #A0A0A8;">On Wednesday, February 6, 2013 at 1:34 AM, Rossella Sblendido wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>
   

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   
   
    Hi devs,<br>
    <br>
    I'd like to start the discussion regarding the population of the
    Mac-learning table for a bridge using the API. <br>
    You can have a look at the requirements <a href="https://trello.com/card/pre-seed-mac-table-via-rest-api/510b93ac787666573800291f/25">here</a>,
    I'm copying them at the bottom to facilitate the discussion.<br>
    <br>
    Here is my proposal:<br>
    <br>
    <b>API changes</b>:<br>
    <ol>
      <li>We need to have a new DTO to represent the MAC-vPortId
        association, something like:<br>
      </li>
    </ol>
    <p>        public class DtoMacPort {<br>
                      private UUID portId;<br>
                      private MAC mac;<br>
                      // getters<br>
                      // setters<br>
    </p>
    <p>        }<br>
    </p>
    <ol>
      <li>A GET against bridges/bridge_id/macPort will return a
        Collection<DtoMacPort> representing all the entries of the
        Mac-learning table of the bridge whose id is bridge_id.</li></ol></div></div></span></blockquote><div>Is that actual run-time Mac-table contents at that moment in time? Or is it just the list of pre-seeded DtoMacPort? </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><ol>
      <li>A PUT of a DtoMacPort object against bridges/bridge_id/macPort
        will add a new entry to the Mac-learning table, if there's
        already an entry with the same Mac, this will be overwritten.</li></ol></div></div></span></blockquote><div>PUT does not return a DTO to the client. Therefore there's no way of passing the DTO's URI back to the client (in the HATEOAS style) - the client could use a template to generate the URI, but I don't like that being the only option.</div><div><br></div><div>Instead, can we say that the first time the client wants to set the vport for a specific MAC, they do a POST. This will return a DTO that includes the URI of the object, which will be needed for update and deletion. If you do a POST and there's already a mac-port entry for that mac, you get an error.</div><div><br></div><div>Subsequently, if the client wants to change a mac's vport, they set the new vport UUID in the dto and PUT it to the server.</div><div><br></div><div>If a client does not know if this is the first time the mac's vport has been set (doesn't know whether to use PUT or POST), then they have two options:</div><div>- GET as in #1 (lists all the DtoMacPort)</div><div>- Do a GET on a template /bridges/bridge_id/macPort/_mac_. We're using templates in other places for similar reasons. The templates are provided inside DTOs (so that we can evolve them). Where should this template be provided?</div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><ol><li>A DELETE of a DtoMacPort object against
        bridges/bridge_id/macPort will remove the entry whose
        MAC=DtoMacPort.getMac() from the Mac-learning table of the
        bridge whose id is bridge_id<br>
      </li>
    </ol>
    <p></p></div></div></span></blockquote><div>The DELETE will be against the DtoMacPort.getURI() right? And the URI is probably going to be /bridges/bridge_id/macPort/mac.</div><div><br></div><div>However, this has the following consequence, any DTO (even outdated) can be used to DELETE the mac-port entry for that mac.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><p>Do we need a method to check if a specific MAC is already in the
      map?<br>
    </p>
    <b>ZK changes</b>:<br>
    <br>
    We store the MAC/vPortId association in ZK under:<br>
    <br>
    bridges/bridge_id/mac_ports/<br>
    <br>
    We use a ReplicatedMap, whose key is the Mac and value is the UUID
    of the port. ReplicatedMap as the name says is a map that is stored
    both in memory and in ZK. We load it when we initialize it and we
    keep it in sync with ZK.<br>
    In our code any entry (Mac1, inPort1) in the Mac-learning table gets
    deleted when the flows count whose sourceMac = Mac1  and ingressPort
    = inPort1 reaches 0. My interpretation of permanent entries is that
    we don't modify them taking into account the flows count, hopefully
    I'm not wrong. <br>
    To make the entry permanent I'd add a boolean in the ReplicatedMap,
    isPermanent. If isPermanent=true then the entry cannot be removed.<br></div></div></span></blockquote><div>I would hold off on the discussion of the API back-end implementation so we can focus on the API design. The API design is of interest to a wider audience than the back-end implementation, so I would have the latter discussion in a separate thread (and only after the API design has been agreed).</div><div><br></div><div>Caveat: I think it's reasonable that during the API design discussion someone says "That API won't work because there's no way the back-end can support it." But it becomes a question of feasibility, not converging on a specific back-end design.</div><div><br></div><div>cheers,</div><div>Pino</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div>
    <br>
    <br>
------------------------------------------------------------------------------------------------------------------<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <div attr="desc">
      <div style="display: block;">
        <p><strong>Feature description</strong><br>
          The API allows populating the virtual bridge's mac-learning
          table with permanent entries. This is used to avoid flooding
          the bridge for use-cases where the vport/mac pairs are known
          in advance.</p>
        <p><strong>Core team responsibilities</strong><br>
          - Propose API changes to expose the MAC-learning table for
          viewing and manipulating.<br>
          - Design ZK changes (should be backward compatible)<br>
          - Implement API server changes and Midolman changes.</p>
        <p><strong>Integration team responsibilities</strong><br>
          - Modify OpenStack integration to pass OS vport/mac pair
          information as Mac-table entries at instance launch.</p>
        <p><strong>GUI/management team</strong><br>
          - Define existing page that need to change (none?)<br>
          - Define new pages - one to display the mac-table contents?<br>
          - Implement the new pages.</p>
        <p><strong>QA team responsibilities</strong><br>
          - Normal vetting of a software version. The changes are not
          user-visible because this is an optimization.</p>
        <p><strong>Schedule</strong><br>
          - Agree on REST API changes by Feb. 11<br>
          - Core team delivers implementation prototype by Feb. 18<br>
          - Core team completes testing by Feb. 25.<br>
          - Integration team completes changes to Grizzly/Diyari by Feb.
          25.<br>
          - QA team approves by March 1.</p>
      </div>
    </div>
    <br>
   

</div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>