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