Commit Graph

53 Commits

Author SHA1 Message Date
Li Zhu 00a3e50e71 Display prestage status and versions in subcloud list
The prestage release can be either the previous or current release for
a subcloud. Checking the prestage release individually on thousands of
subclouds is impractical. Therefore, a new column called "prestage
versions" is added to the output of the "dcmanager subcloud list'
command. Besides, decoupling prestage status from deploy status.

Test plan:
PASS: Successful subcloud prestage with specified 22.12 or 23.09
      release, and verified the correct "prestage versions" output of
      the "dcmanager subcloud list" command.
PASS: Successful prestage strategy with specified 22.12 or 23.09
      release, and verified the correct "prestage versions" output of
      the "dcmanager subcloud list".
PASS: Verified the "prestage status" at each prestage stage.
PASS: Verified that the 'deploy status' was updated to 'complete' after
      upgrading the system controller from version 22.12 to 23.09.
      This verification was performed specifically for those subclouds
      that had a 'prestage-complete' deploy status with the previous
      22.12 system controller. The new columns, "perstage status" and
      "prestage versions", were empty after upgrading.

Depends-on:
https://review.opendev.org/c/starlingx/ansible-playbooks/+/904546

Story: 2010611
Task: 49367

Change-Id: Ica65b1e2e8e44b96352e7d45439a2e7a9063f7c9
Signed-off-by: lzhu1 <li.zhu@windriver.com>
2024-01-26 14:09:19 -05:00
Zhang Rong(Jon) 827799658c Remove the require_audit_flag while checking remote SPG status
This commit removes the require_audit_flag from the peer group
audit conditional, preventing local subclouds from being
incorrectly set to secondary status when a non-primary site
comes online.

Additionally, it removes the "subcloud migrate" API, as the
"subcloud-peer-group migrate" can be re-executed to migrate a
single subcloud that failed to migrate in a previous attempt.

Test Plan:
PASS - Power off the primary site and migrate the subclouds to
       the non-primary site. Power on the primary site after the
       migration is complete, checking the subclouds' status on
       both sites. On the primary site, the subclouds should be
       secondary, and on the non-primary site, they should be
       managed and online.
PASS - With both the primary site and non-primary site online,
       migrate the subclouds away and back, verifying that
       the operation completes successfully.

Closes-Bug: 2049336
Depends-On: I793bee7d680d59a4d29a585c88c8c1689976ee1b

Change-Id: Ib702fcf318d01bd7bfa8a19ec2aee516f6089cb0
Signed-off-by: Zhang Rong(Jon) <rong.zhang@windriver.com>
2024-01-16 17:49:50 -03:00
Zuul 32065bcc68 Merge "Add 'subcloud deploy delete' command to dcmanager" 2024-01-09 13:59:44 +00:00
Swapna Gorre eeb70d47c2 Add 'subcloud deploy delete' command to dcmanager
This commit adds the subcloud deploy delete command to dcmanager.
It is used to delete deploy files under /opt/platform/deploy.

Test Cases:

1) PASS: dcmanager subcloud deploy delete with no release
2) PASS: dcmanager subcloud deploy delete --release 23.09
3) PASS: dcmanager subcloud deploy delete --release 22.12
4) PASS: dcmanager subcloud deploy delete --release 21.12
         fails using the load 23.09 we support n-1.
5) PASS: dcmanager subcloud deploy delete --prestage-image
6) PASS: dcmanager subcloud deploy delete --deployment-files
7) PASS: dcmanager subcloud deploy delete fails when
	 deploy files doesn't exist already.

Story: 2010718
Task: 49190

Change-Id: I94d629009b185f67e3da45d010a6492b9b6d6f17
Signed-off-by: Swapna Gorre <swapna.gorre@windriver.com>
2024-01-09 03:51:31 -05:00
Zhang Rong(Jon) e422731760 Fix unable to determine the SPG sync state if one site is down
If Site1 (the local site) is down while setting up the protection
group, the subcloud peer group sync state is unable to determine.
This commit will automatically create the non-primary association on
Site2 (the peer site) when creating a primary association, and
update the sync state to the non-primary association. Then the
operator can check the sync state on Site2 if Site1 is down.

Test Plan:
- PASS: Create a primary association and check the non-primary
        association on peer site. It was created, and sync_status
        will follow the primary association's sync_status.
- PASS: Delete the primary association and check the non-primary
        association on peer site. It was deleted.
- PASS: If you restart the "dcmanager-manager service" in the local
        site while the association sync_status is in "syncing", the
        sync_status will transition to "failed".
- PASS: Create a primary association and wait for the sync_status
        change to "in-sync". Delete the subcloud peer group on peer
        site, the deletion will fail because it is associating to
        the non-primary association.

Closes-Bug: 2046809

Change-Id: Ia917d0dc7c65fbea1e222fb52dbec79fdbe65b65
Signed-off-by: Zhang Rong(Jon) <rong.zhang@windriver.com>
2024-01-02 16:39:08 +08:00
Gustavo Herzmann cd355ca120 Add rehome-pending deploy status
This commit adds the rehome-pending deploy status, which should be used
when unmanaging a subcloud before the rehoming/migration operation.
This new status will then be used by cert-mon to determine when it
should stop auditing an unmanaged subcloud, to avoid certificate
issues during the rehoming operation.

It's only possible to switch to this state when the subcloud is being
unmanaged and its deploy status is 'complete'. It's possible to manage
it back in case the rehoming operation is not going to be executed
anymore; in this case the deploy-status will be reverted back to
'complete'.

Example usage:
dcmanager subcloud unmanage --migrate subcloud1

CURL:
curl -X PATCH -H "X-Auth-Token: ${TOKEN//[$'\t\r\n']}" \
"http://$MGMT_IP:8119/v1.0/subclouds/{subcloud1}" \
-F migrate="true" \
-F management-state="unmanaged"

Test Plan:
1. PASS - Unmanage a subcloud without --migrate and verify that it
          still works and that cert-mon continues to audit it;
2. PASS - Manage a subcloud, verify that the operation still works as
          expected;
3. PASS - Try to unmanage with --migrate when the subcloud's deploy
          status is different than 'complete' and verify that it
          doesn't allow it;
4. PASS - Unmanage a subcloud using the --migrate option and verify
          that its deploy status changes to 'rehome-pending', all the
          sync statuses change to 'unknown', and that cert-mon stops
          auditing the subcloud;
5. PASS - By directly calling the SubcloudManager.update_subcloud()
          method (internally, skipping API validation), verify that:
          - it's possible to update the deploy_status to 'secondary'
            while also updating its management_state to 'unmanaged';
          - it's possible to update the deploy_status to
            'rehome-pending' while also updating its management_state
            to 'unmanaged';
          - it's NOT possible to update the deploy_status if the
            subcloud is not already unmanaged or its management_state
            is not being updated to 'unmanaged';
          - it's possible to update the deploy_status to 'secondary'
            for a subcloud that's already unmanaged;
          - it's possible to update the deploy_status to 'secondary'
            for a subcloud that's already unmanaged and currently in
            the 'rehome-pending' state.
          - Try to manage a 'rehome-pending' subcloud while also
            changing its deploy status to something different than
            'complete', verify that it fails;
6. PASS - Manage a 'rehome-pending' subcloud and verify that it
          succeeds while also reverting its deploy_status to
          'complete';
7. PASS - Run subcloud update to populate the rehome_data with the
          bootstrap values and address, verify that it still works.

Story: 2010852
Task: 49059

Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
Change-Id: I8bf76904e335e382407c2268a9c1879471ef2fc9
2023-11-09 15:33:06 -03:00
twang4 4027eee390 System peer and subcloud peer group monitoring and handling
System peer monitoring and handling:
It does peer health check by querying peer group list.
After failure is detected and the number of heartbeat
failure reaches the threshold, alarm will be raised.
After connection is back online, alarm will be cleared,
and will perform an audit to the peer groups that are associated
to the system peer.

Subcloud peer group audit and handling:
If the remote peer group's migration_status is in the 'migrating'
state, unmanage the subclouds of the local peer group.
If the remote peer group's migration_status is in the 'complete'
 state, compare the subclouds on both ends.
