The management network is used extensively for all internal
communication.
Since the original use of the network was a private network before
it was exposed for external communication in a distributed cloud
configuration, it was never designed to be reconfigured.
To support MGMT network reconfiguration the idea is to configure the
applications to use the hostname/FQDN instead of a static MGMT IP
address.
In this way the MGMT network can be changed and the services and
applications will still work since they are using the hostname/FQDN
and the DNS will be responsible to translate to the current MGMT
IP address.
The use of FQDN will be applied for all installation modes: AIO-SX,
AIO-DX, Standard, AIO-PLUS and DC subclouds. But given the
complexities of supporting the multi-host reconfiguration,
the MGMT network reconfiguration will focus on support for AIO-SX
only.
The DNSMASQ service must start as soon as possible to translate
the FQDN to IP address.
Test plan ( Debian only )
- AIO-SX and AIO-DX virtualbox installation IPv4/IPv6
- Standard virtualbox installation IPv6
- DC virtualbox installation IPv4 ( AIO-SX/DX subclouds )
- AIO-SX and AIO-DX installation IPv4/IPv6
- AIO-DX plus installation IPv6
- DC IPv6 and subcloud AIO-SX
- AIO-DX host-swact
- DC IPv4 virtualbox with subcloud AIO-DX and AIO-DX
- AIO-SX to AIO-DX migration
- netstat -tupl ( no services are using the MGMT IP address )
- Ran sanity/regression tests
- Backup and Restore for AIO-SX/AIO-DX
Story: 2010722
Task: 48241
Change-Id: If340354755ec401dac1b0da2c93e278e390f81a9
Signed-off-by: Fabiano Correa Mercer <fabiano.correamercer@windriver.com>
Because the management network and its parameters are
embedded in many parts of the system, having a separate
admin network makes it much easier to change the parameters
of this network (subnet, gateway, etc) after a subcloud has
been provisioned.
The admin network will take precedence over the existing
management network for communication between the
subcloud and system controller if it is defined.
The management network will still exist on the subcloud, but
will be a private network.
This commit contains logic to choose the most appropriate
keystone auth url and admin endpoint required for subcloud
administration depending on whether the admin network is
present or not.
Note: Corresponding puppet review:
https://review.opendev.org/c/starlingx/stx-puppet/+/865288
Test Plan:
- Bootstrap and install DC subcloud with admin network defined.
PASS: Ensure the openstack admin endpoints on both the subcloud
and system controller for the affected services use the
admin subnet of the subcloud
PASS: Ensure the subcloud can become online and in-sync using
the admin network.
Regression:
- AIO-SX: On a non-DC system, ensure the openstack endpoints for
the various services are not impacted by the change.
- Bootstrap and install DC subcloud with no admin network defined.
PASS: Ensure the openstack admin endpoints on both the subcloud
and system controller for the affected services use the
management subnet of the subcloud (no impact)
PASS: Ensure the subcloud can become online and in-sync with the
management network (no impact).
Depends-On: https://review.opendev.org/c/starlingx/config/+/863033
Story: 2010319
Task: 46910
Signed-off-by: Steven Webster <steven.webster@windriver.com>
Change-Id: Icf4c7c97ed69c74e6827c63614cb44abca28e38a
This commit updated platform services' sysinv puppet plugins to
generate proper admin_url hiera data to enable https for these endpoints
during controller unlock.
This commit also updated controller_config to copy and install dc admin
endpoint CA cert and haproxy cert for the second controller.
Change-Id: I21345a96f8a0ffb416069ff28dbcfa51b9e12359
Story: 2007347
Task: 39314
Signed-off-by: Andy Ning <andy.ning@windriver.com>
During DC System Controller deployment, the ansible script
intermittently fails during the barbican credential creation
on ansible re-play. Even in the re-play case, it is a random
failure depending on the order of the endpoints in the service
catalog.
The reason for this to happen is that, during the initial play, the
barbican secrets are created prior to initial system configuration
population so endpoints for SystemController region are not created.
Barbican will use the RegionOne keystone endpoint. But after initial
play finished, endpoints for SystemController region are created thus
there are two keystone endpoints (RegionOne and SystemController).
With two region keystone endpoints during re-play, Barbican may pickup
SystemController region keystone endpoint during credential creation.
Yet the service for SystemController region (dcorch identity proxy) has
not started, causing the credential creation to fail.
The fix is to explicitly configure Barbican region_name to RegionOne
during bootstrap so re-play will use RegionOne keystone endpoint. Then
update Barbican region_name after service endpoints reconfiguration to
make region_name consistent with keystone service catalog, so requests
to Barbican will always succeed.
Change-Id: I7afda2806aad6437f746ca8ff39adee2d29571cf
Closes-Bug: 1859726
Signed-off-by: Andy Ning <andy.ning@windriver.com>
Replacing existing mechanism of storing BMC passwords in SysInv.
Implementing access to Barbican API in SysInv and using it to write
the passwords into a Barbican secrets. Note that a Barbican cannot
change the existing password inside its secret, so we need to remove
the old secret and create a new one in case of password update.
Another thing to mention: SysInv has to create Barbican secrets in
context of "services" project in order MTCE can read them later.
Change-Id: I7102a9662f3757c062ab310737f4ba08379d0100
Story: 2003108
Task: 27700
Signed-off-by: Alex Kozyrev <alex.kozyrev@windriver.com>
Barbican service is needed during bootstrap phase for StarlingX.
Implement bootstrap and runtime manifests to achieve that.
Change-Id: I6c22ebddacf8aec3a731f7f6d7a762f79f511c78
Story: 2003108
Task: 27700
Signed-off-by: Alex Kozyrev <alex.kozyrev@windriver.com>
1. Add the new barbican DB and barbican user.
2. Support DB backup/restore and upgrades for barbican.
3. Configure barbican user and password in region config.
4. Provide Barbican configuration with appropriate data via SysInv.
5. Setup Barbican thru puppet manifests.
There are three main services that need to be configured:
- Barbican API: a RESTful API for managing secrets.
- Barbican Worker: a RPC interface for Barbican API.
- Barbican Keystone Listener: a service for Keystone changes.
Also, HA Proxy and Firewall need to be updated with Barbican port (9311)
as well as Remote Logging manifest to allow Barbican log collection.
Change-Id: I6b0b0c90456627bebde2b834b339bc968100b6f9
Story: 2003108
Task: 27700
Depends-On: I2667d56a71b7d3881c03b6a5c1e5ed61d4f0b902
Signed-off-by: Alex Kozyrev <alex.kozyrev@windriver.com>
Fabiano Correa Mercer