Open Stack

I'Just park a madule with a stub call that I can populate with 
pyasn1.
On Jul 24, 2014, at 10:38 AM, Evgeny Fedoruk <EvgenyF at Radware.com>
 wrote:

> Hi,
>  
> Following our talk on TLS work items split,
> We need to decide how will we validate/extract certificates Barbican TLS containers.
> As we agreed on IRC, the first priority should be certificates fetching.
>  
> TLS RST describes a new common module that will be used by LBaaS API and LBaaS drivers.
> It’s proposed front-end API is currently:
> 1. Ensuring Barbican TLS container existence (used by LBaaS API)
> 2. Validating Barbican TLS container (used by LBaaS API)
>    This API will also "register" LBaaS as a container's consumer in Barbican's repository.
>    POST request:
>    http://admin-api/v1/containers/{container-uuid}/consumers
>    {
>     "type": "LBaaS",
>     "URL": "https://lbaas.myurl.net/loadbalancers/<lbaas_loadbalancer_id>/"
>    }
>  
> 3. Extracting SubjectCommonName and SubjectAltName information
>     from certificates’ X509 (used by LBaaS front-end API)
>    As for now, only dNSName (and optionally directoryName) types will be extracted from
>     SubjectAltName sequence,
>  
> 4. Fetching certificate’s data from Barbican TLS container
>     (used by provider/driver code)
>  
> 5. Unregistering LBaaS as a consumer of the container when container is not
>      used by any listener any more (used by LBaaS front-end API)
>  
> So this new module’s front-end is used by LBaaS API/drivers and its back-end is facing Barbican API.
> Please give your feedback on module API, should we merge 1 and 2?
>  
> I will be able to start working on the new module skeleton on Sunday morning. It will include API functions.
>  
> TLS implementation patch has a spot where container validation should happen:https://review.openstack.org/#/c/109035/3/neutron/db/loadbalancer/loadbalancer_dbv2.py line 518
> After submitting the module skeleton I can make the TLS implementation patch to depend on that module patch and use its API.
>  
> As an alternative we might leave this job to drivers, if common module will be not implemented
>  
> What are your thoughts/suggestions/plans?
>  
> Thanks,
> Evg
>  
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev