OSASINFRA-3730: Add support for storing OpenStack CA bundles

[stephenfin]

If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780, this allows us to dole out the bundle to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a) start generating the configuration file in the new format expected by cluster-cloud-controller-manager-operator and (b) stop generating an old secret that only the old, now-removed in-tree OpenStack cloud provider needed and used.

EDIT: I have deferred the above changes to a different PR.

[openshift-ci-robot]

@stephenfin: This pull request references OSASINFRA-3657 which is a valid jira issue.

In response to this:

If a CA bundle is required to talk to your OpenStack then obviously all
services that talk to the cloud need to have both credentials and said bundle.
Currently, these users can get their credentials via cloud credential operator,
but they need to source their CA bundle from elsewhere (typically by extracting
it from the cloud controller manager's configuration). This makes configuration
of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the
root secret on OpenStack. When coupled with the changes introduced in
openshift/cloud-credential-operator#780, this allows us to dole out the bundle
to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a)
start generating the configuration file in the new format expected by
cluster-cloud-controller-manager-operator and (b) stop generating an old secret
that only the old, now-removed in-tree OpenStack cloud provider needed and
used.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@stephenfin: This pull request references OSASINFRA-3657 which is a valid jira issue.

In response to this:

If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780, this allows us to dole out the bundle to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a) start generating the configuration file in the new format expected by cluster-cloud-controller-manager-operator and (b) stop generating an old secret that only the old, now-removed in-tree OpenStack cloud provider needed and used.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[stephenfin]

/hold

Will wait for 4.19 for this.

[mandre]

/retest

[openshift-ci-robot]

@stephenfin: This pull request references OSASINFRA-3730 which is a valid jira issue.

In response to this:

If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780, this allows us to dole out the bundle to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a) start generating the configuration file in the new format expected by cluster-cloud-controller-manager-operator and (b) stop generating an old secret that only the old, now-removed in-tree OpenStack cloud provider needed and used.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[EmilienM]

nice cleanup
/lgtm

[openshift-ci-robot]

@stephenfin: This pull request references OSASINFRA-3730 which is a valid jira issue.

In response to this:

If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780, this allows us to dole out the bundle to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a) start generating the configuration file in the new format expected by cluster-cloud-controller-manager-operator and (b) stop generating an old secret that only the old, now-removed in-tree OpenStack cloud provider needed and used.

This needs to wait for the CCO change to be approved before we merge this.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[EmilienM]

/retest

[EmilienM]

/retest

[openshift-ci-robot]

@stephenfin: This pull request references OSASINFRA-3730 which is a valid jira issue.

In response to this:

If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.

Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780, this allows us to dole out the bundle to anyone who asks for it via a CredentialsRequest.

While we're here, we also tweak the configuration for the cloud provider to (a) start generating the configuration file in the new format expected by cluster-cloud-controller-manager-operator and (b) stop generating an old secret that only the old, now-removed in-tree OpenStack cloud provider needed and used.

EDIT: I have deferred the above changes to a different PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[stephenfin]

/unhold

The CCO change has merged.

[stephenfin]

/retest

[stephenfin]

/test e2e-openstack-proxy

[openshift-ci]

@stephenfin: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-vsphere-host-groups-ovn-custom-no-upgrade	5e359c0dbce90c7f7d597a2c81ee46c883bdc74d	link	false	/test e2e-vsphere-host-groups-ovn-custom-no-upgrade
ci/prow/e2e-azure-ovn	5e359c0dbce90c7f7d597a2c81ee46c883bdc74d	link	true	/test e2e-azure-ovn
ci/prow/e2e-azure-ovn-upi	5e359c0dbce90c7f7d597a2c81ee46c883bdc74d	link	false	/test e2e-azure-ovn-upi
ci/prow/e2e-gcp-ovn	5e359c0dbce90c7f7d597a2c81ee46c883bdc74d	link	true	/test e2e-gcp-ovn

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[stephenfin]

/test e2e-openstack-proxy

[mandre]

/lgtm
/approve

[patrickdillon]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mandre, patrickdillon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [patrickdillon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[stephenfin]

/label acknowledge-critical-fixes-only

This is low risk since it's purely additive.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-installer-altinfra
This PR has been included in build ose-installer-altinfra-container-v4.20.0-202503282312.p0.g2376a18.assembly.stream.el9.
All builds following this will include this PR.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-installer-terraform-providers
This PR has been included in build ose-installer-terraform-providers-container-v4.19.0-202503282312.p0.g2376a18.assembly.stream.el9.
All builds following this will include this PR.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-baremetal-installer
This PR has been included in build ose-baremetal-installer-container-v4.20.0-202503282312.p0.g2376a18.assembly.stream.el9.
All builds following this will include this PR.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-installer-artifacts
This PR has been included in build ose-installer-artifacts-container-v4.19.0-202503282312.p0.g2376a18.assembly.stream.el9.
All builds following this will include this PR.