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

OCPBUGS-16227: make sure sshKey are not emptied out on firstboot #3829

Merged
merged 1 commit into from
Aug 3, 2023

Conversation

cdoern
Copy link
Contributor

@cdoern cdoern commented Jul 29, 2023

re-implement fix for sshKeys without adding them to ignition passwd

I want to run tests on this to see what breaks and also run the hypershift conformance tests, just so we don't burn ourselves twice!

sshKeys should not be removed from nodes upon firstboot.

@openshift-ci-robot openshift-ci-robot added jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. labels Jul 29, 2023
@openshift-ci-robot
Copy link
Contributor

@cdoern: This pull request references Jira Issue OCPBUGS-16227, which is invalid:

  • expected the bug to be in one of the following states: NEW, ASSIGNED, POST, but it is Verified instead

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:

re-implement fix for sshKeys without adding them to ignition passwd

I want to run tests on this to see what breaks and also run the hypershift conformance tests, just so we don't burn ourselves twice!

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/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Jul 29, 2023
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 29, 2023
@cdoern
Copy link
Contributor Author

cdoern commented Jul 31, 2023

/retest-required

@cdoern
Copy link
Contributor Author

cdoern commented Jul 31, 2023

/retest-required

@cdoern
Copy link
Contributor Author

cdoern commented Jul 31, 2023

/payload-job periodic-ci-openshift-hypershift-release-4.14-periodics-e2e-aws-ovn-conformance

@cdoern
Copy link
Contributor Author

cdoern commented Jul 31, 2023

/jira refresh

@openshift-ci-robot openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jul 31, 2023
@openshift-ci-robot
Copy link
Contributor

@cdoern: This pull request references Jira Issue OCPBUGS-16227, which is valid. The bug has been moved to the POST state.

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

Requesting review from QA contact:
/cc @sergiordlr

In response to this:

/jira refresh

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/test-infra repository.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 31, 2023

@cdoern: trigger 1 job(s) for the /payload-(job|aggregate) command

  • periodic-ci-openshift-hypershift-release-4.14-periodics-e2e-aws-ovn-conformance

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/b0ecb100-2fd7-11ee-8bb3-b9cd3cc736bb-0

@openshift-ci openshift-ci bot requested a review from sergiordlr July 31, 2023 19:24
@cdoern
Copy link
Contributor Author

cdoern commented Aug 1, 2023

/jira refresh

@openshift-ci-robot
Copy link
Contributor

@cdoern: This pull request references Jira Issue OCPBUGS-16227, which is valid.

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

Requesting review from QA contact:
/cc @rioliu-rh

In response to this:

/jira refresh

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/test-infra repository.

@openshift-ci openshift-ci bot requested a review from rioliu-rh August 1, 2023 13:15
@openshift-ci-robot
Copy link
Contributor

@cdoern: This pull request references Jira Issue OCPBUGS-16227, which is valid.

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

Requesting review from QA contact:
/cc @rioliu-rh

In response to this:

re-implement fix for sshKeys without adding them to ignition passwd

I want to run tests on this to see what breaks and also run the hypershift conformance tests, just so we don't burn ourselves twice!

sshKeys should not be removed from nodes upon firstboot.

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/test-infra repository.

test/e2e/mcd_test.go Outdated Show resolved Hide resolved
test/e2e/mcd_test.go Outdated Show resolved Hide resolved
test/e2e/mcd_test.go Outdated Show resolved Hide resolved
re-implement fix for sshKeys without adding them to ignition passwd

Signed-off-by: Charlie Doern <[email protected]>
Copy link
Contributor

@yuqi-zhang yuqi-zhang left a comment

Choose a reason for hiding this comment

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

Makes sense to me! Should be safe for all platforms off the top of my head

@cdoern
Copy link
Contributor Author

cdoern commented Aug 2, 2023

/retest-required

@yuqi-zhang
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 3, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Aug 3, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cdoern, yuqi-zhang

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

cs := framework.NewClientSet("")
outNodeYoungest := bytes.NewBuffer([]byte{})
// get nodes by newest
outNodeYoungest = runCmd(t, "oc get nodes --sort-by .metadata.creationTimestamp | tail -n 1")
Copy link
Member

Choose a reason for hiding this comment

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

