<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>