<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://1510/"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1083724087;
mso-list-type:hybrid;
mso-list-template-ids:-381006326 -450221680 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:16;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:90.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:126.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:162.0pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:198.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:234.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:270.0pt;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:306.0pt;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:342.0pt;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks Vish, that makes it clearer. I guess the validation can be handled by which ever manager picks up the call rather than having to be validates on the manager of a specific host (assuming multi-host of course), which should mean it’s still reasonably responsive.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Just looking through the code it looks to me that there a few things that might still need clearing up to make this separation work. For example:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>_<i>add_flaoting</i>_ip calls to the compute.api (makes sense now) – which could do whatever validation makes sense at the instance level and then passes on the network.api. But _<i>remove</i>_floating_ip calls direct to network_api, so even if the Instance wanted to do some validation it can’t. Shouldn’t both pass through compute.api in this new model ?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There are also a few other casts left in the Network API layer:<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>release_floating_ip<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>deallocate_for_instance<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>add_fixed_ip_to_instance<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>remove_fixed_ip_from_instance<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>add_network_to_project<o:p></o:p></span></p><p class=MsoNormal style='text-indent:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If the network manager if now the only thing that can perform validation shouldn’t all of these be turned into calls as well ?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Vishvananda Ishaya [mailto:vishvananda@gmail.com] <br><b>Sent:</b> 28 March 2012 23:26<br><b>To:</b> Day, Phil<br><b>Cc:</b> openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)<br><b>Subject:</b> Re: [Openstack] Validation of floating IP opertaions in Essex codebase ?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mar 28, 2012, at 10:04 AM, Day, Phil wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Folks,</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>At the risk of looking lazy in my first question by following up with a second:</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So I tracked this down in the code and can see that the validation has moved into network/manager.py, and what was a validation/cast in network/api.py has been replaced with a call – but that seems to make the system more tightly coupled across components (i.e. if my there is a problem getting the message to the Network Manager then even an invalid request will be blocked until the call returns or times out).</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is a side effect of trying to decouple compute and network, see the explanation below.<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It also looks as if the validation for disassociate_floating_ip has also been moved to the manager, but this is still a cast from the api layer – so those error messages never get back to the user.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Good point. This probably needs to be a call with the current model.<o:p></o:p></p></div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Coming from Diablo it all feels kind of odd to me – I thought we were trying to validate what we could of requests in the API server and return immediate errors at that stage and then cast into the system (so that only internal errors can stop something from working at this stage). Was there a deliberate design policy around this at some stage ?</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There are a few things going on here.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>First we have spent a lot of time decoupling network and compute. Ultimately network will be an external service, so we can't depend on having access to the network database on the compute api side. We can do a some checks in compute_api to make sure that it isn't attached to another instance that we know about, but ultimately the network service has to be responsible for saying what can happen with the ip address.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So the second part is about why it is happening in network_manager vs network_api. This is a side-effect of the decision to plug in quantum/melange/etc. at the manager layer instead of the api layer. The api layer is therefore being very dumb, just passing requests on to the manager.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So that explains where we are. Here is the plan (as I understand) for the future:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>a) move the quantum plugin to the api layer<o:p></o:p></p></div><div><p class=MsoNormal>(At this point we could move validation into the api if necessary.)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>b) define a more complete network api which includes all of the necessary features that are currently compute extensions<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>c) make a client to talk to the api<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>d) make compute talk through the client to the api instead of using rabbit messages<o:p></o:p></p></div><div><p class=MsoNormal>(this decouples network completely, allowing us to deploy and run network as a completely separate service if need be. At this point the quantum-api-plugin could be part of quantum or a new shared NaaS project. More to decide at the summit here)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In general, we are hoping to switch to quantum as the default by Folsom, and not have to touch the legacy network code very much. If there are serious performance issues we could make some optimizations by doing checks in network-api, but these will quickly become moot if we are moving towards using a client and talking through a rest interface.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So Looks like the following could be done in the meantime:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>a) switch disassociate from a cast to a call -> i would consider this one a a bug and would appreciate someone verifying that it fails and reporting it<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>b) add some validation in compute api -> I'm not sure what we can assert here. Perhaps we could use the network_info cache and check for duplicates etc.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>c) if we have serious performance issues, we could add another layer of checks in the compute_api, but we may have to make sure that we make sure it is ignored for quantum.<o:p></o:p></p></div></div></body></html>