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 <evge...@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.lo...@rackspace.com] > Sent: Wednesday, July 23, 2014 9:09 PM > To: openstack-dev@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" <evge...@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.ga...@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 <evge...@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.ga...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev