Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oci supported #6405

Closed

Conversation

adriengentil
Copy link
Contributor

@adriengentil adriengentil commented Jun 5, 2024

rccrdpccl and others added 30 commits March 27, 2024 18:48
…ed (openshift#6116)

Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
…6 spoke (openshift#6113)

* Update CBO dependency to 82df158cd2e9

This includes
openshift/cluster-baremetal-operator#380 which
is required for a single stack ipv6 cluster to be deployed from a
dual-stack hub when the hub is a single node.

https://issues.redhat.com/browse/MGMT-17354

* Update call to GetIronicIPs to use a provisioning pointer

This was changed in openshift/cluster-baremetal-operator#380

Resolves https://issues.redhat.com/browse/MGMT-17354
Co-authored-by: danmanor <infrastructure-operator@redhat.com>
Co-authored-by: red-hat-konflux <123456+red-hat-konflux[bot]@users.noreply.github.com>
…ift#6125)

Openshift releases earlier than 4.14 do not support the
ImageDigestMirrorSet so configure ImageContentSources when building
the install-config for these versions.
…run when the instance becomes leader instead of skipping if it not (openshift#6115)
Plain HTTP is supported, and this adds doc
on how to use it.
…penshift#6149)

IPv6 L2 connectivity check uses nmap.  nmap uses NDP (Network Discovery
Protocol) to check L2 connectivty to IPv6 hosts. There are cases that
NDP response does not arrive or it is not captured by nmap which means
that the system assumes there is no connectivity to the host.  However,
there might be L3 connectivity (ping) to the same host.
So change adds fallback for IPv6 L2 connectivity.  In case there is
failure in L2 connectivity to IPv6 host and success in L3 connecivity to
the same host, the host is assumed connected on L2, providing that the
remote address is part of the L2 subnet being checked.
Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
…if MCE is not selected (openshift#6150)

Signed-off-by: Riccardo Piccoli <rpiccoli@redhat.com>
Co-authored-by: danmanor <infrastructure-operator@redhat.com>
…Release Syncer - if there are release images already in the DB, continue using the stale data instead of failing / truncating the table (openshift#6145)
Co-authored-by: red-hat-konflux <123456+red-hat-konflux[bot]@users.noreply.github.com>
Now that hypershift is compiled with CGO_ENABLED=1
the hypershift CLI fails with
/lib64/libc.so.6: version `GLIBC_2.32' not found (required by hypershift)
/lib64/libc.so.6: version `GLIBC_2.34' not found (required by hypershift)

So instead we'll try to run it in a pod as we do for
connected tests.
Hosts were incorrectly marked as connected to each other even
if there were no IP address connections found.
Presently, we import The Local ACM Hub Cluster on the startup of
assisted-service.

This is causing issues with the finalizers on the ClusterDeployment and
AgentClusterInstall objects that are created as part of this process.

When a user attempts to delete the AgentServiceConfig, this will result
in the assisted-service being taken down and this renders it unable to
handle the finalizers on the AgentClusterInstall and ClusterDeployment.

The remedy for this is to move the creation and deletion of these
objects to an independent controller that will place a finalizer on
AgentServiceConfig, this will allow the AgentClusterInstall and
ClusterDeployment to be removed prior to removal of the service.
…6199)

Co-authored-by: danmanor <infrastructure-operator@redhat.com>
…itecture of both release and OS images to comply with ABI current behavior (openshift#6190)
…age using major.minor OpenShift version to latest non-beta release image if exists, or latest beta release image otherwise (openshift#6185)
…nshift#6142)

https://issues.redhat.com/browse/MGMT-17313
Previously, only day 2 workers had BMH and Machines created for
them. We want the same behavior for day 2 control plane nodes
(added in https://issues.redhat.com/browse/MGMT-8578) so that
their CSRs will be approved automatically.
openshift#6124)

BMH is the custom resource that is used to add a new host. Agent on the
other hand is created automatically when a host registers. Since there
is a need to control agent labels the following agent label support was
added:

In order to add an entry that controls agent label, a new BMH annotation
needs to be added.
The annotation key is prefixed with the string
'bmac.agent-install.openshift.io.agent-label.'.  The remainder of the
annotation is considered the label key.
The value of the annotation is identical to the agent label value.

Note: agent labels cannot be deleted by usage of BMH annotations.
…Release Syncer - if there are release images already in the DB, continue using the stale data instead of failing / truncating the table (openshift#6145) (openshift#6186)
Open installation of OCP on iSCSI boot volume to all platforms.

Remove `ip=ibft` from the kernel arguments as it prevent proper network
configuration when several NICs are in use. RHCOS team recommend to
leave DHCP configuration.
…ng to pre-release suffix as well instead of just base version (openshift#6209)
…openshift#6212)

Bump x/net to 0.24.0 to mitigate CVE-2023-45288 (api go.mod)
Forgot to deal with api/go.mod, this PR addresses that.
jupierce and others added 18 commits May 23, 2024 22:21
…penshift#6346)

The following vulnerabilities are fixed by pinning transitive dependencies:
- https://snyk.io/vuln/SNYK-PYTHON-REQUESTS-6928867

Co-authored-by: snyk-bot <snyk-bot@snyk.io>
…base (openshift#6347)

* Add separate Dockerfile for assisted-service with an el8 base

This is required to ensure that users have an option to install FIPS
clusters for versions where the installer is linked against el8 crypto
libraries.

The resulting image will be deployed by the operator when the user
indicates that clusters requiring the el8 libraries will be installed in
FIPS mode (versions < 4.16).

Resolves https://issues.redhat.com/browse/MGMT-17896

* Use a build arg to determine the base image

Instead of a separate Dockerfile for the el8 image an single build arg
will determine the base image.
* Use envconfig directly for release image mirror

This is more clear if it's fetched directly from the ENV in the package
rather than being set in main.

* Remove ServiceBaseURL from ignition generator

It's not used when running the installer

* Remove ServiceIPs

This was only ever used for the on-prem ISO which was never released as
a product and was eventually removed.

* Move ABI tls certs override into generator package

This is only used in the generator package so it can be a part of its
config directly rather than in main.

* Remove auth handler from install config generator

This was only used for the auth type and that isn't being used in the
function that it is passed to.

* Remove bonus interface

ISOInstallConfigGenerator and InstallConfigGenerator were exactly the
same

* Stop saving failed cluster dirs

The error handling here is incorrect (it was checking the error from the
S3 upload) and to my knowledge no one has ever looked in this saved
cluster directory to debug an issue.
…s and etcd restrictions (openshift#6257)

When none platform is in use, if there is ambiguity in node-ip assignment,
then incorrect assignment might lead to installation failure. This happens
when etcd detects that the socket address from an etcd node does not match the
expected address in the peer certificate. In this case etcd rejects such connection.

Example: assuming two networks - net1 and net2.
master node 1 has 1 address that belongs to net1.
master node 2 has 2 addresses. one that belongs to net 1, and another that belongs to net 2
master node 3 has 1 address that belongs to net 1.
If the selected node-ip of master node 2 belongs to net 2, then when it will create a connection
with any other master node, the socket address will be the address that belongs to net 1.
Since etcd expects it to be the same as the node-ip, it will reject the connection.

This can be solved by node-ips selection that will not cause such a conflict.
Node ips assignment should be done through ignition.
To correctly set bootstrap ip, the machine-network for the cluster
must be set to match the selected node-ip for that host.

MGMT-17701: Add capability to calculate none platform node-ips based on L3 connected addresses and connectivity

Calculate the node-ips for none platform cluster.  Node ip calculation
is actually calculation of the node-ip, hint, and cidr.
Node-ip is the ip address that exists on the host that was selected as
the node-ip.
Hint is actually an IP address that does not exist on the host, but must
belong to the subnet of the node-ip.
Cidr is the subnet in cidr notation that the node-ip and hint belong to.
Node-ip calculation is either done for all cluster hosts or none of
them.

MGMT-17702: Modify ignition to use calculated node-ips for none platform

In order to set node-ip, ignition is modified.  A file called
/etc/default/nodeip-configuration contains the hint as was set by
node-ip generation.
In addition the bootstrap-ip is set in ignition as was set in node-ip
generation.  This is set as environment variable called
"OPENSHIFT_INSTALL_BOOTSTRAP_NODE_IP".

MGMT-17703: Modify machine-network based on calculated node-ips

The etcd in boostrap uses he machine-network to set the IP address.
Therefore during install-config generation the machine-network may be
replaced by the cidr from the node-ip generation.
* Refactor ignition_file_contains_http_proxy unit test to use DescribeTable

The change is done in order to avoid duplicate code.

Signed-off-by: Alona Paz <alkaplan@redhat.com>

* Expand ignition_file_contains_http_proxy to check agent.service proxy

This commit expands the ignition_file_contains_http_proxy existing unit
test to verify the agent.service proxy setting in the ignition file are
correct.

Signed-off-by: Alona Paz <alkaplan@redhat.com>

* MGMT-17849: escape '%' in agent.service proxy urls

The proxy url format is http://<user>:<password>@<ipaddr>:<port>
The user and password may contain url escaped characters
(starting with '%').

systemd rejects unknown '%' specifiers on unit configuration [1].
Therefore, agent.service proxy urls should escape '%' -> '%%'
to avoid being rejected.

Environment=HTTP_PROXY=http://usr%40name:passwd%5D@10.10.1.1:3128

should become

Environment=HTTP_PROXY=http://usr%%40name:passwd%%5D@10.10.1.1:3128

[1] https://github.com/systemd/systemd/blob/a1b2c92d8290c76a29ccd0887a92ac064e1bb5a1/NEWS#L10

Signed-off-by: Alona Paz <alkaplan@redhat.com>

* Add ignition_file_contains_asterisk_no_proxy as an entry to a similar test

Signed-off-by: Alona Paz <alkaplan@redhat.com>

---------

Signed-off-by: Alona Paz <alkaplan@redhat.com>
Currently or `ocm/client` package supports authentication to OCM using
an offline token via the `OCM_SELF_TOKEN` environment variable. But the
OCM team has deprecated this authentication mechanism and will remove
it in the future. The alternative is to use a client identifier and
client secret, which is what we use in the SaaS environment. This patch
disables by default that support, and will make the server fail with an
explicit error message if it is used. Users that really need to use it will
need to explicitly enable it setting the `ACKNOWLEDGE_DEPRECATED_OCM_SELF_TOKEN`
environment variable to `yes`. In that case the server will start, but a
warning will be written to the log.

Signed-off-by: Juan Hernandez <juan.hernandez@redhat.com>
…present on cluster updates (openshift#6359)

When a cluster is single stack and DHCP VIP allocation is off, the
machine-network is calculated by selecting a host network that the VIPs
belong to. So machine network update is forbidden in this case.
This is undesirable for KubeAPI where the machine-network is specified
in a custom resource.
So this change allows machine-network update if the update arrived from
KubeAPI (non interactive).
…shift#6349)

A user should request the EL8 image when they are running in a
FIPS-enabled cluster and intend to only install OCP versions <4.16.

This can be done by setting the
`agent-install.openshift.io/service-image-base` annotation to `el8` on
the AgentServiceConfig resource

Resolves https://issues.redhat.com/browse/MGMT-17898
…ft#6378)

Co-authored-by: danmanor <infrastructure-operator@redhat.com>
…nnected environment (openshift#6332)

Pass a flag in the installation command instructing the controller if notify reboots functionality
is enabled.
The flag is enabled only if kube-api is not enabled in the service
…es for pull secret validation instead of the mirror one (openshift#6377)
…nnected environment (openshift#6333)

Fot day2 hosts the functionality is removed since we don't want to
enable it for kube-api

Revert "MGMT-15902: Trigger reboots for node event when day2 node moves to done (openshift#5648)"

This reverts commit 652202c.
…enshift#6386)

Previously this code would use the dynamic binary for 4.16 nighlies
this change ensures all 4.16 releases will get the static binary when
FIPS is not enabled.

Resolves https://issues.redhat.com/browse/OCPBUGS-34701
Remove OCI from technology preview as it is now a supported integration.
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 5, 2024
@openshift-merge-robot
Copy link

PR needs rebase.

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.

@openshift-ci openshift-ci bot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jun 5, 2024
@openshift-ci openshift-ci bot added api-review Categorizes an issue or PR as actively needing an API review. kind/dependency-change Categorizes issue or PR as related to changing dependencies labels Jun 5, 2024
Copy link

openshift-ci bot commented Jun 5, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adriengentil

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:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 5, 2024
Copy link

openshift-ci bot commented Jun 5, 2024

@adriengentil: 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-metal-assisted-day2 b0bfe4a link true /test e2e-metal-assisted-day2
ci/prow/verify-generated-code b0bfe4a link true /test verify-generated-code
ci/prow/images b0bfe4a link true /test images
ci/prow/e2e-metal-assisted-static-ip-suite b0bfe4a link true /test e2e-metal-assisted-static-ip-suite
ci/prow/e2e-metal-assisted-cnv b0bfe4a link true /test e2e-metal-assisted-cnv
ci/prow/lint b0bfe4a link true /test lint
ci/prow/unit-test b0bfe4a link true /test unit-test
ci/prow/e2e-metal-assisted-ipv4v6 b0bfe4a link true /test e2e-metal-assisted-ipv4v6
ci/prow/e2e-metal-assisted-single-node b0bfe4a link true /test e2e-metal-assisted-single-node
ci/prow/e2e-metal-assisted-lvm b0bfe4a link true /test e2e-metal-assisted-lvm
ci/prow/e2e-metal-assisted-odf b0bfe4a link true /test e2e-metal-assisted-odf
ci/prow/e2e-metal-assisted-onprem b0bfe4a link true /test e2e-metal-assisted-onprem
ci/prow/subsystem-aws b0bfe4a link true /test subsystem-aws

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-review Categorizes an issue or PR as actively needing an API review. approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/dependency-change Categorizes issue or PR as related to changing dependencies needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.