On Fri, Dec 25, 2015 at 07:04:19PM -0800, Preston L. Bannister wrote: > In the implementation of a instance backup service for OpenStack, on > restore I need to (re)create the restored instance in the original tenant. > Restores can be fired off by an administrator (not the original user), so > at instance-create time I have two main choices: > 1. Create the instance as the backup service. > 2. Create the instance as the original user. > Clearly (1) is workable (given the backup user has access to the tenant). > Keypairs are a bit of an issue, but solvable. > Also clearly (2) is better, but that requires a means to impersonate the > original user. Keystone trusts seem to be that means, but raises > additional questions. (Also the fact the current documentation for > Keystone is incomplete in this area does not raise the confidence level.) > 1. How far back is the Keystone OS-TRUST extension reliable? (Kilo? > Juno?)
Heat first started using trusts in Havana, and although there were a few bugs early in that process, IIRC things have been pretty much solid since Icehouse. https://blueprints.launchpad.net/heat/+spec/heat-trusts > 2. Do any OpenStack distributions omit the OS-TRUST extension? > A feature labelled as an "extension" poses a risk to the developer. :) Trusts have long been enabled by default in keystone: https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L2005 So, FWIW, my take on it is it's reasonable for other services to rely on them being enabled by default - heat has used trusts by default since Kilo: https://bugs.launchpad.net/heat/+bug/1286157 The mitigation for it being an extension in the Heat case, is we provide a config option to switch back to the old pre-trusts behavior, but we default to using trusts unless explicitly configured otherwise. HTH, Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
