Description of problem: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/deploy_fernet_on_the_overcloud/sec-fernet Deployment of RHOSP 10 will fail if these directions are followed. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. $ . ~/stackrc 2. sudo keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone 3. sudo tar -zcf keystone-fernet-keys.tar.gz /etc/keystone/fernet-keys 4. upload-swift-artifacts -f keystone-fernet-keys.tar.gz 5. create fernet.yaml with the following contents: parameter_defaults: controllerExtraConfig: keystone::token_provider: 'fernet' 6. openstack overcloud deploy --templates -e fernet.yaml Actual results: 2017-03-01 21:10:54Z [overcloud]: CREATE_FAILED Resource CREATE failed: resources.AllNodesDeploySteps: Property error: resources.CephStorageArtifactsC onfig.properties: Property DeployArtifactURLs not assigned 2017-03-01 21:10:55Z [overcloud.ControllerAllNodesValidationDeployment.0]: CREATE_IN_PROGRESS state changed 2017-03-01 21:10:55Z [overcloud.ControllerAllNodesValidationDeployment.2]: CREATE_IN_PROGRESS state changed Stack overcloud CREATE_FAILED Expected results: Successful overcloud deploy Additional info: Step no 1.1.3 uses the upload-swift-artifacts script to upload keystone-fernet-keys.tar.gz into swift on the undercloud as the overcloud-artifacts/keystone-fernet-key.tar.gz object. This script also creates a deployment-artifacts.yaml file that needs to be included in the in the 'openstack overcloud deploy --templates e fernet.yaml' command. Deployment fails because the artifact exists but the deployment has no reference to it, that needs to be provided as a url in deployment-artifacts.yaml. Even taking '--templates -e fernet.yaml' out of the command will cause the deployment to fail because that object exists in swift but the deploy command has no swift url for it. Additionally, this document should reference $HOME/templates as most of the other documentation does. My workaround below uses this. The upload-swift-artifacts script silently creates deployment-artifacts.yaml in $HOME/.tripleo/environments - the workaround here is this: $ cp $HOME/.tripleo/environments/deployment-artifacts.yaml to $HOME/templates/environments $ openstack overcloud deploy --templates -e $HOME/templates/environments/fernet.yaml -e $HOME/templates/environments/overcloud-artifacts.yaml This will produce a successful deployment with ferent tokens enabled on the overcloud. Note also that upload-swift-artifacts can take a --environment switch to have the deployment-artifacts.yaml placed in a more RHOSP friendly environment -- e.g. /home/stack/templates
I have reviewed the case and the issue is with the customers templates. They are using DeployArtifactURLs in their zenoss_ceilometer.yaml template. This is overriding the DeployArtifactURLs being generated when the use upload-swift-artifacts to manage the fernet keys. The recommended solution would be to drop the DeployArtifactURLs from zenoss_ceilometer.yaml and use virt-customize[0] to install this rpm on the overcloud-full images prior to deployment. This would fee up the DeployArtifactURLs parameter for use with upload-swift-artifacts. If they do not wish to use virt-customize, they customer would need to manually merge the two DeployArtifactURLs together for both to work. I highly recommend using virt-customize to ensure that the zenoss rpm is installed prior to deployment than using DeployArtifactURLs in this case. [0] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/partner_integration/overcloud_images#qcow_installing_rpms