Open Stack

I am interested too. UTC-8.


On Wed, Feb 12, 2014 at 11:38 PM, Gary Duan <garyduan at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20140213/db73a243/attachment.html>