Open Stack

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