[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

Clint Byrum clint at fewbar.com
Sun Jun 8 23:22:40 UTC 2014

Excerpts from Eichberger, German's message of 2014-06-06 15:52:54 -0700:
> Jorge + John,
> I am most concerned with a user changing his secret in barbican and then the LB trying to update and causing downtime. Some users like to control when the downtime occurs.

Couldn't you allow a user to have multiple credentials, the way basically
every key based user access system works (for an example see SSH). Users
changing their credentials would create new ones, reference them in the
appropriate consuming service, and dereference old ones when they are
believed to be out of service.

I see both specified options as overly complicated attempts to work
around what would be solved gracefully with a many-to-one relationship
of keys to users.

> For #1 it was suggested that once the event is delivered it would be up to a user to enable an "auto-update flag".
> In the case of #2 I am a bit worried about error cases: e.g. uploading the certificates succeeds but registering the loadbalancer(s) fails. So using the barbican system for those warnings might not as fool proof as we are hoping. 
> One thing I like about #2 over #1 is that it pushes a lot of the information to Barbican. I think a user would expect when he uploads a new certificate to Barbican that the system warns him right away about load balancers using the old cert. With #1 he might get an e-mails from LBaaS telling him things changed (and we helpfully updated all affected load balancers) -- which isn't as immediate as #2. 
> If we implement an "auto-update flag" for #1 we can have both. User's who like #2 juts hit the flag. Then the discussion changes to what we should implement first and I agree with Jorge + John that this should likely be #2.

IMO you're doing way too much and tending toward tight coupling which
will make the system brittle.

If you want to give the user orchestration, there is Heat. A template will
manage the sort of things that you want, such as automatic replacement
and dereferencing/deleting of older credentials. But not if your service
doesn't support having n+1 active credentials at one time.

More information about the OpenStack-dev mailing list