<div dir="ltr">Hi,<div><br></div><div style>I would be interested in this discussion. Below are some time slot suggestions:</div><div style><br></div><div style>Mon: 19:00, 20:00 UTC (11:00, 12:00 PST)</div><div style>Wed: 20:00, 21:00 UTC (12:00, 13:00 PST)</div>
<div style>Thu: 19:00, 20:00, 21:00 UTC (11:00, 12:00, 13:00 PST)</div><div style><br></div><div style>Thanks,</div><div style>-hemanth</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 2:19 PM, Paul Michali <span dir="ltr"><<a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I'd like to see if there is interest in discussing vendor plugins for L3 services. The goal is to strive for consistency across vendor plugins/drivers and across service types (if possible/sensible). Some of this could/should apply to reference drivers as well. I'm thinking about these topics (based on questions I've had on VPNaaS - feel free to add to the list):</div>
<div><br></div><div><ul><li>How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes).</li><li>Providing "client" feedback (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?)</li>
<li>Handling and reporting of errors to the user (e.g. how to indicate to the user that a failure has occurred establishing a IPSec tunnel in device driver?)</li><li>Persistence of vendor specific information (e.g. should new tables be used or should/can existing reference tables be extended?).</li>
<li>Provider selection for resources (e.g. should we allow --provider attribute on VPN IPSec policies to have vendor specific policies or should we rely on checks at connection creation for policy compatibility?)</li><li>
Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type)</li></ul>
<div>If you have an interest, please reply to me and include some days/times that would be good for you, and I'll send out a notice on the ML of the time/date and we can discuss.</div></div><div><br></div><div>Looking to hearing form you!</div>
<div><br></div><div>
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<div>PCM (Paul Michali)</div><div><br></div><div>MAIL <a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a></div><div>IRC pcm_ (<a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>)</div>
<div>TW @pmichali</div><div>GPG key 4525ECC253E31A83</div><div>Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83</div></div></span>
</div>
<br></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>