Please consider providing facts or functions in puppet-keystone

[Maik Zumstrull]

We have a few cases where we need the ID of a user or tenant, or an endpoint URL, generally "stuff from Keystone" to generate a configuration file. The openstack-puppet classes sometimes have this need as well (e.g. https://github.com/stackforge/puppet-heat/blob/master/lib/puppet/provider/heat_domain_id_setter/ruby.rb).

It would be convenient if puppet-keystone would ship with functions (and possibly some facts) to have this information retrieved automatically during the puppet run. That avoids storing information that could be derived in hiera files, or writing custom one-off providers to retrieve this information.

It's understood that this wouldn't necessarily solve all issues within a single puppet run due to ordering issues. Functions are evaluated strictly before resources, so you couldn't retrieve the ID of an object puppet will create within the same run. That's acceptable for our purposes.

[Richard Raseley (richard-raseley)]

Can you share some specific use-cases, as well as your current workarounds, which would be enabled by this functionality?

[Maik Zumstrull (m-zumstrull)]

A specific example is our object storage service, which needs to authenticate to Keystone using the UUID of a privileged account to retrieve S3-compatible credentials for users. The ideal situation would be:

- Puppet installs the software
- Puppet creates the privileged user
- Puppet configures the software with the credentials for that user
- Puppet launches the service

We currently have a break between the second and third steps, because the storage service needs the ID of the service account, which Puppet has no convenient way of knowing. So we put in a dummy ID, the first Puppet run creates the user and the service fails, we retrieve the ID and put it in the config, and future Puppet runs continue. Since this happens once per cluster, it's not the worst problem ever, but it is somewhat unclean.

It would work better with current code if the storage service could use a username instead of the ID, but it can't, and arguably that isn't a bug - stuff not meant for direct human intervention should be using unique IDs.