Open Stack

I'm interested in the discussion. UTC-8.

Gary


On Wed, Feb 12, 2014 at 10:22 AM, Mandeep Dhami <dhami at noironetworks.com>wrote:

>
> I would be interested as well (UTC-8).
>
> Regards,
> Mandeep
>
>
>
> On Wed, Feb 12, 2014 at 8:18 AM, Eugene Nikanorov <enikanorov at mirantis.com
> > wrote:
>
>> I'd be interested too.
>>
>> Thanks,
>> Eugene.
>>
>>
>> On Wed, Feb 12, 2014 at 7:51 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:
>>
>>> Paul,
>>>
>>> I'm interesting in joining the discussion.  UTC-7.  Any word on when
>>> this will take place?
>>>
>>> Carl
>>>
>>> On Mon, Feb 3, 2014 at 3:19 PM, Paul Michali <pcm at cisco.com> wrote:
>>> > 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):
>>> >
>>> > How to handle vendor specific validation (e.g. say a vendor has
>>> restrictions
>>> > or added capabilities compared to the reference drivers for
>>> attributes).
>>> > Providing "client" feedback (e.g. should help and validation be
>>> extended to
>>> > include vendor capabilities or should it be delegated to server
>>> reporting?)
>>> > 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?)
>>> > Persistence of vendor specific information (e.g. should new tables be
>>> used
>>> > or should/can existing reference tables be extended?).
>>> > 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?)
>>> > 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)
>>> >
>>> > 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.
>>> >
>>> > Looking to hearing form you!
>>> >
>>> > PCM (Paul Michali)
>>> >
>>> > MAIL          pcm at cisco.com
>>> > IRC            pcm_  (irc.freenode.net)
>>> > TW            @pmichali
>>> > GPG key    4525ECC253E31A83
>>> > Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140212/4000328c/attachment.html>