suggestion (non-blocking): You can do these node queries via the Clientset without having to shell out and parse oc output:

package main

import (
	"context"
	"fmt"
	"sort"

	"github.com/openshift/machine-config-operator/test/framework"

	corev1 "k8s.io/api/core/v1"
	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

func printNodeStatusLine(node *corev1.Node) {
	fmt.Printf("Node %s was created at %s. Is ready? %v\n", node.Name, node.CreationTimestamp, isNodeReady(node))
}

// This will determine whether or not a node is ready. There are additional conditions one can look at and consider, though this should be enough for this particular use-case. See https://github.com/openshift/machine-config-operator/blob/94fc0354f154e2daa923dd96defdf86448b2b327/pkg/controller/node/status.go#L237-L263 for more info.
func isNodeReady(node *corev1.Node) bool {
        for _, condition := range node.Status.Conditions {
                if condition.Reason == "KubeletReady" && condition.Type == corev1.NodeReady && condition.Status == corev1.ConditionTrue {
                        return true
                }
        }

        return false
}

func getYoungestNodeFromPool(nodeList *corev1.NodeList) *corev1.Node {
	// Sort the nodes in descending order by the creation timestamp. The youngest node will be in position '0'.
	sort.Slice(nodeList.Items, func(i, j int) bool {
		return nodeList.Items[i].CreationTimestamp.Time.Unix() > nodeList.Items[j].CreationTimestamp.Time.Unix()
	})

	youngestNode := nodeList.Items[0]
	return &youngestNode
}

func main() {
	cs := framework.NewClientSet("")

	nodeList, err := cs.CoreV1Interface.Nodes().List(context.TODO(), metav1.ListOptions{
		LabelSelector: "node-role.kubernetes.io/worker=",
	})

	if err != nil {
		panic(err)
	}

	youngestNode := getYoungestNodeFromPool(nodeList)
	fmt.Printf("Youngest node: ")
	printNodeStatusLine(youngestNode)

	fmt.Println("Nodes in worker pool:")
	for _, node := range nodeList.Items {
		printNodeStatusLine(&node)
	}
}

This will produce output like this:

Youngest node: Node ip-10-0-30-153.ec2.internal was created at 2023-08-03 08:23:03 -0400 EDT. Is ready? true
Nodes in worker pool:
Node ip-10-0-30-153.ec2.internal was created at 2023-08-03 08:23:03 -0400 EDT. Is ready? true
Node ip-10-0-2-150.ec2.internal was created at 2023-08-03 08:20:39 -0400 EDT. Is ready? true
Node ip-10-0-45-21.ec2.internal was created at 2023-08-03 08:20:31 -0400 EDT. Is ready? true

Copy link
Member

Choose a reason for hiding this comment

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

Since my code sample above deals with timestamps, I'd like to bring attention to the fact that the Golang Time types in the stdlib are not marshalable. That means if you convert it to JSON and try to convert it back, you'll get weird conversion errors; if it even converts at all!

With that in mind, you may be wondering how Kubernetes handles this problem, given that we have timestamps. Here's the answer: https://github.com/kubernetes/apimachinery/blob/5cb236977966cfc829e3b94b57fa69b44e0a95bc/pkg/apis/meta/v1/time.go

@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD 94fc035 and 2 for PR HEAD c652faf in total

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Aug 3, 2023

@cdoern: 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/okd-scos-e2e-aws-ovn c652faf link false /test okd-scos-e2e-aws-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/test-infra repository. I understand the commands that are listed here.

@cdoern
Copy link
Contributor Author

cdoern commented Aug 3, 2023

/retest-required

unknown statuses?!!?!

@openshift-merge-robot openshift-merge-robot merged commit a41f5af into openshift:master Aug 3, 2023
@openshift-ci-robot
Copy link
Contributor

@cdoern: Jira Issue OCPBUGS-16227: All pull requests linked via external trackers have merged:

Jira Issue OCPBUGS-16227 has been moved to the MODIFIED state.

In response to this:

re-implement fix for sshKeys without adding them to ignition passwd

I want to run tests on this to see what breaks and also run the hypershift conformance tests, just so we don't burn ourselves twice!

sshKeys should not be removed from nodes upon firstboot.

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/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants