Fix oidc remote cloudrc path - #1453
Closed
afaranha wants to merge 38 commits into
Closed
Conversation
The scp command constructed from the SSH command by replacing "ssh" with "scp" does not account for IPv6 addresses. When the controller host is an IPv6 address (e.g. 2620:cf:cf:aaaa::70), scp interprets the colons as the host:path separator, causing it to connect to a bogus IPv4 address derived from the first octet. Fix by splitting the SSH command into the scp options and the host, then wrapping the host in square brackets for the scp remote path. This is compatible with both IPv4 and IPv6 addresses since brackets around an IPv4 address are valid in scp. Update both the test role and the user-facing documentation. Co-authored-by: Cursor <cursoragent@cursor.com>
LDAP adoption testing will add a ldap domain to keystone. This ldap connection will be to the freeipa server setup for tlse environments on a multinode adoption job. Jira: https://issues.redhat.com/browse/OSPRH-6861
Following the same config as hci scenario
…ion-multinode keystone ldap adoption testing
…option_test Test OIDC after adoption
…p_ip_delta Update ip vip in controllers to avoid conflict ip with vip undercloud
…tackdataplane-typos removed extra spaces and added note about DNS
Update uni07eta adoption scenario for MTU 9000 and external network change. All network MTUs set to 9000 to match greenfield. External network changed from VLAN 218 to VLAN 99 to match greenfield, with ospbr-218 handling the VLAN 218 provider network. Related-Issue: #OSPRH-28563 Assisted-by: Claude Opus 4.6 Signed-off-by: Renjing Xiao <rxiao@redhat.com>
The undercloud ctlplane_vip was set in scenario files but never used by any service endpoint — they all use ctlplane_ip instead. The consumer in ci-framework's adoption_osp_deploy role has been removed in openstack-k8s-operators/ci-framework#4019. This removes the now-unnecessary ctlplane_vip key from the undercloud section in all 12 scenario files. The overcloud VIPs in vips_data.yaml files are unrelated and remain untouched. Depends-On: openstack-k8s-operators/ci-framework#4019 Related-Issue: #OSPRH-17418 Co-authored-by: Cursor <cursoragent@cursor.com>
For test IP range uses: start=192.168.122.171,end=192.168.122.250 so to avoid IP conflict, it needs to change the current IP bridge of ceph. In ci-framework-job files, IPs from .106 are assigned for ceph but it seems that it is not used.
This pull request introduces at-rest data encryption for Ceph OSDs within Hyperconverged Infrastructure (HCI) environments. By modifying the OSD specification, the HCI nodes will automatically have their underlying storage drives encrypted.
…ph_ip Update the IP brigde for ceph to avoid conflict with test IP range
…ChangeMastertoBridge changed master to bridge
…t-description-upstream syncing short descriptions with downstream repo
…nk-to-ibm replaced link with ibm link
…crypted Enabled LUKS encryption for Ceph OSD in HCI scenarios
…e-undercloud-ctlplane-vip Remove unused undercloud ctlplane_vip from scenario files
…scp-ipv6-brackets ovn_adoption: fix scp with IPv6 addresses in cluster-to-standalone
The post-adoption ironic instance provisioning task in nova_verify.yaml can fail with quota exceeded (HTTP 403) when the adopted environment already uses all available instances (e.g. uni04delta-ipv6 with 10 VMs from the source cloud at the default quota of 10). Set the instance quota correctly from the start in pre_launch_ironic.bash by reading the current quota and adding headroom for the pre-adoption and post-adoption test instances. The quota carries over through the Nova database migration during adoption, so the post-adoption provisioning step no longer hits the limit. Also add ironic_post_adoption_create_instance variable (default true) to allow scenarios to skip the post-adoption provisioning step entirely. Co-authored-by: Cursor <cursoragent@cursor.com>
…-verify-ironic-post-adoption-guard nova_verify, pre_launch_ironic: fix ironic post-adoption provisioning
…sibleuser-to-root updated ansibleUser to tripleo-admin
…7-AddSudo added sudo to bootstrap command
Commit 824d9ed replaced sleep-based BGP workarounds with a retry loop that checks connectivity to the podified MariaDB, but did not add an equivalent check for the source TripleO Galera nodes. With BGP, the route to the mariadb-copy-data pod may take a few seconds to be advertised, causing the subsequent WSREP sync check to fail with "ERROR 2002 (HY000): Can't connect to MySQL server" (EINPROGRESS). Add a retry-loop task that verifies TCP connectivity to every TripleO Galera member via 'select 1;' before running the non-retrying WSREP sync check. Also update the documentation procedure to include this new connectivity check step and fix the BGP note wording to correctly describe route advertisement direction. Assisted-By: Claude (claude-opus-4.6)
Additionally, update the basic checkout and setup-python actions to non-EOL releases. Assisted-by: goose+gemini
…ctions Pin Github actions to SHAs
Add external Ceph deployment to the uni05epsilon multi-cell adoption scenario, following the uni04delta pattern. The Ceph cluster is deployed on the cell1 and cell2 compute nodes (which have OSD disks) as an external cluster before the TripleO overcloud deploy. All three stacks (overcloud, cell1, cell2) reference the external-ceph environment and generated credentials. Changes: - Add ceph_inventory.yaml targeting cell1/cell2 computes - Add osd_spec.yaml for OSD device configuration - Add pre_oc_run hooks to overcloud stack: setup ceph nodes, deploy ceph cluster, create external ceph parameters - Add external-ceph.yaml environment to all three stacks Related: OSPNW-1658 Co-authored-by: Cursor <cursoragent@cursor.com>
…wait-for-connectivity-to-tripleo-galera mariadb_copy: wait for connectivity to TripleO Galera before sync check
Enable Ceph for uni05epsilon adoption scenario
Update uni07eta adoption config MTU to 9000
OIDC tests can run into issues due to the
federation_oidc_cloudrc_remote_path var, it can try to access the
/home/root folder, which doesn't exist.
This patch will set federation_oidc_cloudrc_remote_path to
/root/ci-framework-data/tmp/{{ federation_oidc_cloudrc_filename }}
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
The |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OIDC tests can run into issues due to the
federation_oidc_cloudrc_remote_path var, it can try to access the /home/root folder, which doesn't exist.
This patch will set federation_oidc_cloudrc_remote_path to /root/ci-framework-data/tmp/{{ federation_oidc_cloudrc_filename }}