Open Stack

@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.

They¹d have to know to throw it, which could be problematic.  But A
completely new protocol will probably result in some kind of exception, so
it¹s probably sufficient.

doug



On 7/23/14, 12:08 PM, "Brandon Logan" <brandon.logan at RACKSPACE.COM> wrote:

>@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