Red Hat Bugzilla – Bug 1301619
[Docs] [Director] Documentation does not include impacts of modifying Director template files.
Last modified: 2017-08-17 22:15:29 EDT
Description of problem: What are the impacts on specific parts of the system if a customer makes modifications to Director template files? (which modification implies a full redeployment, which are applicable live, etc.) No current user information about this in documentation - please assess and schedule. Version-Release number of selected component (if applicable): OSP 7 or 8 Expected results: docs to be updated with this information.
Assigning to Dan for review.
This is a copy/paste segment from an email I wrote to multiple people outlining a plan for this BZ: So Telefonica has asked about some documentation gaps regarding modifications to the Overcloud stack and impacts of certain modifications. There's two parts to this: 1. Telefonica had some confusion as to whether modifications to the stack occur live or whether you need to re-deploy. I said that the modifications do not happen live, but you have to modify your custom Heat template/environment files and re-run the same command from when you first deployed (openstack overcloud deploy). After running this command, the director (and more specifically Heat) performs an update on each stack resource. 2. Nicholas mentioned that there are certain impacts to performing the modifications and it would be good to document them. For example, some things can't be modified, like the network environment configuration, or else the stack update fails. Or certain caveats like you need to deploy one Ceph node in your initial deployment if you want to scale Ceph nodes. Item 1 can be addresses quite easily by me. I can document a general modification procedure in Chapter 7 of the director guide and let customers know that modifications require subsequent runs of "openstack overcloud deploy". Although some sections in Chapter 7 use this command (e.g. the Scaling instruction), I don't think we explicitly say this is how it works. I can add this pretty much immediately as a starting point. Item 2 is trickier and I might need some help from the Engineering team. What would be good is if we also had some general guidelines as to what can and can't modified. Things like networking, storage, hieradata, Portal registration details, etc, etc. This is kind of similar to an email Graeme Gillies raised for storage node scalability and having a table to show what was supported. So I think collating this info in similar list/table would the best approach and we can include this information with Item 1 (although if anyone has any other suggestions on how to approach this, please feel free to raise them)