Open Stack

    Are you close to adding the stub modules for the X509 parsing and barbicn integration etc.

On Jul 24, 2014, at 6:38 AM, Evgeny Fedoruk <EvgenyF at Radware.com> wrote:

> Hi Doug,
> I agree with Brandon, since there is no flavors framework yet, each driver not supporting TLS is in charge of throwing the unsupported exception.
> The driver can do it once getting a listener with TERMINATED-HTTPS protocol.
> 
> Evg
> 
> 
> -----Original Message-----
> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] 
> Sent: Wednesday, July 23, 2014 9:09 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] FW: [Neutron][LBaaS] TLS capability - work division
> 
> @Evgeny: Did you intend on adding another patchset in the reviews I've been working on? If so I don't really see any changes, so if they're are some changes you needed in there let me know.
> 
> @Doug: I think if the drivers see the TERMINATED_HTTPS protocol then they can throw an exception.  I don't think a driver interface change is needed.
> 
> Thanks,
> Brandon
> 
> 
> On Wed, 2014-07-23 at 17:02 +0000, Doug Wiegley wrote:
>> Do we want any driver interface changes for this?  At one level, with 
>> the current interface, conforming drivers could just reference 
>> listener.sni_containers, with no changes.  But, do we want something 
>> in place so that the API can return an unsupported error for non-TLS 
>> v2 drivers?  Or must all v2 drivers support TLS?
>> 
>> doug
>> 
>> 
>> 
>> On 7/23/14, 10:54 AM, "Evgeny Fedoruk" <EvgenyF at Radware.com> wrote:
>> 
>>> My code is here:
>>> https://review.openstack.org/#/c/109035/1
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Evgeny Fedoruk
>>> Sent: Wednesday, July 23, 2014 6:54 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - work 
>>> division
>>> 
>>> Hi Carlos,
>>> 
>>> As I understand you are working on common module for Barbican 
>>> interactions.
>>> I will commit my code later today and I will appreciate if you and 
>>> anybody else  who is interested will review this change.
>>> There is one specific spot for the common Barbican interactions 
>>> module API integration.
>>> After the IRC meeting tomorrow, we can discuss the work items and 
>>> decide who is interested/available to do them.
>>> Does it make sense?
>>> 
>>> Thanks,
>>> Evg
>>> 
>>> -----Original Message-----
>>> From: Carlos Garza [mailto:carlos.garza at rackspace.com]
>>> Sent: Wednesday, July 23, 2014 6:15 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - work 
>>> division
>>> 
>>>   Do you have any idea as to how we can split up the work?
>>> 
>>> On Jul 23, 2014, at 6:01 AM, Evgeny Fedoruk <EvgenyF at Radware.com>
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm working on TLS integration with loadbalancer v2 extension and db.
>>>> Basing on Brandon's  patches 
>>>> https://review.openstack.org/#/c/105609 , 
>>>> https://review.openstack.org/#/c/105331/  , 
>>>> https://review.openstack.org/#/c/105610/
>>>> I will abandon previous 2 patches for TLS which are 
>>>> https://review.openstack.org/#/c/74031/ and 
>>>> https://review.openstack.org/#/c/102837/
>>>> Managing to submit my change later today. It will include lbaas 
>>>> extension v2 modification, lbaas db v2 modifications, alembic 
>>>> migration for schema changes and new tests in unit testing for lbaas db v2.
>>>> 
>>>> Thanks,
>>>> Evg
>>>> 
>>>> -----Original Message-----
>>>> From: Carlos Garza [mailto:carlos.garza at rackspace.com]
>>>> Sent: Wednesday, July 23, 2014 3:54 AM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - work 
>>>> division
>>>> 
>>>> 	Since it looks like the TLS blueprint was approved I''m sure were 
>>>> all eager to start coded so how should we divide up work on the source code.
>>>> I have Pull requests in pyopenssl
>>>> "https://github.com/pyca/pyopenssl/pull/143". and a few one liners 
>>>> in pica/cryptography to expose the needed low-level that I'm hoping 
>>>> will be added pretty soon to that PR 143 test's can pass. Incase it 
>>>> doesn't we will fall back to using the pyasn1_modules as it already 
>>>> also has a means to fetch what we want at a lower level.
>>>> I'm just hoping that we can split the work up so that we can 
>>>> collaborate together on this with out over serializing the work were 
>>>> people become dependent on waiting for some one else to complete 
>>>> their work or worse one person ending up doing all the work.
>>>> 
>>>> 
>>>>      Carlos D. Garza 
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> 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