summaryrefslogtreecommitdiffstats
path: root/puppet
AgeCommit message (Collapse)AuthorFilesLines
2017-08-18Let mds create manila key and fsJan Provaznik6-13/+48
ceph-ansible will take care of setting up client keys both in ceph and on client side. It will also create filesystem for manila. To assure that manila manifest can work in future both with puppet and with ceph-ansible, creation of filesystem is moved to ceph-mds manifest and creation of manila key on ceph side is moved to ceph-base (so manila key is always created), manila key is added to ceph-external for external ceph deployments. Key creation is removed from manila.pp in patch I2b5567a39ac8737e80758b705818cc1807dc8bf1 Change-Id: I6308a317ffe0af244396aba5197c85e273e69f68 Related-To: Ia3ef9e9a2b159dacea01e38762145ff2bcc7ba27 Depends-On: I3f18bbe476c4f43fa4e162cc66c5df443122cd0c
2017-08-18Merge "Make cinder-manage db sync run on only one controller during upgrade"Jenkins1-7/+13
2017-08-16Merge "Add NeutronOverlayIPVersion parameter to neutron-plugins-ml2 service"Jenkins1-0/+7
2017-08-15Add NeutronOverlayIPVersion parameter to neutron-plugins-ml2 serviceFeng Pan1-0/+7
This patch adds NeutronOverlayIPVersion parameter to congfigure neutron ML2 overlay_ip_version option from T-H-T. puppet-neutron already has support for configuration of this option, we are just exposing it from T-H-T. This parameter needs to be set to '6' when IPv6 vxlan tunnel endpoints are desired. Closes-Bug: #1691213 Change-Id: I056afa25f67a3b6857bdfef14e6d582b0a9e5e93 Signed-off-by: Feng Pan <fpan@redhat.com>
2017-08-15Convert network templates to be rendered via j2Steven Hardy1-2/+2
Use the network.network.j2.yaml to render these files, instead of relying on the hard-coded versions. Note this doesn't currently consider the _v6 templates as we may want to deprecate these and instead rely on an ipv6 specific network_data file, or perhaps make the network/network.network.j2.yaml generic and able to detect the version from the cidr? Change-Id: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a Partially-Implements: blueprint composable-networks
2017-08-14Merge "Make HA container bundle work on remote nodes"Jenkins1-0/+13
2017-08-14Merge "Convert cephstorage-role.yaml to role.role.j2.yaml"Jenkins1-718/+0
2017-08-13Merge "Add support for update_tasks"Jenkins2-1/+17
2017-08-12Merge "Convert blockstorage-role.yaml to role.role.j2.yaml"Jenkins1-704/+0
2017-08-12Merge "Convert objectstorage-role.yaml to role.role.j2.yaml"Jenkins1-703/+0
2017-08-12Add support for update_tasksSteven Hardy2-1/+17
These work the same way as upgrade_tasks *but* they use a step variable instead of tags, so we can iterate over a count/sequence which isn't possibly via a wrapper playbook with tags (we may want to align upgrade tasks with the same approach if this works out well). Note the tasks can be run via ansible-playbook on the undercloud, like: openstack overcloud config download --config-dir tmpconfig cd tmpconfig/tripleo-HCrDA6-config ansible-playbook -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit controller The above will do a rolling update for the Controller role (note the inconsistent capitalization, we probably need to fix the group naming in tripleo-ansible-inventory) because we specify serial: 1 in the playbook. You can also trigger an update explicitly on one node like this, which is useful for debugging: ansible-playbook -vvv -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit overcloud-controller-0 Change-Id: I20bb3e26ab9d9cadf1a31fd304de8a014a901aa9
2017-08-12Merge "Consolidate puppet/docker deployments with one deploy steps workflow"Jenkins4-442/+0
2017-08-12Merge "Convert compute-role.yaml to role.role.j2.yaml"Jenkins2-747/+27
2017-08-12Merge "Convert controller-role.yaml to role.role.j2.yaml"Jenkins2-856/+136
2017-08-11Consolidate puppet/docker deployments with one deploy steps workflowSteven Hardy4-442/+0
If we consolidate these we can focus on one implementation (the new ansible based one used for docker-steps) Change-Id: Iec0ad2278d62040bf03613fc9556b199c6a80546 Depends-On: Ifa2afa915e0fee368fb2506c02de75bf5efe82d5
2017-08-11Convert cephstorage-role.yaml to role.role.j2.yamlSteven Hardy1-718/+0
Add some special-casing for backwards compatibility, such that the CephStorage role can be rendered via j2 for support of composable networks. Change-Id: Iee92bb6ee94963717d3a8ef400e7970f62576a0d Partially-Implements: blueprint composable-networks
2017-08-11Convert blockstorage-role.yaml to role.role.j2.yamlSteven Hardy1-704/+0
Add some special-casing for backwards compatibility, such that the BlockStorage role can be rendered via j2 for support of composable networks. Change-Id: Ia5fb5ff6dbe218710e95a69583ac289cf7b4af9e Partially-Implements: blueprint composable-networks
2017-08-11Convert objectstorage-role.yaml to role.role.j2.yamlSteven Hardy1-703/+0
Add some special-casing for backwards compatibility, such that the ObjectStorage role can be rendered via j2 for support of composable networks. Change-Id: I52abbefe2f5035059ccbed925990faab020c6c89 Partially-Implements: blueprint composable-networks
2017-08-11Convert compute-role.yaml to role.role.j2.yamlSteven Hardy2-747/+27
Add some special-casing for backwards compatibility, such that the Compute role can be rendered via j2 for support of composable networks. Change-Id: Ieee446583f77bb9423609d444c576788cf930121 Partially-Implements: blueprint composable-networks
2017-08-11Convert controller-role.yaml to role.role.j2.yamlSteven Hardy2-856/+136
Add deprecated role-specific parameters to role definition, in order to special-case some parameters for backwards compatibility, such that the Controller role can be rendered via j2 for support of composable networks. Co-Authored By: Dan Sneddon <dsneddon@redhat.com> Change-Id: I5983f03ae1b7f0b6add793914540b8ca405f9b2b Partially-Implements: blueprint composable-networks
2017-08-11TLS everywhere: Configure CA for mongodbJuan Antonio Osorio Robles1-0/+6
It wasn't being configured, thus making mongodb fail. Change-Id: If0d7513aacfa74493a9747440fb97f915a77db84 Closes-Bug: #1710162
2017-08-11Merge "Move HAProxy's public TLS logic from controller to service template"Jenkins4-6/+25
2017-08-11Merge "Set virsh secret with an init step when using Ceph"Jenkins2-0/+10
2017-08-11Move HAProxy's public TLS logic from controller to service templateJuan Antonio Osorio Robles4-6/+25
This de-couples public TLS from controllers to now run wherever HAProxy is deployed. Partially-Implements: blueprint composable-networks Change-Id: I9e84a25a363899acf103015527787bdd8248949f
2017-08-10Merge "Create parameters for haproxy TLS certs and keys"Jenkins2-11/+55
2017-08-09Merge "Addition of Nuage as mechanism driver for ML2"Jenkins3-0/+111
2017-08-09Set virsh secret with an init step when using CephGiulio Fidente2-0/+10
Run virsh secret-define and secret-set-value in an init step instead of relying on the puppet-nova exec. Co-Authored-By: Jiri Stransky <jistr@redhat.com> Change-Id: Ic950e290af1c66d34b40791defbdf4f8afaa11da Closes-Bug: #1709583
2017-08-08Make HA container bundle work on remote nodesMichele Baldessari1-0/+13
Right now when we deploy an HA bundle on a pacemaker remote node, the deploy will fail due to the fact that the bundle includes tripleo::profile::base::pacemaker which makes a call to hiera('hacluster_pwd') which will fail on pcmk remote nodes. While we could noop the profile on pcmk nodes, it's much simpler to just make sure this hiera key exists on pcmk remote nodes. Also make sure that pacemaker::corosync::manage_fw is set to false on remote nodes, otherwise the mere inclusion of the pacemaker profile will cause iptables-save to run in a container and thus failing. Change-Id: I09b3e54a470cc2d600a701d23463962501c5c9d6
2017-08-08Make cinder-manage db sync run on only one controller during upgradeSofer Athlan-Guyot1-7/+13
We got to ensure that the cinder-manage db sync is run on only one controller. Change-Id: I88a6aa4c49d893b95a26795fbfcf163a780fd0bc Closes-Bug: #1709315
2017-08-07Create parameters for haproxy TLS certs and keysJuan Antonio Osorio Robles2-11/+55
this removes the hardcoded paths for the haproxy certs and keys and will enable re-use. We'll use this in a further commit in the containterized TLS work. Change-Id: I602e5a569e2e7e60835deb80532abcedd7a1f63d
2017-08-07Use number for KeystoneCronTokenFlushMaxDelay instead of stringJuan Antonio Osorio Robles1-2/+2
Using a string results in an erroneous check in puppet-keystone, which sets up a zero where it shouldn't. So we change it to number to avoid that. Note that there will also be a puppet-keystone fix for this. Changing the value here assures that deployers only give valid values to this parameter. Change-Id: I00823e23358df91ce54f421c12636f05d4196e15 Closes-Bug: #1708584
2017-08-05Merge "Start redis service after upgrade"Jenkins1-0/+3
2017-08-04Change the directory for haproxy certs/keys to be service-specificJuan Antonio Osorio Robles2-7/+11
This moves the directories containing the certs/keys for haproxy one step further inside the hierarchy. This way we will be able to bind-mount this certificate into the container without bind-mounting any other certs/keys from other services. bp tls-via-certmonger-containers Depends-On: Iba3adb9464a755e67c6f87d1233b3affa8be565a Change-Id: I73df8d442b361cb5ef4e343b4ea2a198a5b95da9
2017-08-04Merge "Changing the default port-binding configuration"Jenkins2-2/+46
2017-08-03Update EventPipelinePublisher param description to include zaqarPradeep Kilambi1-0/+2
Since we now support zaqar:// publisher, Enhance the description to indicate how to set the zaqar publisher. Change-Id: Ib7eba98d199fade2346620672e33b74686d4685b
2017-08-03Merge "Make UpgradeLevelNovaCompute parameters consistent"Jenkins2-2/+2
2017-08-03Addition of Nuage as mechanism driver for ML2lokesh-jain3-0/+111
Adding composable services for Nuage mechanism driver for ML2. This is separate from Nuage as the core plugin and intentional duplication of Nuage under puppet services. Parameters required for working of Nuage as mechanism driver are also added. Change-Id: I2b564610721152c4f4dab9da79442256ba8d0b33
2017-08-03Merge "Make many networking parameters consistent"Jenkins5-8/+7
2017-08-03Merge "Make RoleParameters and key_name descriptions consistent"Jenkins6-6/+6
2017-08-03Merge "Set redis password hiera value in compute agent"Jenkins1-0/+5
2017-08-02Make UpgradeLevelNovaCompute parameters consistentBen Nemec2-2/+2
There is logic in nova-base.yaml that depends on the default for this parameter being '', and the nova-compute service only needs it set to auto during upgrade. That will be done by [1] anyway, so it doesn't matter what the default is. It's also not clear to me that the nova-compute task is even needed now that we're post-Ocata, but that's not a change I feel comfortable making. 1: https://github.com/openstack/tripleo-heat-templates/blob/master/environments/major-upgrade-composable-steps.yaml Change-Id: Iccfcb5b68e406db1b942375803cfedbb929b4307 Partial-Bug: 1700664
2017-08-02Make many networking parameters consistentBen Nemec5-8/+7
These are mostly the low hanging fruit that only required a few minor changes to fix. There are more that require a lot of changes or might be more controversial that will be done later. Change-Id: I55cebc92ef37a3bb167f5fae0debe77339395e62 Partial-Bug: 1700664
2017-08-02Make RoleParameters and key_name descriptions consistentBen Nemec6-6/+6
The key_name default is ignored because the parameter is used in some mutually exclusive environments where the default doesn't need to be the same. Change-Id: I77c1a1159fae38d03b0e59b80ae6bee491d734d7 Partial-Bug: 1700664
2017-08-02Start redis service after upgradePradeep Kilambi1-0/+3
We install redis if its not already there, but we should also ensure redis service is started in the next step 4. related to issues we're seeing in I284de61bbefac9e9b37390650016643ffe38b5cc Change-Id: Ic01db53ea8669f14e87f6987045b2be5a3480024
2017-08-02Merge "Fix iscsid role data's section"Jenkins1-1/+1
2017-08-01Set redis password hiera value in compute agentPradeep Kilambi1-0/+5
Without this config defaults to undef in containers Change-Id: Id47f365364e7b0d399de92995871b136550cd625
2017-07-31Merge "Add 'ovn-controller' service"Jenkins2-4/+32
2017-07-28Merge "Enable Zaqar API SSL"Jenkins1-1/+3
2017-07-27Changing the default port-binding configurationItzik Brown2-2/+46
networking-odl no longer supports the network-topology port binding controller and instead now relies on a pseudo-agent binding controller. This means that each OVS node must be configured with host configuration in OVSDB about which VIF types, network types, functions, etc that this OVS node supports. The end result is this affects where nova and neutron will schedule instances. Changes Include: - Modifying default port binding controller to use pseudo agent - Adds necessary per role parameters to be able to configure host config on a per role basis to allow for heterogenous compute node configurations. Change-Id: I50458abf6a8a6bf724ad97accb6444d9c497d287 Closes-Bug: 1674995 Signed-off-by: Tim Rozet <trozet@redhat.com>
2017-07-27Add 'ovn-controller' serviceNuman Siddique2-4/+32
Presently the ovn-controller service (puppet/services/neutron-compute-plugin-ovn.yaml) is started only on compute nodes. But for the cases where the controller nodes provide the north/south traffic, we need ovn-controller service runninng in controller nodes as well. This patch - Renames the neutron-compute-plugin-ovn.yaml to ovn-controller.yaml which makes more sense and sets the service name as 'ovn-controller'. - Adds the service 'ovn-controller' to Controller and Compute roles. - Adds the missing 'upgrade_tasks' section in ovn-dbs.yaml and ovn-controller.yaml Depends-On: Ie3f09dc70a582f3d14de093043e232820f837bc3 Depends-On: Ide11569d81f5f28bafccc168b624be505174fc53 Change-Id: Ib7747406213d18fd65b86820c1f86ee7c39f7cf5