search

openshift / sriov-network-operator

SR-IOV Network Operator
Apache License 2.0
119 stars 106 forks source link

OCPBUGS-41829: openstack: dynamically mount the config-drive #1004

Closed EmilienM closed 1 month ago

EmilienM commented 2 months ago

When we want to use config-drive in immutable systems, very often the config-drive is only used at boot and then umounted (e.g. ignition does this).

Later when we want to fetch Metadata from the config drive, we actually have to mount it.

In this PR, I'm adding similar code than coreos/ignition where we dynamically mount the config-drive is the device was found with the right label (config-2 or CONFIG-2 as documented in OpenStack). If the device is found, we mount it, fetch the data and umount it.

openshift-ci-robot commented 2 months ago

@EmilienM: This pull request references Jira Issue OCPBUGS-41829, which is invalid:

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to [this](https://github.com/openshift/sriov-network-operator/pull/1004): >When we want to use config-drive in immutable systems, very often the >config-drive is only used at boot and then umounted (e.g. ignition does >this). > >Later when we want to fetch Metadata from the config drive, we actually >have to mount it. > >In this PR, I'm adding similar code than coreos/ignition where we >dynamically mount the config-drive is the device was found with the >right label (config-2 or CONFIG-2 as documented in OpenStack). If the >device is found, we mount it, fetch the data and umount it. > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fsriov-network-operator). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
EmilienM commented 2 months ago

/hold the upstream PR hasn't merged yet. I'm using that manual backport to run our CI job.

I want to see the outcome for e2e-openstack-nfv-config-drive.

openshift-ci[bot] commented 2 months ago

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: EmilienM Once this PR has been reviewed and has the lgtm label, please assign zshi-redhat for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/openshift/sriov-network-operator/blob/master/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
EmilienM commented 2 months ago

/jira refresh

openshift-ci-robot commented 2 months ago

@EmilienM: This pull request references Jira Issue OCPBUGS-41829, which is valid.

3 validation(s) were run on this bug * bug is open, matching expected state (open) * bug target version (4.18.0) matches configured target version for branch (4.18.0) * bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact: /cc @zhaozhanqi

In response to [this](https://github.com/openshift/sriov-network-operator/pull/1004#issuecomment-2346185625): >/jira refresh Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fsriov-network-operator). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
EmilienM commented 2 months ago

It looks like it didn't work as expected:

2024-09-12T14:46:44.698567851Z  INFO    daemon/writer.go:59 getCheckPointNodeState()
2024-09-12T14:46:44.698600431Z  INFO    daemon/writer.go:65 CreateOpenstackDevicesInfo()
2024-09-12T14:46:44.698609192Z  INFO    openstack/openstack.go:114  reading OpenStack meta_data from config-drive
2024-09-12T14:46:44.701726268Z  INFO    openstack/openstack.go:116  getting OpenStack meta_data from metadata server
2024/09/12 14:46:44 [DEBUG] GET http://169.254.169.254/openstack/2018-08-27/meta_data.json
2024-09-12T14:46:44.860127011Z  INFO    openstack/openstack.go:116  getting OpenStack network_data from metadata server
2024/09/12 14:46:44 [DEBUG] GET http://169.254.169.254/openstack/2018-08-27/network_data.json

https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_sriov-network-operator/1004/pull-ci-openshift-sriov-network-operator-master-e2e-openstack-nfv-config-drive/1834211009112313856/artifacts/e2e-openstack-nfv-config-drive/gather-extra/artifacts/pods/openshift-sriov-network-operator_sriov-network-config-daemon-dwkwl_sriov-network-config-daemon.log

EmilienM commented 2 months ago

This time it read the config drive, but the job failed when creating the SRIOV network policy. I'll retest the job.

2024-09-12T22:31:21.02913626Z   INFO    daemon/writer.go:65 CreateOpenstackDevicesInfo()
2024-09-12T22:31:21.029146361Z  INFO    openstack/openstack.go:118  reading OpenStack meta_data from config-drive
2024-09-12T22:31:21.057448323Z  INFO    openstack/openstack.go:225  found config drive device   {"device": "/dev/sr0"}
2024-09-12T22:31:21.065428364Z  INFO    openstack/openstack.go:229  mounted config drive %s into %s {"/dev/sr0": "/tmp/sriov-configdrive2821721804"}
2024-09-12T22:31:21.066344839Z  INFO    openstack/openstack.go:118  reading OpenStack network_data from config-drive
2024-09-12T22:31:21.079312593Z  INFO    openstack/openstack.go:234  umounted config drive   {"path": "/tmp/sriov-configdrive2821721804"}

Note that with metadata it worked fine on the other job:

2024-09-12T22:29:03.387109403Z  INFO    daemon/writer.go:65 CreateOpenstackDevicesInfo()
2024-09-12T22:29:03.387118413Z  INFO    openstack/openstack.go:118  reading OpenStack meta_data from config-drive
2024-09-12T22:29:03.406026696Z  ERROR   openstack/openstack.go:340  GetOpenStackData(): non-fatal error getting OpenStack data from config drive    {"error": "error finding config drive device: unable to run blkid: exit status 2"}
2024-09-12T22:29:03.406055927Z  INFO    openstack/openstack.go:121  getting OpenStack meta_data from metadata server
2024/09/12 22:29:03 [DEBUG] GET http://169.254.169.254/openstack/2018-08-27/meta_data.json
2024-09-12T22:29:04.14953728Z   INFO    openstack/openstack.go:121  getting OpenStack network_data from metadata server
2024/09/12 22:29:04 [DEBUG] GET http://169.254.169.254/openstack/2018-08-27/network_data.json

So there is no regression with this PR.

/test e2e-openstack-nfv-config-drive

EmilienM commented 2 months ago

/cc MaysaMacedo MiguelCarpio mandre

EmilienM commented 2 months ago

/test e2e-openstack-nfv-config-drive

EmilienM commented 2 months ago

/test e2e-openstack-nfv e2e-openstack-nfv-config-drive

EmilienM commented 2 months ago

/test e2e-openstack-nfv /test e2e-openstack-nfv-config-drive

openshift-ci[bot] commented 2 months ago

@EmilienM: The following test 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-openstack-nfv-hwoffload b9d15c832f6e33652b111f92f88db963805aa2ea link false /test e2e-openstack-nfv-hwoffload

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).
EmilienM commented 2 months ago

/test e2e-openstack-nfv

openshift-ci-robot commented 1 month ago

@EmilienM: This pull request references Jira Issue OCPBUGS-41829. The bug has been updated to no longer refer to the pull request using the external bug tracker. All external bug links have been closed. The bug has been moved to the NEW state.

In response to [this](https://github.com/openshift/sriov-network-operator/pull/1004): >When we want to use config-drive in immutable systems, very often the >config-drive is only used at boot and then umounted (e.g. ignition does >this). > >Later when we want to fetch Metadata from the config drive, we actually >have to mount it. > >In this PR, I'm adding similar code than coreos/ignition where we >dynamically mount the config-drive is the device was found with the >right label (config-2 or CONFIG-2 as documented in OpenStack). If the >device is found, we mount it, fetch the data and umount it. > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fsriov-network-operator). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
EmilienM commented 1 month ago

i'm happy with the tests results, I'll wait for the upstream PR to merge and then wait for a downstream sync from SNO maintainers.