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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
