<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)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">The current tap-service-* and tap-flow-* APIs are synchronous. When the call completes a status of success or failure is returned. The problem here though is that this status is being returned by the TaaS plugin after it goes through some
checks and successfully updates the configuration state. One of the operations performed by the plugin is to issue tasks to the TaaS agent/driver. However, failures encountered by the latter don’t get returned back to the user. This can lead to problem situations
where the configuration state might reflect that tap-services and/or tap-flows have been successfully created, but in actuality that may not always be the case.
<o:p></o:p></p>
<p class="MsoNormal">I think we should adopt an asynchronous model, where we maintain the state for tap-service and tap-flow objects. Valid states could be “created”, “create-pending” and “failed.” In addition, we will need a suitable mechanism to have the
plugin extract the current state from the agent/driver and provide it to the end-user.
<o:p></o:p></p>
<p class="MsoNormal">Another scenario where the asynchronous model with states (as described above) will be useful is for TaaS backend implementations that may take a while to complete certain operations. In this situation, the front-end doesn’t need to block
completely; it can return as soon as the request is successfully handed to the agent or if the config tasks itself failed. For the former case, subsequent queries of the object’s state will indicate if the operation has completed, is still pending or has failed.<o:p></o:p></p>
<p class="MsoNormal">Thoughts…? <o:p></o:p></p>
<p class="MsoNormal">Anil<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>