summaryrefslogtreecommitdiffstats
path: root/extraconfig/pre_network
AgeCommit message (Collapse)AuthorFilesLines
2017-06-16Blacklist support for ExtraConfigJames Slagle3-5/+65
Commit I46941e54a476c7cc8645cd1aff391c9c6c5434de added support for blacklisting servers from triggered Heat deployments. This commit adds that functionality to the remaining Deployments in tripleo-heat-templates for the ExtraConfig interfaces. Since we can not (should not) change the interface to ExtraConfig, Heat conditions are used on the actual <role>ExtraConfigPre and NodeExtraConfig resources instead of using the actions approach on Deployments. Change-Id: I38fdb50d1d966a6c3651980c52298317fa3bece4
2017-06-13Modify PreNetworkConfig config inline with role-specific parametersSaravanan KR3-4/+99
Existing host_config_and_reboot.role.j2.yaml is done in ocata to configure kernel args. This can be enhanced with use of role-specific parameters, which is done in the current patch. The earlier method is deprecated and will be removed in Q releae. Implements: blueprint ovs-2-6-dpdk Change-Id: Ib864f065527167a49a0f60812d7ad4ad12c836d1
2017-05-19Update the template_version alias for all the templates to pike.Carlos Camacho2-2/+2
Master is now the development branch for pike changing the release alias name. Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
2017-01-17Bump missing template names to ocataCarlos Camacho2-2/+2
Update pending templates to use the release name alias. Change-Id: I39f9be212d3e9f3bec6f45d9757eca7a3b0ccc06
2017-01-06Configure Kernel Args and Tuned and then reboot for ComputeSaravanan KR2-0/+158
* On top of the https://review.openstack.org/#/c/411204 * Added Kernel args and Tune-d configuration * Added provision to provide different kernel args per role (applicable for different types of compute roles only) Implements: blueprint tuned-nfv-dpdk Change-Id: I5c538428c376c9d2ebd1c364f0ee8503fd7d620e
2016-12-15Add pre-network hook and example showing config-then-rebootSteven Hardy1-0/+48
There are some requirements for early configuration that involves e.g setting kernel parameters then rebooting. Currently this can be done via cloud-init, e.g firstboot templates, but there's been discussion around enabling a SoftwareDeployment approach instead. The main advantage of doing it this way is there's an error path if something goes wrong with the config (except triggering the reboot as we have to use NO_SIGNAL for that). Change-Id: Ia54ee654f755631b8062eb5c209a60c6f9161500