If the remote end is in a 'managed+online' state,
set the local subclouds with the same region_name to
'unmanaged+secondary.'
If the remote peer group's migration_status is in the 'none' state,
set the migration_status of the local peer group to 'none' as well.

Batch rehome update:
When Subcloud Peer Group based batch rehoming is performed,
need to check if the associated System Peer is alive or not:
If yes, and the remote subcloud with same region_name is
being managed in peer site, need to unmanage it before
rehoming it to local site.
If not, this means the peer site is not available for the
subcloud management any more, rehoming can be performed
directly.
If the subcloud peer group priority is 0, will try to clear alarm
of FM_ALARM_ID_DC_SUBCLOUD_PEER_GROUP_NOT_MANAGED
after batch rehoming is complete.

Security enhancement:
Base64 encode/decode admin_password when save/load rehome_data
from DB.

Test Plan:
1. PASS - Add a system peer on DC0, unplug the OAM network
          between DC0 and DC1. Alarm raised.
2. PASS - Reconnect the OAM network between DC0 and DC1,
          previous alarm will be cleared.
3. PASS - Add a subcloud peer group on DC0.
          Add two subclouds on DC0 under the subcloud peer group.
          which should be in managed, online and complete states.
          Add a system peer on DC0 pointing to DC1,
          Add a peer-group-association associating the peer-group
          and the system-peer above on DC0.
          create another association in DC1, for system DC0 and the
          peer group synced to DC1.
          Shutdown DC0, perform the migrate operation on
          subcloud-peer-group from DC1, after all subclouds have
          been migrated and entered online managed states.
          Power on DC0, check alarm like "Subcloud peer group
          xxx is managed by remote system (peer_uuid=xxx) with
          lower priority."  has been raised.
          Check the subcloud state on DC0, should be in 'secondary' state,
          Perform the migrate operation on subcloud-peer-group from DC0.
          After all subclouds have been migrated and entered online
          managed states. Alarm is cleared.
          Check subclouds on DC1, subcloud state should be in secondary state.
4.PASS - Migrate a subcloud peer group with 0 priority,
          Before migrate, check alarm
          FM_ALARM_ID_DC_SUBCLOUD_PEER_GROUP_NOT_MANAGED
          exists.
          After migration done, check alarm cleared.
5. PASS - When the remote peer group's migration_status is in the
          'migrating' state (if DC0 comes back online while rehoming
          is still in progress); DC0's subcloud will be auto set to 'unmanaged',
          after DC1's migration is complete and all subcloud in 'managed+online',
          DC0's subcloud will auto set to 'secondary'.

Story: 2010852
Task: 48483
Task: 48509
Task: 48819

Change-Id: Ic97e7c4a7628445522adfba4b0b2e0cc945cbe22
Signed-off-by: Wang Tao <tao.wang@windriver.com>
2023-11-06 10:12:31 +08:00
Zhang Rong(Jon) 477c9e6cb8 Add dcmanager peer group association management API support
Add dcmanager peer-group-association management API.

This commit adds peer-group-association APIs of
create/delete/update/show/list/sync,
and adds system-peer API of list subcloud-peer-groups.

Test Plan:
1. PASS - Verify that cloud manage peer-group-association
          through api successfully.
2. PASS - Verify that cloud get associated subcloud-peer-group
          list with system-peer api successfully.
3. PASS - Check create without providing the must required
          parameters.
4. PASS - Check create with wrong peer_group_priority.
5. PASS - Check delete with a not existing association id.
6. PASS - Check system_peer_manager associate peer group,
          sync peer group and delete association.
7. PASS - Create an association with 50 subclouds need to
          sync. Check the sync status on peer site after
          it is synced.

Story: 2010852
Task: 48506
Change-Id: I41c16a8ab13e60f5b1de5b05fbbc51821f7f8d57
Signed-off-by: Zhang Rong(Jon) <rong.zhang@windriver.com>
2023-11-04 10:36:41 +08:00
twang4 8196e7f946 Add Subcloud Peer group management
Group of the current managed subclouds which are supposed
to be duplicated in a peer site as secondary subclouds.

This commit add subcloud-peer-group APIs of
create/delete/update/show/list/
list-subclouds of a subcloud-peer-group

Update setting peer-group for subcloud, Using DB of subclouds'
'peer_group_id' Column.

Update subcloud update API, add peer_group parameter
Usage:
Add a subcloud to peer-group:
dcmanager subcloud update SUBCLOUD --peer-group PEER_GROUP
Remove a subcloud from peer-group:
dcmanager subcloud update SUBCLOUD --peer-group none

Test Plan:
1. PASS - Create a subcloud-peer-group
2. PASS - Update an existing subcloud's peer-group to a existing
              subcloud-peer-group successfully;
3. PASS - Verify subcloud-peer-group list-subclouds can get the expected
              Subcloud above successfully;
4. PASS - Update group_priority/group_state/max_subcloud_rehoming/
               system_leader_id/system_leader_name
              of a subcloud-peer-group successfully;
5. PASS - Check can get subcloud status of a subcloud-peer-group
               successfully;
6. PASS - Delete a subcloud-peer-group completes successfully.
7. PASS - Delete a subcloud-peer-group while it still has subclouds
               associated to it. the subclouds' peer-group-id is auto
               set to None successfully;
8. PASS - Add a subcloud, update the peer-group-id as a non-existing
              subcloud-peer-group, get error message successfully;
9. PASS - Update subcloud peer group with invalid
               group_priority/group_state/max_subcloud_rehoming/
               system_leader_id/system_leader_name

Story: 2010852
Task: 48485
Change-Id: I93d0808b8cf02eba0e6f687007df42e2d2ea1848
Signed-off-by: Wang Tao <tao.wang@windriver.com>
2023-09-08 15:43:31 +08:00
Cristian Mondo a6a6b84258 Subcloud Name Reconfiguration
This change adds the capability to rename the subcloud after
bootstrap or during subcloud rehome operation.

Added a field in the database to separate the region name
from the subcloud name.
The region name determines the subcloud reference in the
Openstack core, through which it is possible to access
the endpoints of a given subcloud. Since the region name
cannot be changed, this commit adds the ability to maintain
a unique region name based on the UUID format, and allows
subcloud renaming when necessary without any endpoint
impact.
The region is randomly generated to configure the subcloud
when it is created and only applies to future subclouds.
For those systems that have existing subclouds, the region
will be the same as on day 0, that is, region will keep the
same name as the subcloud, but subclouds can be renamed.

This topic involves changes to dcmanager, dcmanager-client
and GUI. To ensure the region name reference needed by the
cert-monitor, a mechanism to determine if the request is
coming from the cert-monitor has been created.

Usage for subcloud rename:
dcmanager subcloud update <subcloud-name> --name <new-name>

Usage for subcloud rehoming:
dcmanager subcloud add --name <subcloud-name> --migrate ...

Note: Upgrade test from StarlingX 8 -> 9 for this commit
is deferred until upgrade functionality in master is
restored. Any issue found during upgrade test will be
addressed in a separate commit

Test Plan:
PASS: Run dcmanager subcloud passing subcommands:
      - add/delete/migrate/list/show/show --detail
      - errors/manage/unmanage/reinstall/reconfig
      - update/deploy
PASS: Run dcmanager subcloud add supplying --name
      parameter and validate the operation is not allowed
PASS: Run dcmanager supplying subcommands:
      - kube/patch/prestage strategies
PASS: Run dcmanager to apply patch and remove it
PASS: Run dcmanager subcloud-backup:
      - create/delete/restore/show/upload
PASS: Run subcloud-group:
      - add/delete/list/list-subclouds/show/update
PASS: Run dcmanager subcloud strategy for:
      - patch/kubernetes/firmware
PASS: Run dcmanager subcloud update command passing --name
      parameter supplying the following values:
      - current subcloud name (not changed)
      - different existing subcloud name
PASS: Run dcmanager to migrate a subcloud passing --name
      parameter supplying a new subcloud name
PASS: Run dcmanager to migrate a subcloud without --name
      parameter
PASS: Run dcmanager to migrate a subcloud passing --name
      parameter supplying a new subcloud name and
      different subcloud name in bootstrap file
PASS: Test dcmanager API response using cURL command line
      to validate new region name field
PASS: Run full DC sanity and regression

Story: 2010788
Task: 48217

Signed-off-by: Cristian Mondo <cristian.mondo@windriver.com>
Change-Id: Id04f42504b8e325d9ec3880c240fe4a06e3a20b7
2023-09-07 10:30:06 -03:00
Zhang Rong(Jon) 9d1c9ccd23 Add system peer management API support
Add dcmanager system-peer management api.

Test Plan:
1. PASS - Verify that cloud manage system-peer
          through api successfully.
2. PASS - Add system peer with invalid UUID, manager_endpoint,
	  systemcontroller_gateway_address, administrative_state,
	  heartbeat_interval
3. PASS - Update system peer with invalid administrative_state,
	  heartbeat_interval
4. PASS - Get system peer with UUID, name
5. PASS - Delete system peer with UUID, name

CLI example:
dcmanager system-peer add --peer_uuid $(uuidgen) --peer_name dc-0
--manager_endpoint http://128.128.128.1:5000/v3
(The peer_uuid get from the peer site with command `system show`)

dcmanager system-peer list

dcmanager system-peer update --administrative_state enabled 1

dcmanager system-peer show 1

dcmanager system-peer delete 1

Story: 2010852
Task: 48482

Change-Id: I349cd24bccc732eb8ed56df9346185cfce7b2570
Signed-off-by: Zhang Rong(Jon) <rong.zhang@windriver.com>
2023-08-28 06:18:28 +00:00
Gustavo Herzmann 338ceaca81 Deprecate dcmanager subcloud reinstall and reconfig
This commit deprecates the dcmanager subcloud reinstall and reconfig
in favor of the new 'dcmanager subcloud redeploy' and 'dcmanager
subcloud deploy config' commands, respectively.

This commit also removes unused constants, add missing deploy states
to the subcloud audit function and to the subcloud restore invalid
state list, and fixes the api-ref method for the deploy install and
resume commands.

Test Plan:
1. PASS - Call the reinstall API endpoint and verify that it returns
   the 410 status code with the deprecation notice instructing the use
   of the /v1.0/subclouds/{subcloud}/redeploy URL;
2. PASS - Call the reconfigure API endpoint and verify that it returns
   the 410 status code with the deprecation notice instructing the use
   of the /v1.0/phased-subcloud-deploy/{subcloud}/configure URL.
3. PASS - Change the subcloud deploy state to the new states added to
   the INVALID_DEPLOY_STATES_FOR_RESTORE, call the subcloud backup
   restore and verify that the operation is not allowed;
4. PASS - Change the subcloud deploy state to the new states added to
   the audit function and verify that the audit is not skipped.

Story: 2010756
Task: 48572

Change-Id: I9a502a89ec1c6eb23f286a80c7bf39fcbed0b2c4
Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
2023-08-25 15:22:18 -03:00
twang4 24a825848c Add subcloud secondary status support and migration
Definition of "Day-2": User can perform the operation post
the initial deployment.

Definition of "secondary": A secondary subcloud is just in the
DB, will not do any other operations like management/sync.

Update DB of subclouds add rehome_data column.

Update "dcmanager subcloud add --secondary" to save data for
day-2's rehome/migrate purpose.

Update "dcmanager subcloud update --bootstrap-address
--bootstrap-values" to save data for day-2's
rehome/migrate purpose.

Add "dcmanager subcloud migrate" for day-2's rehome/migrate

Example of usage:
dcmanager subcloud add --secondary --bootstrap-address \
128.224.115.15 --bootstrap-values ./sub1-bootsrapvalues.yml
dcmanager subcloud migrate sub1 --sysadmin-password PASSWORD
EQUALS TO:
dcmanager subcloud add --migrate --bootstrap-address \
123.123.123.123 --bootstrap-values ./sub1-bootsrapvalues.yml \
--sysadmin-password password

This commit updates the 'subcloud add' implementation to use
the 'secondary' subcloud deployment operations.
It saves rehome necessary data as JSON format into the
'subclouds' table's 'rehome_data' column in the DB.
Additionally, it adds the 'migrate' subcommand for
subcloud day-2's migration abilities.

Test Plan:
1. PASS - Verify that 'secondary' option works for 'subcloud add'
              successfully.
2. PASS - Verify that 'bootstrap-values' could update
               subclouds' rehome_data through api.
               successfully.
3. PASS - Verify that 'bootstrap-address' could update
               subclouds' rehome_data through api.
               successfully.
4. PASS - Verify that 'migrate' command can migrate a 'secondary'
               subclouds successfully.
5. PASS - Verify original subcloud add/update functionalities
               successfully.
6. PASS - Verify 'subcloud add --secondary' can handle error
              And set secondary-failed successfully.
7. PASS - Verify delete a 'secondary-failed' subcloud
              successfully

CLI example:
dcmanager subcloud add --secondary --bootstrap-address 128.224.119.55 \
--bootstrap-values ./testsub.yml

dcmanager subcloud update testsub --bootstrap-address 128.224.119.55 \
--bootstrap-values ./testsub.yml

dcmanager subcloud migrate testsub --sysadmin-password PASSWORD
API use case:
PATCH /v1.0/subclouds/testsub/migrate

Story: 2010852
Task: 48503
Task: 48484
Change-Id: I9a308a4e2cc5057091ba195c4d05e9d1eb4a950c
Signed-off-by: Wang Tao <tao.wang@windriver.com>
2023-08-25 11:03:17 +08:00
Victor Romano 528f90afec Add subcloud redeploy option to dcmanager
This commit adds the command "subcloud redeploy" to dcmanager.
The redeploy operation is similar to "subcloud reinstall",
performing a fresh install, bootstrapping and configuring the
subcloud, but allowing the user to use either previously used
install/bootstrap/config values stored on the system controller
or new values from provided files. Since config is an optional
phase, it will only be executed if respective parameters are
provided in the current request or were provided in a previous
deployment.

Test Plan:
  Success cases:
    - PASS: Redeploy subcloud without passing any new files and
            verify the redeployment was successful and the final
            deploy state is "complete".
    - PASS: Redeploy subcloud passing new install/bootstrap/config
            files and verify the redeployment was successful and
            the final deploy state is "complete".
    - PASS: Redeploy a subcloud with a different management
            subnet and verify that the network reconfiguration
            was executed during the bootstrap phase and the
            redeployment completed successfully.
    - PASS: Redeploy a subcloud that wasn't configure by the
            "deploy config" command passing a config file and
            verify that the subcloud was redeploy and configured.
    - PASS: Redeploy a subcloud that wasn't configure by the
            "deploy config" command without passing a config file.
            and verify that the subcloud was redeployed and no
            configuration attempt was made.
    - PASS: Redeploy a subcloud passing a previous release (21.12)
            and verify the redeployment was successful and the final
            deploy state is "complete".
    - PASS: Abort each one of the three deployment phases. Verify the
            deployment was successfully aborted.
    - PASS: Resume the aborted deployment and verify the subcloud was
            successfully deployed.
    - PASS: Repeat previous tests but directly call the API (using
            CURL) instead of using the CLI.

  Failure cases:
    - PASS: Verify it's not possible to redeploy an online and/or
            managed subcloud.
    - PASS: Call the API directly, passing bmc-password and/or
            sysadmin-password as plain text as opposed to b64encoded
            and verify that the response contains the correct error
            code and message.

Story: 2010756
Task: 48496

Change-Id: I6148096909adda2b95b6bb964bc7a749ac62c20c
Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
2023-08-21 17:32:50 -03:00
Gustavo Herzmann 2050cf7ceb Add 'subcloud deploy complete' command to dcmanager
This commit adds the subcloud deploy complete command to dcmanager.
It's used to mark the subcloud deployment as 'complete'. This is
useful when the user manually configures the subcloud and wants to finalize the deployment without running 'dcmanager subcloud deploy config'.

To run the 'deploy complete' operation deploy status of the subcloud
must be 'bootstrap-complete'.

This commit also fixes an issue with the value returned from the
subcloud_deploy_create function. It was returning the database model
object to the RCP call when it should be returning a dictionary.

Test Plan:
1. PASS - Bootstrap a subcloud, manually configuring it and then run
          the deploy complete command (by CLI and directly through the
          API). Verify that the deploy status updates from
          'bootstrap-complete' to 'complete';
2. PASS - Verify that the command is rejected when the deploy status
          is not 'bootstrap-complete'.

Story: 2010756
Task: 48453

Change-Id: Ie2eca930e4b13a50cc12e8b9eef79bcb5e7c671f
Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
2023-07-31 16:59:16 +00:00
Victor Romano adc8e48ac9 Add subcloud deploy resume option to dcmanager
This commit adds the command "subcloud deploy resume" to dcmanager.
It will resume subcloud deployment based on current subcloud deploy
state. All parameters except sysadmin-password are optional if they
were already provided in previous phases. Since install and config
are both optional phases, they will only be executed if respective
parameters are/have been provided.

Test Plan:
  These options will be referenced on the test cases as the values
  already present on the system controller before the resume operation
  or the values passed to it's command:
  [1] All values (install_values, bootstrap_values, deploy_config)
  [2] Only install_values and bootstrap_values
  [3] Only bootstrap_values
  [4] Only deploy_config
  Success cases:
    - PASS: Resume from create-complete previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from create-complete previously having [2] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'bootstrap-complete'.
    - PASS: Resume from create-complete previously having [3] without
            passing any new parameter and manually installing the
            subcloud and verify that it's deploy state is
            'bootstrap-complete'.
    - PASS: Resume from create-complete previously having [1] passing
            a previous release (21.12) and verify that the subcloud's
            deploy state is 'complete' and the installed load is
            correct.

    - PASS: Resume from install-complete previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from install-complete previously having [2] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'bootstrap-complete'.
    - PASS: Resume from install-complete previously having [3] without
            passing any new parameter and verify that it's deploy state
            is 'bootstrap-complete'.
    - PASS: Resume from install-failed previously having [1] passing
            new install_values and verify that the subcloud's deploy
            state is 'complete' and the installation used new values.
    - PASS: Resume from install-failed previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from install-aborted previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.

    - PASS: Resume from bootstrap-complete previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from bootstrap-complete previously having [3] and
            passing [4] and verify that the subcloud's deploy state
            is 'complete'.
    - PASS: Resume from bootstrap-failed previously having [1] passing
            new bootstrap_values and verify that the subcloud's deploy
            state is 'complete' and the bootstrap used new values.
    - PASS: Resume from bootstrap-failed previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from bootstrap-aborted previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.

    - PASS: Resume from config-failed previously having [1] passing
            new deploy_config file and verify that the subcloud's deploy
            state is 'complete' and the config used new values.
    - PASS: Resume from config-failed previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.
    - PASS: Resume from config-aborted previously having [1] without
            passing any new parameter and verify that the subcloud's
            deploy state is 'complete'.

    - PASS: Repeat previous tests but directly call the API (using
            CURL) instead of using the CLI.

  Failure cases:
  - PASS: Verify that it's not possible to resume deployment if the
          deploy state is not one of the following:
          - create-complete
          - install-complete
          - pre-install-failed
          - install-failed
          - install-aborted
          - bootstrap-complete
          - pre-bootstrap-failed
          - bootstrap-failed
          - bootstrap-aborted
          - pre-config-failed
          - config-failed
          - config-aborted
  - PASS: Call the API directly, passing bmc-password and/or
          sysadmin-password as plain text as opposed to b64encoded and
          verify that the response contains the correct error code
          and message.
  - PASS: Resume from bootstrap-complete previously having [2] and
          verify that the system alerts that the only remaining phase
          is config and there's no deploy-config file available

Story: 2010756
Task: 48316

Change-Id: I81c0a226b3ede56628e21372b02748013c3f6b35
Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
2023-07-24 14:00:06 -03:00
Victor Romano f081453b3c Add subcloud deploy abort option to dcmanager
This commit adds the command "subcloud deploy abort" to dcmanager.
It allows the user to abort the on-going execution of a playbook
against the subcloud. Any task will be aborted immediately if the
unabortable flag is not set by the playbook [1]. If current
operation is install, a shutdown command will also be issued.

Test Plan:
  Success cases:
  - PASS: Trigger an abort during installation and verify that the
          playbook execution was aborted immediately, the subcloud was
          shut dows after it and the RVMC pod and job were terminated.
  - PASS: Trigger an abort during config and verify that
          the playbook execution was aborted immediately.
  - PASS: Trigger an abort during bootstrap without the presence
          of unabortable flag and verify that the playbook execution
          was aborted immidiately.
  - PASS: Trigger an abort during bootstrap with the presence of
          unabortable flag and verify that the playbook execution
          was aborted only after the flag was deleted.
  - PASS: Trigger an abort directly calling the API (using CURL
          instead of using the CLI.
  Failure cases:
  - PASS: Verify that the abort request is rejected if deploy
          state is not 'installing', 'bootstrapping' or 'configuring'.
  - PASS: Abort when an unabortable task is running and then force an
          external error during this task restarting dcmanager-manager
          service, verify that deploy state is set to a failed state
          e.g. bootstrap-failed.
  - PASS: Abort when an unabortable task is running and then force an
          internal error during this task using ansible.builtin.fail
          module, verify that deploy state is set to a failed state
          e.g. bootstrap-failed.
  - PASS: Abort when an unabortable task is running and then force
          the playbook to halt the execution during this task using
          ansible.builtin.pause module, verify that deploy state is
          set to a failed state after 10 minutes
          e.g. bootstrap-failed.

Story: 2010756
Task: 48102

Co-Authored-By: Gustavo Herzmann <gustavo.herzmann@windriver.com>
Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
Change-Id: Ic5311324a76bf7ce1215692e934d5577ff82868e
2023-07-19 14:16:00 -03:00
Victor Romano 77faee83d2 Add subcloud deploy install option to dcmanager
This commit adds the command "subcloud deploy install" to dcmanager.
It runs the subcloud install step only. The install values file is
optional if it has already been provided in the previous phase
using subcloud deploy create.

Test Plan:
  Success cases:
  - PASS: Install passing install_values and verify that the subcloud
          was successfully installed.
  - PASS: Install without passing install_values and verify that the
          subcloud was successfully installed using install data
          previously saved in db.
  - PASS: Install passing current release and verify that the
          subcloud was successfully installed.
  - PASS: Install passing previous release and verify that the
          subcloud was successfully installed.
  - PASS: Repeat previous tests but directly call the API (using
          CURL) instead of using the CLI.
  Failure cases:
  - PASS: Verify that it's not possible to run the install if deploy
          state is not 'create-complete', 'pre-install-failed',
          'install-failed' or 'install-complete'.
  - PASS: Call the API directly, passing bmc-password as plain text
          as opposed to b64encoded and verify that the response
          contains the correct error code and message.

Story: 2010756
Task: 48056

Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
Change-Id: I3a9f4e8c2f39964b2b0b784181bc78494f3078a2
2023-06-26 15:35:50 -03:00
Victor Romano 6b7b012992 Add the subcloud deploy config option to dcmanager
This commit adds the command "subcloud deploy config" to dcmanager.
It provides similar options as dcmanager subcloud reconfig. However,
the --deploy-config file is optional if it has been provided previously
via subcloud deploy config or subcloud deploy create command.

Test Plan:
  Success cases:
  - PASS: Bootstrap a subcloud then issue "dcmanager subcloud deploy
          config" command with --deploy-config option to apply initial
          config. Verify that the subcloud is successfully configured.
  - PASS: Create a deploy config using dcmanager subcloud deploy create
          with --deploy-config option. Install and bootstrap the
          subcloud then config the subcloud using dcmanger subcloud
          deploy config with --deploy-config option. Verify that the
          subcloud is successfully configured with config options
          provided last.
  - PASS: Bootstrap a subcloud then issue "dcmanager subcloud deploy
          config" command with --deploy-config option to apply an
          erroneous config. Verify that the subcloud fails to be
          configured. Repeat the command this time with a good config
          file and verify that the subcloud is successfully configured.
  - PASS: Apply config passing deploy_config file for a subcloud
          running a previous release (21.12) and verify that
          the subcloud was successfully configured.
  - PASS: Create a subcloud deploy with --deploy-config option,
          install and bootstrap the subcloud then issue "dcmanager
          subcloud deploy config" command without --deploy-config
          option. Verify that the subcloud is successfully configured.
  - PASS: Repeat previous tests but directly call the API (using
          CURL) instead of using the CLI.
  Failure cases:
  - PASS: Verify that it's not possible to run the config if deploy
          state is not 'complete', 'pre-config-failed', 'config-failed',
          'deploy-failed', 'bootstrapped' or in a prestaging state.
          ('deploy-failed' will be removed once 'subcloud reconfig'
           is deprecated)
  - PASS: Verify that it's not possible to run "dcmanager subcloud
          deploy config" command without providing a deploy config file
          if this has never been provided before.
  - PASS: Verify that it's not possible to run the config without
          previously uploading deploy files.
  - PASS: Verify that it's not possible to configure without
          passing the 'sysadmin-password' parameter (using CURL,
          since the CLI will prompt for the password if it's
          omited)
  - PASS: Call the API directly, passing sysadmin-password as plain
          text as opposed to b64encoded and verify that the response
          contains the correct error code and message.

Story: 2010756
Task: 48022

Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
Change-Id: I65e1cbea1879d49066c2add69cabd04e64216b8f
2023-06-26 15:12:38 -03:00
Gustavo Herzmann 32f6fc5805 Add 'subcloud deploy bootstrap' command to dcmanager
Adds the subcloud deploy bootstrap command to dcmanager. It only
performs the bootstrap phase, where all parameters are validated and
the bootstrap playbook is executed.

The bootstrap values can be updated using the bootstrap-values
parameter, otherwise the system will use the boostrap values from the
subcloud deploy create command.

Test Plan:
  The following tests were run twice, once using the CLI, and once
  using CURL to request the API directly.
  The subcloud was created using the follwing command:
  dcmanager subcloud deploy create
    --bootstrap-address <bootstrap-address>
    --bootstrap-values <bootstrap-values>
  Except for the different release test, where the --release 21.12
  parameter was also used.

  The following commands were used to test the bootstrap (changing the
  parameters accordingly for each test):
  CLI: dcmanager subcloud deploy bootstrap
    --bootstrap-address <bootstrap-address>
    --bootstrap-values <bootstrap-values>
    --sysadmin-password <password>
    <subcloud name or id>
  CURL: curl -X PATCH -H "X-Auth-Token: ${TOKEN//[$'\t\r\n']}"
    "http://$MGMT_IP:8119/v1.0/phased-subcloud-deploy/
    <subcloud name or id>/bootstrap"
    -F bootstrap_values=@<bootstrap-values>
    -F bootstrap-address=<bootstrap-address>
    -F sysadmin_password=<b64 encoded password>

  Success cases:
    1. PASS - Bootstrap a subcloud without the bootstrap-values and
              bootstrap-address parameters (omit them from the CLI/CURL
              command) and verify that it uses the existing values
              (from the deploy create command);
    2. PASS - Bootstrap a subcloud with the same bootstrap-values and
              bootstrap-address parameters used during deploy create
              (include the parameters in the CLI/CURL command, using
              the same values used during deploy create);
    3. PASS - Bootstrap a subcloud with bootstrap-values containing a
              new value for management_subnet, verifying that the
              routes and endpoints are updated accordingly;
    4. PASS - Verify that if a new bootstrap-address is used, the
              subcloud inventory file is updated accordingly;
    5. PASS - Verify subcloud bootstrap with previous release version
              (tested with 21.12);
  Failure cases:
    6. PASS - Verify that it's not possible to bootstrap with a
              management_subnet that conflicts with the subnet of an
              existing subcloud;
    7. PASS - Verify that it's not possible to bootstrap when the
              deploy status is not in one of the following states:
              'install-complete', 'bootstrap-failed',
              'bootstrap-aborted', 'bootstrap-complete' and
              'create-complete';
    8. PASS - Verify that it's not possible to bootstrap when the
              'name' parameter from bootstrap-values doesn't match the
              subcloud name;
    9. PASS - Verify that it's not possible to bootstrap without
              passing the 'sysadmin-password' parameter (using CURL,
              since the CLI will prompt for the password if it's
              omited);
    10. PASS - Verify that it's not possible to bootstrap with a
              'sysadmin-password' that's not b64encoded (using CURL,
              since the CLI automatically encodes the password).

Story: 2010756
Task: 48114

Change-Id: Ic987406bbcc154a8edbaa008c40ccabe1766d03d
Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
2023-06-20 17:44:55 -03:00
Gustavo Herzmann cb8737316f Add 'subcloud deploy create' command to dcmanager
This commit adds the subcloud deploy create command to dcmanager. It
accepts the same parameters as the subcloud add command, but only
performs the pre-deployment phase, where all parameters are validated
and the subcloud database entry is created. It does not perform the
install, bootstrap or config phases.

The commit does not modify the subcloud add command to use this phase
internally, this will be done in another commit, after the other
deployment phases are implemented.

Test Plan:
1. PASS - Create a subcloud using all the parameters and verify that
          the data is correctly stored in the DB;
2. PASS - Verify that the values from --install-values are correctly
          stored in the DB;
3. PASS - Verify that the values from --deploy-config and
          --bootstrap-values are are stored correctly in the
          ANSIBLE_OVERRIDES_PATH directory;
4. PASS - Verify that it's not possible to create a subcloud without
          the required parameters;
5. PASS - Verify that it's not possible to create a subcloud while
          another one with the same name or address already exists;
6. PASS - Repeat previous tests after swacting to controller-1.
7. PASS - Repeat previous tests but directly call the API (using
          CURL) instead of using the CLI;
8. PASS - Call the API directly, passing bmc-password as plain text
          as opposed to b64encoded and verify that the response
          contains the correct error code and message.

Story: 2010756
Task: 48030

Change-Id: Ia5321d08df7bec5aef1a8f90cb7292a522da9af9
Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
2023-06-20 09:13:41 -03:00
Enzo Candotti e2985c370e Rename config_sync_status field
This commits updates the 'config_sync_status' field name to
'deploy_config_sync_status' in order to distiguish from the
config-out-of-date information related to the 250.001 alarm.

Test Plan:
PASS: Build distributedcloud package. Install it on a DC system
alongside the client changes. Verify that the client receives
the updated field name and that the name printed on the output
command is the expected.
PASS: Verify the correct functionality of the 'dcmanager
subcloud show --detail' command.

Story: 2010719
Task: 48089

Change-Id: I8e573947dfa61700f15bba4313939bb7a7959d53
Signed-off-by: Enzo Candotti <enzo.candotti@windriver.com>
2023-05-24 17:57:11 -03:00
Enzo Candotti e88471cd38 Show Subcloud Deploy Configuration Status
This commit extends the
"dcmanager subcloud show <subcloud> --detail" command to display
the deploy configuration status of the subcloud from the
systemcontroller.

The presence of a 260.002 alarm related to a 'host' resource on an
online subcloud indicates an outdated deploy configuration.
In such cases, the field will display "Deployment: configurations
out-of-date". Otherwise, the field  will show:
"Deployment: configurations up-to-date". The field will not be shown
for offline subclouds.

Test Plan:
PASS: Successful bring up of a fresh DC system with these changes.
PASS: Run 'dcmanager subcloud show' without the '--detail' argument.
Verify that the new field is not being shown.
PASS: Run 'dcmanager subcloud show --detail' for an online subcloud
containing a 260.002 alarm related to a host resource. Verify that
the output contains 'Deployment: configurations out-of-date'.
PASS: Run 'dcmanager subcloud show --detail' for an online subcloud
containing a 260.002 alarm related to a resource other than host.
Verify that the output contains 'Deployment: configurations
up-to-date'.
PASS: Run 'dcmanager subcloud show --detail' for an online subcloud
without a 260.002 alarm. Verify that the output contains 'Deployment:
configurations up-to-date'.
PASS: Run 'dcmanager subcloud show --detail' for an offline subcloud.
Verify that the new field is not being shown.

Story: 2010719
Task: 48025

Change-Id: I223919ded1d6d5dfcc81c2060c5e6491ed8a73d9
Signed-off-by: Enzo Candotti <enzo.candotti@windriver.com>
2023-05-24 11:51:15 -03:00
Li Zhu f174505b66 Add release optionality to subcloud prestage
Add an optional --release parameter to subcloud prestage and
prestage_strategy create commands to enable release optionality
in subcloud prestage.

Test Plan:
  - Verify successful subcloud prestage with specified 21.12 or 22.12
    release.
  - Verify successful subcloud prestage with the active release (22.12)
    when the release parameter is absent.
  - Verify the subcloud prestage request was rejected by specifying
    a release other than the subcloud and system controller's current
    release(s) and any inactive load release.
  - Verify successful creation of prestage strategy with specified
    21.12 or 22.12 release.
  - Verify successful creation of prestage strategy with the active
    release (22.12) when the release parameter is absent.

Depends-On: https://review.opendev.org/c/starlingx/ansible-playbooks/+/880788

Story: 2010611
Task: 47848

Signed-off-by: lzhu1 <li.zhu@windriver.com>
Change-Id: I125b164c223074b42f16c9cf039771a4802d44dc
2023-05-19 16:33:42 -04:00
Victor Romano 9824f80d95 Add release parameter to subcloud-backup restore
Add optional --release parameter to subcloud-backup restore so that the
user can specify which loaded image to use during the installation
process triggered by --with-install.
This parameter can only be used if --with-install is also specified.

Test plan:
  PASS: Verify that the subcloud is restored with installation of
        current active release when specified.
  PASS: Verify that the subcloud is restored with installation of
        previous inactive release when specified.
  PASS: Verify that the subcloud is restored with installation of
        current active release if the "--release" parameter is omitted.

Story: 2010611
Task: 47709

Signed-off-by: Victor Romano <victor.gluzromano@windriver.com>
Change-Id: I619a1bf50c221fe6fc8cdfa87724d18393aef9cb
2023-04-12 16:20:33 -03:00
Hugo Brito 3d7cb75e22 Generalize subcloud network reconfiguration
This commit refactors the subcloud network reconfiguration,
allowing for a more flexible and generalized approach, adding
the option to fallback to the management network as well.

Test Plan:
PASS: Run dcmanager subcloud update with network paramaters
(dcmanager subcloud update --sysadmin-password <password>
--management-subnet <network-subnet>
--management-gateway-ip <network-gateway-ip>
--management-start-ip <network-start-ip>
--management-end-ip <network-end-ip>
--bootstrap-address <bootstrap-address> <subcloud_name>)
- The update_playbook will be called and update the subcloud
(subcloud route to systemcontroller and admin endpoints)
- A new route to the subcloud is created on the system controller.
- Subcloud service endpoint URLs are updated in keystone
(openstack endpoint list|grep <subcloud-name>) on the system controller.
PASS: verify successful deployment of a new subcloud
PASS: verify successful reconfiguration of a subcloud from mgmt to
admin network

Depends-On: https://review.opendev.org/c/starlingx/ansible-playbooks/+/878504

Story: 2010319
Task: 47706

Signed-off-by: Hugo Brito <hugo.brito@windriver.com>
Change-Id: I1df57a206e21fa2444bd645c456c4d5d1b539066
2023-04-04 13:00:03 -03:00
Li Zhu ad1f05ac5f Add release optionality to subcloud add/reinstall
Add an optional --release parameter to subcloud add and reinstall
commands to enable release optionality in subcloud add and subcloud
reinstall.

Test Plan:
1. Verify successful subcloud add which includes remote install with
specified (previous/current) release
2. Verify successful subcloud reinstall with the specified
(previous/current) release
3. Verify the subcloud is successfully installed with the active
release when the release parameter is absent
4. Verify the subcloud is successfully reinstalled with the active
release when the release parameter is absent
5. Verify the subcloud install request was rejected
when the software_version in the install_values doesn't
match the specified release
6. Verify the subcloud install/reinstall request was rejected
when the kubernetes_version value specified in the subcloud bootstrap
yaml file doesn't match the value of the fresh_install_k8s_version of
the specified previous release

Depends-On: https://review.opendev.org/c/starlingx/utilities/+/878545
            https://review.opendev.org/c/starlingx/ansible-playbooks/+/878922

Story: 2010611
Task: 47684

Signed-off-by: lzhu1 <li.zhu@windriver.com>
Change-Id: Ic4193c2901d8bfa485eeb683c08422d946802bcb
2023-04-03 00:12:39 +00:00
Gustavo Herzmann 34025f18cf Add upload-only parameter to dcmanager api-ref docs
Updates the api-ref parameter list and the request/response examples
to include the new upload-only option from the DC patch orchestration
strategy.

Story: 2010584
Task: 47650

Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
Change-Id: I2bba78d5db1a876df3324a333925a9f75fdd8625
2023-03-15 09:12:05 -03:00
rsujay 157c166f7c Update DC api-ref documentation with new parameters
The current restrictions for network reconfiguration post-install is problematic for correcting or updating network configuration for Subcloud deployments or supporting Subcloud rehoming procedures.

The proposed solution is to decouple the Distributed Cloud networking operations from the management network by introducing a new admin network type that will be used for the addressing and routing between the central System Controller and the Subcloud.

Currently, network parameters are not able to be modified via the dcmanager subcloud update CLI.  This commit is to update DC api-ref documentation with new admin parameters.

Test-plan: Debian
dcmanager subcloud update --admin-subnet --admin-gateway-ip --admin-node-0-address --admin-node-1-address
dcmanager subcloud show


Story: 2010319
Task: 47139

Signed-off-by: rsujay <ramkrishna.sujay@windriver.com>
Change-Id: I971943fa7fec63d4fae222ba0199ef1811975f8f
2023-02-02 06:05:28 +00:00
Hugo Brito 183e62525c Deprecate dcmanager subcloud restore API
With the new dcmanager subcloud-backup restore [1][2] the
old restore code can be removed. This removes all code
related to the legacy restore and returns error 410 if
the user tries to access the old API.

1: https://review.opendev.org/c/starlingx/distcloud/+/862431
2: https://review.opendev.org/c/starlingx/distcloud/+/860598

Test Plan:
PASS - Test add subcloud

Story: 2010116
Task: 46763

Signed-off-by: Hugo Brito <hugo.brito@windriver.com>
Change-Id: I185464424da7b853a644ec905bdb383ce5c857f9
2022-11-18 15:24:06 -03:00
Andre Carneiro a9fab3e396 Add API doc for subcloud-backup delete and restore
Document the dcmanager subcloud-backup delete and restore API.

Story: 2010116
Task: 46210

Signed-off-by: Andre Carneiro <Andre.DexheimerCarneiro@windriver.com>
Change-Id: I2675dd555de9a5e89a6d78beda6f11846cc6f4ba
2022-11-01 17:30:38 -03:00
Gabriel Silva Trevisan ee0bec71ec Update dcmanager API doc for subcloud-backup
Document the dcmanager subcloud-backup API.

Story: 2010116
Task: 45696

Signed-off-by: Gabriel Silva Trevisan <gabriel.silvatrevisan@windriver.com>
Change-Id: Iebdf3ce65a19144382b0419e94f05c47ff6f39fa
2022-10-27 15:23:34 -03:00
Andre Carneiro 198f8aab71 Fixes documentation for subcloud-group delete
The return code for the subcloud-group delete rest
request was wrong in the documentation. The endpoint
returns status 200 upon success, instead of 204 as
was written in the documentation. This changes the
documentation with the correct response code.

Closes-Bug: 1988221

Signed-off-by: Andre Carneiro <Andre.DexheimerCarneiro@windriver.com>
Change-Id: I6fc89e7c71dd51e8aaf2b9858ef89a7d5fdbb871
2022-08-31 14:06:49 -03:00
Kyle MacLeod 9c4d1e9965 Fix prestage orchestration details for skipped subclouds
Ensure that the 'details' field reflects the reason a subcloud is
skipped during prestage orchestration.

We use a new exception, StrategySkippedException, to signal the
OrchThread that a subcloud is being skipped. This immediately
transitions the subcloud strategy to complete, while preserving
the reason for skipping in the strategy_step details.

NOTE: this update also includes a minor update
to the API parameters file, which was missed in the
original feature commit (api-ref/source/parameters.yaml)

Test Plan:

PASS:
- normal prestage orchestration
- prestage orchestration with non-AIO-SX subcloud
    - subcloud is skipped
    - details populated and reported in details column
      of 'dcmanager strategy-step list'
    - subcloud deploy_status is returned to 'complete'
- verify feature logging

Closes-Bug: 1963967
Signed-off-by: Kyle MacLeod <kyle.macleod@windriver.com>
Change-Id: I3408f274e3e04410872716b718130a3a27006c36
2022-03-07 14:13:51 -05:00
BoYuan Chang 0d05b33719 Support subcloud deploy upload prestaging images
Modify the existing REST API to upload the prestaging images list
to system controller

Test Cases Completed on local VM as well as DC Lab

a. (Passed) With all 4 variables
b. (Passed) With only --prestage-images
c. (Passed) With all other variables expect for --prestage-images
d. (Passed) With 1 or 2 missing varibles when --prestage-images is present
e. (Passed) With 1 or multiple invalid directory path

REST APIs:
curl -X POST -H "X-Auth-Token: $TOKEN" $APIURL/subcloud-deploy \
-F deploy_playbook=@<full path of the playbook name> \
-F deploy_overrides=@<full path of the override file name> \
-F deploy_chart=@full path of the helm chart name> \
-F prestage_images=@<full path of the prestage image name>

CLI:
dcmanager subcloud-deploy upload \
--deploy-playbook <full path of the playbook name> \ <- Existing
--deploy-chart <full path of the override file name> \ <- Existing
--deploy-overrides <full path of the override file name> <- Existing
--prestage-images <full path of the override file name> <- Added

Story: 2009799
Task: 44342

Change-Id: I75d4ac0931d2a37ceb68281a2ab6137ee2459e99
2022-01-31 15:10:50 -05:00
albailey 20774e10e9 Updating API docs for dcmanager commands
Aligns the API doc with its current functionality.

 - Splits the examples (requests and responses)
into their own json files.

 - Splits parameters and result fields into a parameters.yaml
file to simplify shared fields between APIs.

 - Several APIs actually return 200 for delete rather than 204

 - Converted 'Patch' to 'Software Update' when referring
to the variety of update types supported.

 - Added missing fields. ex: extra-args for strategies.

 - Updated responses to include new sync status fields.

Change-Id: I6d26765be0a8e98664f904314af15bfdfab9fda2
Story: 2008675
Task: 43752
Signed-off-by: albailey <Al.Bailey@windriver.com>
2022-01-13 12:45:53 -06:00
Yuxing Jiang df6fa08f77 Add mandatory/optional parameters in subcloud reinstall API
The subcloud reinstall requires bootstrap values and sysadmin password
which are not stored in the central cloud database for bootstrapping a
subcloud after reinstall. This commit adds these mandatory values to
the subcloud reinstall API, parses these values along with the
existing install values to reinstall a subcloud. In addtion, the
deploy config values are also accepted to deploy the re-installed post
bootstrap.

Tests:
Unhappy path:
1. Reinstall an online subcloud, reinstall rejected.
2. Reinstall a subcloud without mandatory bootstrap value
"system_mode", reinstall rejected.
3. Reinstall a subcloud with "management_start_address" differs from
the value stored in database, reinstall rejected.
4. Reinstall a subcloud without image in data_install, and the
software image is not uploaded in dc-vault, reinstall rejected.

Happy path:
1. Power off a managed subcloud, reinstall this subcloud with correct
bootstrap values and deploy config, the subcloud goes "installing",
"bootstrapping" and turns online and unmanaged after deployment. After
managing this subcloud, it turns in-sync status.
2. Power off a subcloud, reinstall this subcloud with only bootstrap
values offered. After the deploy status changes to "complete", issue a
dcmanager subcloud reconfigure with its deploy config values. The
subcloud will turn online after deployment.
3. Swact the active system controller, power off a subcloud, reinstall
this subcloud on the previous standby system controller. the subcloud
is reinstalled successfully and goes online after deployment.
4. Upgrade the system controllers and subcloud controllers in a DC
system, power off a subcloud after the upgrade, reinstall the subcloud
on the upgraded system controller, the reinstall is successful, and
the subcloud goes online after deployment.
5. Power off a subcloud, manually manipulate the software
version(including the value in data_install), add an image path in
data_install, reinstall this subcloud. The reinstall is successful.
Check the data in database, the software version is corrected and the
image path is changed to the image in dc-vault.

Partial-Bug: 1932034
Signed-off-by: Yuxing Jiang <yuxing.jiang@windriver.com>
Change-Id: I6cdfaa3d476b1c2cdd3970fdfad4a5273d1b1222
2021-06-22 23:47:20 +00:00
Tee Ngo 1348af4772 Update dcmanager API doc for subcloud restore
Document the dcmanager subcloud restore API.

Story: 2008573
Task: 42034
Change-Id: I38505518b367b275a95f040cee67e6a183cf9606
Signed-off-by: Tee Ngo <Tee.Ngo@windriver.com>
2021-03-10 17:30:34 -05:00
Yuxing Jiang c659a7f684 Create an API to reinstall a subcloud
This commit creates a REST API to reinstall a subcloud.

In SubcloudController, the tasks includes:
1. Read the subcloud info from dcmanager db, subclouds table.
2. JSONify the data_install from db, generate the new install values.

In SubcloudManager:
1. Check the subcloud availability, software version before reinstall
2. Check the image value, if image doesn't exists, update the image with
iso in dc-vault
3. Run the install command and apply command

API format: PATCH /v1.0/subclouds/<subcloud>/reinstall
-----
Tests:
-----
Happy path:
1. dcmanager subcloud add: a new subcloud with bootstrap values,
deploy config and install values.
2. dcmanager subcloud delete: an existing subcloud.
3. dcmanager subcloud reconfig: an existing subcloud with deploy
config.
4. dcmanager subcloud reinstall: an existing offline subcloud, this
subcloud has image path in data_install in db dcmanager. After the
tasks of reinstall and bootstrap succeed, reconfig this subcloud with
proper deploy config, this subcloud will be online.
5. upload an image to dc-vault using: system --os-region-name
SystemController load-import -a <bootimage.iso> <bootimage.sig>. Then
using dcmanager subcloud reinstall to an existing offline subcloud,
this subcloud has no image path in data_install in db dcmanager. After
the tasks of reinstall and bootstrap succeed, reconfig this subcloud
with proper deploy config, this subcloud will be online.

Unhappy path:
1. dcmanager subcloud reinstall: an existing online subcloud,
reinstall fails.
2. dcmanager subcloud reinstall: an existing subcloud without
data_install value in db, reinstall fails.
3. dcmanager subcloud reinstall: an existing subcloud with
data_install in db, but missing mandatory install value, reinstall
fails.
4. dcmanager subcloud reinstall: an existing subcloud, but its sw
version in db doesn't meet the sw version with system controllers',
reinstall fails.
5. dcmanager subcloud reinstall: an existing subcloud with
data_install in db, but has no image path in data_install, and also
has no right versioned image in dc-vault in system controller,
reinstall fails.

Story: 2007267
Task: 40732
Change-Id: I8be6d8d11e6b4ee02bbcca499ba8869ba76bffaa
Signed-off-by: Yuxing Jiang <yuxing.jiang@windriver.com>
2020-10-09 10:11:35 -04:00
Zuul a307733a52 Merge "CLI command to deploy a subcloud" 2020-06-11 22:30:48 +00:00
Jessica Castelino 4fd65e9913 CLI command to deploy a subcloud
If deployment failed, the user has no option than to delete and
re-add it. If the user was re-adding the subcloud without
re-installing, it would further result in a bootstrap failure.
Thus, to simplify things, a new CLI command is provided to allow
re-deployment. Furthermore, if the user still chooses to delete
the subcloud and re-add it without a re-install, a better error
message is provided asking them to re-install the host.

CLI:
dcmanager subcloud reconfig <id/name> --deploy-config <file>

Test Cases:
1) Successfully add a subcloud with or without deployment option
2) Fail to re-add a subcloud without re-installation after a failed
   deployment
3) Re-deploy with new CLI command after successful and unsuccessful deployment
4) Re-deploy with new CLI command before and after the subcloud is unlocked
5) Test new CLI command by passing wrong parameters

Change-Id: I9fe7e3791e3887160668281048c3c12a7f40c2af
Partial-Bug: 1864756
Signed-off-by: Jessica Castelino <jessica.castelino@windriver.com>
2020-06-10 13:05:27 -04:00
Andreas Jaeger efcfc7a45a Switch to newer openstackdocstheme and reno versions
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems

Update Sphinx version as well.

Disable openstackdocs_auto_name to use 'project' variable as name.

Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.

openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.

See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html

Change-Id: I7da2bdaafe86b9eb930202bef3742571daa90e17
2020-06-04 14:18:06 +02:00
MCamp859 acc710093b Minor edits to test docs promote issue
Change-Id: I08ffc5e57b5b04c59102a6491f2fcdc256f16e0f
Signed-off-by: MCamp859 <maryx.camp@intel.com>
2020-05-11 14:28:28 -04:00
Tao Liu 58a7186bea Support subcloud deploy upload the common files
Add new REST APIs to upload and display the deploy manager
common files on the System Controller.

The deploy manager common files which include playbook,
overrides and helm charts are uploaded to
/opt/platform/deploy/<version>:
/opt/platform/deploy/<version>/deploy_playbook_<original name>
/opt/platform/deploy/<version>/deploy_overrides_<original name>
/opt/platform/deploy/<version>/deploy_chart_<original name>

Modify the subcloud post request to accept the bootstrap-values,
install-values and deploy-config as file contents. The deploy
config file is only used by the deploy manager and it is
uploaded to /opt/dc/ansible.

The information that used to create the overrides for the
playbook are extracted and sent to the dcmanager, which include
bootstrap values, install values and the full path of deploy
file names, if the deploy-config is presented in the request.

Testcases:
REST APIs:
1. curl -X POST -H "X-Auth-Token: $TOKEN" $APIURL/subcloud-deploy \
-F deploy_playbook=@<full path of the playbook name> \
-F deploy_overrides=@<full path of the override file name> \
-F deploy_chart=@full path of the helm chart name>

2. curl -X GET -H "X-Auth-Token: $TOKEN" $APIURL/subcloud-deploy

3. curl -X POST -H "X-Auth-Token: $TOKEN" \
$APIURL/subclouds \
-F bootstrap_values=@<full path of the bootstrap override file> \
-F sysadmin_password=<encoded password> \
-F bootstrap-address=<bootstrap IP>

4. curl -X POST -H "X-Auth-Token: $TOKEN" \
$APIURL/subclouds \
-F bootstrap_values=@<full path of the bootstrap override file> \
-F install_values=@<full path of the install value file> \
-F deploy_config=@<full path of the deploy config file> \
-F sysadmin_password=<encoded password> \
-F bmc_password=<encoded password> \
-F bootstrap-address=<bootstrap IP> \

CLI:
1. dcmanager subcloud-deploy upload \
--deploy-playbook <full path of the playbook name> \
--deploy-chart <full path of the override file name> \
--deploy-overrides <full path of the override file name>

2. dcmanager subcloud-deploy show

3. dcmanager subcloud add --bootstrap-address <IP>  \
--bootstrap-values <full path of the bootstrap override> \
--deploy-config <full path of the deploy config file> \

4. dcmanager subcloud add --bootstrap-address <IP> \
--bootstrap-values <full path of the bootstrap override> \
--install-values <full path of the install value file> \

5.dcmanager subcloud add --bootstrap-address <IP> \
--bootstrap-values <full path of the bootstrap override> \
--install-values <full path of the install value file> \
--deploy-config <full path of the deploy config file> \

Host swact and deploy of a subcloud

Closes-Bug: 1864508

Change-Id: I3ce0da6efb8c2d78a213647789fc6bdb3b348b2d
Signed-off-by: Tao Liu <tao.liu@windriver.com>
2020-04-21 09:09:38 -04:00
albailey 5e884374d2 Adding DistributedCloud subcloud group feature
A new subcloud group feature has been added as a way to
logically group several subclouds.  This would allow a group
of subclouds to be updated in parallel or in serial, or to
limit how many are updated in parallel.

A 'Default' subcloud group is created in all installations,
and all subclouds are automatically members of that
subcloud group unless explicitly updated to reference another.

The Default subcloud group cannot have its name changed, and
other groups cannot use the same name.

A subcloud group that has subclouds in it, cannot be deleted.

Change-Id: Id0f232966c0128ecf6d87f941abcd42ff5a1a5c1
Story: 2007518
Task: 39301
Signed-off-by: albailey <Al.Bailey@windriver.com>
2020-04-14 06:21:06 -05:00
Jessica Castelino e39a56cdc6 Fixed a typo in StarlingX API reference document
Change-Id: Ie317ab71f356bf8c74984e45784c39daea53e7e2
Signed-off-by: Jessica Castelino <jessica.castelino@windriver.com>
2020-03-09 17:02:25 -04:00
Jessica Castelino fe3ef48558 Show OAM Floating IP for Subcloud
Extends the dcmanager subcloud show command to display the floating
OAM IP of the subcloud from the system controller.

Change-Id: Ib421ea65660ed77a241798831c83cbaf1710f9e8
Story: 2007267
Task: 38896
Signed-off-by: Jessica Castelino <jessica.castelino@windriver.com>
2020-03-04 17:51:35 -05:00
Kristal Dale 54ed99eb3c Update landing pages for docs, api-ref, and release notes:
- Use updated project name in titles/text
- Correct text for link to Storyboard (docs)
- Correct capitalization in section headings
- Correct formatting for section headings
- Update project name in link to release notes, api-ref
- Update project name in config for docs/releasenotes/api-ref

Story:2007193
Task:38342

Change-Id: I65d4b92deef90c09f7c1f309bf79e454c570c8a1
Signed-off-by: Kristal Dale <kristal.dale@intel.com>
2020-01-21 16:36:06 -08:00
Kristal Dale 6cd39f8226 Clean up and standardize landing pages
doc index.rst:
1. Update intro sentence to read as a complete sentence
2. Remove unused toctree
3. Correct heading levels (impacting side nav and correct rendering
of content)
4. Remove "Indices and Tables" section: genindex page not used,
search searches only index (not useful here)

api-ref index.rst:
1. Update intro sentence to read as a complete sentence
2. Update text around search link for consistency (move to
follow intro)
3. Add heading before toctree for consistency with other pages

release notes:
1. Standardize page title reST markup
2. Remove search (make consistent with other openstack release note
pages)

Story: 2004737
Task: 28803

Change-Id: I11ba3784a5d50953d62f0bc4a08f3f2b308da6b5
Signed-off-by: Kristal Dale <kristal.dale@intel.com>
2019-01-08 15:52:04 -08:00
Abraham Arce 5b01572a60 [Doc] openstackdocstheme starlingxdocs theme
Enable starlingxdocs theme support for:

- Documentation
- Release Notes
- API Reference

Add zuul check and gate job:

- build-openstack-api-ref

Change-Id: I33252608b94b08b2e70511a76744b82c2d0fc937
Signed-off-by: Abraham Arce <abraham.arce.moreno@intel.com>
2018-10-22 14:34:48 +00:00