| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This adjusts the interface to OS::TripleO::AllNodesExtraConfig so
it supports custom/composable/optional roles.
Note this does break backwards compatibility, and I can't see any way
to avoid that. I've converted the in-tree templates, and we'll have
to document carefully and or provide a script (or automated conversion
via mistral perhaps?) to allow folks to easily adjust any out of tree
templates to the new format.
Basically you just have to:
1. Remove all the *_servers parameters, replace with one "servers"
json parameter
2. Replace references to e.g "controller_servers" with "servers, Controller"
which does a path-based lookup into the json map provided by overcloud.yaml
Change-Id: I5eebf853646b2f6300d6b542fcd4f43e82d3b413
Partially-Implements: blueprint custom-roles
|
|
Since https://review.openstack.org/#/c/315616 this is no longer
required.
Change-Id: I0452d1577a25d19b4351bfe7830a6c7bbe485e67
|
|
Due to fix: https://bugs.launchpad.net/networking-cisco/+bug/1469839,
the replay count parameter is no longer used. This needs to be
reflected in the Triple O templates.
Change-Id: I666c4394108287adcb4989e897ab3936667a602b
Closes-bug: #1551387
|
|
There are two reasons the name property should always be set for deployment
resources:
- The name often shows up in logs, files and API calls, the default
derived name is long and unhelpful
- Sorting by name determines the merge order of os-apply-config, and the
execution order of puppet/shell scripts (note this is different to
resource dependency order) so leaving the default name results in an
undetermined order which could lead to unpredictable deployment of
configs
This change simply sets the name to the resource name, but a future change
should prepend each name with a run-parts style 2 digit prefix so that the
order is explicitly stated. Documentation for extraconfig needs to clearly
state what prefix is needed to override which merge/execution order.
For existing overcloud stacks, heat currently replaces deployment resources
when the name changes, so this change
Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9
Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
|
|
Due to a limitation in the puppet version used in RHEL7 there is no simple
way to scope a 2nd level hiera hash key with the create_resources + defined
types pattern. Lack of the .each method support prior to puppet 4.0 is the
problem here. This template change works around the problem by explicitly
adding the hostname to the hieradata for a server under a nexus switch.
The duplicate server names under different switches is needed for vPC
config scenarios.
Closes-bug: #1506546
Change-Id: I03b866fb440e968c9f86ae93942b687e7165a065
|
|
The collection of hostname to MAC mappings done in AllNodesPostDeploy
uses 'hostname -f' to get the FQDN for each node. This form
of the command causes a nameserver lookup for the domain name. A
timing issue has been seen where the hostname lookup fails due to
the nameserver not having the mapping yet. The solution is to
hardcode the domain to 'localdomain' as is done in a few other
patches--ie. see controller-puppet.yaml.
Change-Id: Ibea50fcc6b9f22ca163ff063e0dc9ca69dff5f34
|
|
The puppet-neutron changes to remove the usage of ERB templates require
changing the format of the 'servers' hash/dictionary to include a key
for use with puppet's create_resources directly from hiera data.
Depends-On: I401371c9e5176de7ce19d4d4e878e9f2e69aab80
Change-Id: I950b7fb019dd8dd072592618b968a19df5c9c884
|
|
Switch the implemention from a pre_deploy ExtraConfig to an
AllNodesExtraConfig, so we can collect the mac->hostname mapping
for all nodes, then calculate a NexusConfig based on that and
a provided mapping of switch ports to mac address.
The same conversion is also done to the NetworkUCSMHostList:
The port mappings are provided via parameter_defaults like:
parameter_defaults:
NetworkNexusConfig: {
"bxb-tor-1": {
"username": "admin",
"ssh_port": 22,
"password": "lab",
"ip_address": "10.86.7.204",
"nve_src_intf": 0,
"physnet": "datacentre",
"servers": {
"fa:16:3e:fa:be:ef": "1/11",
"fa:16:3e:fa:5e:cf": "1/23",
"fa:16:3e:fa:12:34": "2/34"
}
}
}
NetworkUCSMHostList: 'fa:16:3e:fa:be:ef:profile1'
This results in an entry like this appended to
/etc/puppet/hieradata/neutron_cisco_data.yaml:
neutron::plugins::ml2::cisco::nexus::nexus_config:\
{"bxb-tor-1": {"username": "admin", "nve_src_intf": 0, "ssh_port": 22,
"servers": {"overcloud-compute02": "2/34", "overcloud-compute01": "1/23",
"overcloud-control01": "1/11"}, "password": "lab", "ip_address": "10.86.7.204",
"physnet": "datacentre"}}
neutron::plugins::ml2::cisco::ucsm::ucsm_host_list: overcloud-control01:profile1
Co-Authored-By: Rob Pothier <rpothier@cisco.com>
Co-Authored-By: Tim Swanson <tiswanso@cisco.com>
Change-Id: I372c3ffb6bd85b7239fcb9f3fc4fa51cd4a39332
|
Steven Hardy
Leon Zachery
Steve Baker
tiswanso