summaryrefslogtreecommitdiffstats
path: root/firstboot/userdata_example.yaml
diff options
context:
space:
mode:
authorZane Bitter <zbitter@redhat.com>2016-02-02 12:32:37 -0500
committerZane Bitter <zbitter@redhat.com>2016-02-24 11:18:46 -0500
commitd0dcb9401c868786df58f5801a431392b8e89df8 (patch)
tree83fec52e89484ccede04c89e3a2b228c6b62fa83 /firstboot/userdata_example.yaml
parent9e473e4b54197811ede59b07bfb3d0e79475e2e1 (diff)
Generate the endpoint map statically
A stack is an extremely heavyweight abstraction in Heat. Particularly in TripleO, every stack includes a copy of all the template and environment data for all of the stacks in the tree, all of which must be stored anew in the database. The EndpointMap abstraction created no fewer than 30 nested stacks, none of which contained any resources but which existed purely for the purpose of abstracting out some intrinsic functions used to calculate the endpoint URLs for the various services. This likely adds several GB to the memory requirements of the undercloud, and can cause things to slow to a crawl since all 30 nested stacks need to be queried whenever we need data from any one of them. This change eliminates the nested stacks and instead generates the endpoint map statically. This can be done offline in less than 250ms, allows the input data to be expressed in an even more human-readable form, and reduces the runtime overhead of the endpoints map by a factor of 31, all with no loss of functionality, compatibility or flexibility. Since we don't run a setup script to generate the tarball, the endpoint_map.yaml output is checked in to source control. The build script offers a --check option that can be used to make sure that the output file is up-to-date with the input data. Change-Id: I2df8f5569d81c1bde417ff5b12b06b7f1e19c336
Diffstat (limited to 'firstboot/userdata_example.yaml')
0 files changed, 0 insertions, 0 deletions