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

[release-0.3] Fix login race #226

Merged
merged 18 commits into from
Jan 28, 2024

Conversation

orelmisan and others added 18 commits January 28, 2024 13:25
Currently, the mounting of hugepages is performed
by the `/usr/bin/dpdk-checkup-boot.sh` script
which is executed on every boot.

Move it to the VM configuration phase, so it would be
done automatically by the operating system.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit e9eabe1)
This commit adds a new configmap that will be consumed by the
vmi-under-test in future commits.
The create and delete configmap functions are generalized to accept both
configmaps.
The unit test is also generalized in order to include any configmap
deleted/created.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit f6686af)
Currently the configmap is mounted but has no data.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit d63b317)
There is no need to pass the tuned-adm-set-marker file to the function.
Removing it from the service and hard-coding it to the service script on
both VM image scripts.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit 5633c4d)
Currently the VM guests are configured on a service added on the
customize-vm script created in the image building process.
There is no real need for the script to run on that context, and it is
easier to manage if it runs as part of the cloud-init context.
This commits:
- copies the script to a checkup function.
- adds the boot script to the traffic-gen and vmi-under-test VMs
- mounts the script with the correct permissions.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit 9dfcf78)
Currently the VM guests are configured on a service added on the
customize-vm script created in the image building process.
There is no real need for the script to run on that context, and it is
easier to manage if it runs as part of the cloud-init context.
This commits:
- Runs the boot script on the cloud-init context.
- Removes it from the images customize-vm scripts.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit a5d4f68)
Currently, `driverctl` is executed on every boot.
There is no need to run it before we configure
`tuned-adm profile` and reboot the VM.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit b9c39cc)
The traffic-gen's `customize-vm` script is the same
as the one used by the VM-under-test, with an
additional step of TRex installation.

Reorder the file so the two scripts would be aligned.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit 2e4df10)
Currently, when logging in as root - the login operation
fails because of a mistake in the directory name expected by
`loggedInPromptRegex`.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit 9108b98)
Currently, the checkup creates a `cloud-user` user
using cloud-init, and logs in to the VMs using its
credentials.
Immediately after logging in, the checkup issues the
`sudo su` command, thus effectively running as the root user.

Logging in as root simplifies the login operation, and remove
problems that can occur when certain assumptions are made when
performing the `sudo su` step - for example:
1. Not expecting the sudo warning message
2. Not expecting to enter the user's password again.

Also remove the creation of `cloud-user` from cloud-init, since
it is no longer needed.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit f646c65)
`configureConsole` is only used in login.go.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit 5161cae)
Since we log in as root, there is no need to have
support for sudo.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit 85a5b09)
Since we only log in as `root` - simply `LoginToCentOS`
and rename it to match its abilities.

Signed-off-by: Orel Misan <omisan@redhat.com>
(cherry picked from commit 6b627dc)
Since the checkup relies on the boot script finishing, it is better to
not fail on error.
Replacing the "-e" option with a "-x" for better verbosity should the
checkup fail.
Setting the "-x" flag makes the script run visible in /var/log/cloud-init-output.log

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit 3d063e7)
After initially configuring the VM, a reboot is performed. However it is
not immediatly taking affect. To make sure that the script exits right
after the reboot is set, initiating manual exit from the script.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit 9b199c4)
This commit enables the guest-agent-exec option on the guest, in order
to use the probe polling option, that will be introduced in future
commits.

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit 91c401b)
In order for the VMI to be properly configured for DPDK, adding a new
marker file that will be polled by guest-agent-exec in future commits.
Also setting the correct selinux context of the marker file so it will
be properly polled [0].

[0]
https://kubevirt.io/user-guide/virtual_machines/liveness_and_readiness_probes/#defining-guest-agent-ping-probes

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit beb3ede)
Currently the checkup setup only waits for the VMI to finish "booting",
i.e. the guest agent service to be ready.
However this is not enough in order to ensure that the VMI has been
configured, a procedure currently done on the cloud-init service.
When the configuration is complete, the script configuring the guest in
the cloud-init service adds a marker file.
Changing the wait condition to "ready" is stronger than waiting for
"guest-agent", since the guest-agent ping needs guest agent in order to
set the VMI to ready.

This commit:
- introduces a new waiting mechanism, using guest-agent-ping probe [0]
to poll-wait the guest until the file is present, and only then sets the
VMI ready condition to true.
- adds a wait for the VMI ready condition to be true.
- removed the now unnecessary wait for guest-agent-ready condition.

[0]
https://kubevirt.io/user-guide/virtual_machines/liveness_and_readiness_probes/#defining-guest-agent-ping-probes

Signed-off-by: Ram Lavi <ralavi@redhat.com>
(cherry picked from commit ee2b433)
@orelmisan
Copy link
Member Author

After this PR, release-0.3 will be equal to current main.

Copy link
Collaborator

@RamLavi RamLavi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@orelmisan orelmisan merged commit 36ad82b into kiagnose:release-0.3 Jan 28, 2024
6 checks passed
@orelmisan orelmisan deleted the release-0.3-login branch January 28, 2024 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants