summaryrefslogtreecommitdiffstats
path: root/extraconfig/pre_network
AgeCommit message (Collapse)AuthorFilesLines
2017-07-25Contrail network realignement + DPDK enablementMichael Henkel2-0/+330
This patch moves Contrail roles communication from public/external to internal_api network for OpenStack API. It also adds the option to enable dpdk. Monolithic firstboot script is broken down into small pre-network and per-node extraconfig scripts Change-Id: I296a3bf60cef6fa950fd71d6e68effe367d1e66b Closes-Bug: 1698422
2017-07-14Add a new role for ComputeOvsDpdk and clean-up parametersSaravanan KR1-31/+11
A new role ComputeOvsDpdk has been added to avoid manual roles_data creation. And cleaned-up the DPDK parameters inline with the refactored code. Change-Id: I16dac69609c98194c2504ff067258fa14363d4f1
2017-07-13Merge "Added OvS permission workaround for enabling DPDK"Jenkins1-0/+26
2017-07-10Revert "Revert "Blacklist support for ExtraConfig""James Slagle3-5/+65
There is a Heat patch posted (via Depends-On) that resolves the issue that caused this to be reverted. This reverts the revert and we need to make sure all the upgrades jobs pass before we merge this patch. This reverts commit 69936229f4def703cd44ab164d8d1989c9fa37cb. Closes-Bug: #1699463 implements blueprint disable-deployments Change-Id: Iedf680fddfbfc020d301bec8837a0cb98d481eb5
2017-07-10Added OvS permission workaround for enabling DPDKSaravanan KR1-0/+26
The vhost sockets sockets are created with qemu permission, but ovs runs with root permission. In order to allow ovs to access vhost sockets reducing the ovs group permission from root to qemu. This is a temprovary workaround, until ovs fixes the permission issue. The script supports both ovs2.6 and ovs2.7 versions. Change-Id: I172956390c19fc9824bf7590cd48bfcf6201191b
2017-06-23Adds service for OVS and enables ODL DPDK deploymentsTim Rozet2-22/+90
In order to deploy OpenDaylight with DPDK we need to copy the DPDK config for OVS done in the neutron-ovs-dpdk service template, without enabling OVS agent for compute nodes. To do this correctly, we should inherit and openvswitch service which is a common place to set OVS configuration and parameters. Note: vswitch::dpdk config will be called in prenetwork setup with ovs_dpdk_config.yaml so there is no need to include that in the step config for neutron-ovs-dpdk-agent service or opendaylight-ovs-dpdk. Changes Include: - Creates a common openvswitch service template, which in the future will migrate to be its own service. - Renames and fixes OVS DPDK configuration heat parameters in the openvswitch template. - neutron-ovs-dpdk-agent now inherits the common openvswitch template. - Adds opendaylight-ovs-dpdk template which also inherits common ovs template. - Uses OVS DPDK config script to allow configuring OVS DPDK in prenetwork config (before os-net-config runs). This has an issue where hieradata is not present yet, so we have to redefine the heat parameters and pass them via bash. In the future this should be corrected. - Adds opendaylight-dpdk environment file used to deploy an ODL + DPDK deployment. - Updates neutron-ovs-dpdk environment file. Closes-Bug: 1656097 Partial-Bug: 1656096 Depends-On: I3227189691df85f265cf84bd4115d8d4c9f979f3 Change-Id: Ie80e38c2a9605d85cdf867a31b6888bfcae69e29 Signed-off-by: Tim Rozet <trozet@redhat.com>
2017-06-23Enable DPDK on boot using PreNetworkConfigSaravanan KR1-2/+95
DPDK has to be enabled on openvswitch on the boot before configuring the network as when the network uses DPDK ports OvS should be ready to handle DPDK. Enabled DPDK via PreNetworkConfig by checking if ServiceNames contains DPDK service. Implements: blueprint ovs-2-6-dpdk Closes-Bug: #1654975 Depends-On: I83a540336c01a696780621fb2b39486a6abf0917 Change-Id: I7af4534d91e67c94ba559b78b9ac6a001e639db3
2017-06-22Revert "Blacklist support for ExtraConfig"Alex Schultz3-65/+5
This reverts commit d6c0979eb3de79b8c3a79ea5798498f0241eb32d. This seems to be causing issues in Heat in upgrades. Change-Id: I379fb2133358ba9c3c989c98a2dd399ad064f706 Related-Bug: #1699463
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