Bug 1042191

Summary:	[RFE][heat]: A resource which generates random strings for passwords
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-heat	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ddomingo, markmc, sbaker, sdake, shardy, yeylon
Target Milestone:	ga	Keywords:	FutureFeature
Target Release:	5.0 (RHEL 7)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/heat/+spec/random-string-resource
Whiteboard:	upstream_milestone_icehouse-1 upstream_status_implemented upstream_definition_approved
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	This release adds a new Orchestration resource type called OS::Heat::RandomString. This resource type randomly generates a string that can be accessed via an attribute.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-22 19:08:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 21:19:19 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/heat/+spec/random-string-resource.

Description:

Orchestrated services often need passwords and secrets to be propagated to multiple servers and set in configuration files or admin tools.

Currently the only practical way of doing this is to define template parameters for passwords and specify the password value on stack create. This can become a burden for complex templates with many services. For example these tripleo examples ask the user to generate 13 random passwords to pass to stack-create:
http://docs.openstack.org/developer/tripleo-incubator/devtest.html

This blueprint suggests creating a resource type OS::Heat::RandomString which randomly generates a string that can be accessed via an attribute. Properties can be set to specify what kind of string to generate, but defaults would aim to generate a string which is appropriate for service and user passwords that heat templates typically configure.

The resource's string will be stored in resource data and will be persisted by heat for the lifecycle of the stack. A future modification could be to store the string on a key server like Barbican.

Specification URL (additional information):

None

Comment 2 Stephen Gordon 2014-01-23 20:47:50 UTC

Moving to POST based on upstream status (Implemented).