Open Stack

Carlos,
The module skeleton, including API functions and their brief description, was committed at https://review.openstack.org/#/c/109849/

checkContainerExistance 		-should be used by LBaaS API, I will merge it into TLS implementation change.
					- Throwing TLSContainerNotFound exception
validateContainer 			-should be used LBaaS API instead of checkContainerExistance if we will be able to implement it for Juno.
					- Throwing TLSContainerNotFound or TLSContainerInvalid exceptions
_getContainerAndRegisterConsumer 	- internal. Used by checkContainerExistance and validateContainer. Getting container by posting service as a container consumer.
unregisterContainerConsumer		- should be used by LBaaS API when container is not used for listeners anymore. I will implement it in TLS implementation change. Also used by
 					- also used by checkContainerExistance and validateContainer in order not to leave containers consumed in Barbican before
 					- driver does the real consumer registration with getCertificateX509 and/or extractCertificateHostNames
getCertificateX509			- should be used by specific vendor driver. Getting container by posting service as a container consumer. Returns certificate's X509
extractCertificateHostNames		- should be used by specific vendor driver. Getting certificate's X509 by using getCertificateX509 and returns SCN and SAN names dict.

I will appreciate your opinion on this API. 

Thanks,
Evg


-----Original Message-----
From: Carlos Garza [mailto:carlos.garza at rackspace.com] 
Sent: Thursday, July 24, 2014 7:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction

Sorry I meant to say I'm pretty agreeable just park a stub module so I can populate it.
On Jul 24, 2014, at 11:06 AM, Carlos Garza <carlos.garza at rackspace.com>
 wrote:

> I'Just park a module 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
> 


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev