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

Adding a default value for hardware metadata state #669

Merged
merged 1 commit into from
Jan 17, 2023

Conversation

pokearu
Copy link
Contributor

@pokearu pokearu commented Jan 17, 2023

Description

The metadata state field is consumed in CAPT for checking if a given hardware is ready.

The changes sets a default value for the field to provisioning with kubebuilder defaults. Currently this field is left empty.

Why is this needed

Boots and CAPT looks at spec.metadata.state to check if a hardware needs to be PXE served and if a hardware is ready.
Today a user is not expected to set the field but defaulting to provisioning helps provide context to the starting state of the tinkerbell provisioning process.

@codecov
Copy link

codecov bot commented Jan 17, 2023

Codecov Report

Merging #669 (1f90433) into main (4f94071) will not change coverage.
The diff coverage is n/a.

❗ Current head 1f90433 differs from pull request most recent head 0955770. Consider uploading reports for the commit 0955770 to get more accurate results

@@           Coverage Diff           @@
##             main     #669   +/-   ##
=======================================
  Coverage   48.26%   48.26%           
=======================================
  Files          18       18           
  Lines         951      951           
=======================================
  Hits          459      459           
  Misses        484      484           
  Partials        8        8           
Impacted Files Coverage Δ
api/v1alpha1/hardware_types.go 100.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@chrisdoherty4 chrisdoherty4 added the ready-to-merge Signal to Mergify to merge the PR. label Jan 17, 2023
@mergify mergify bot merged commit ae32f7f into tinkerbell:main Jan 17, 2023
jacobweinstock added a commit to jacobweinstock/tink that referenced this pull request Jun 26, 2024
This default value doesn't make sense from a holistic
point of view. It was added as part of some CAPT refactoring.
tinkerbell#669
If CAPT needs this state then the responsibility is on CAPT
to set this. Also, this field is no longer used by Smee or
CAPT.

Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock added a commit to jacobweinstock/tink that referenced this pull request Jul 1, 2024
This default value doesn't make sense from a holistic
point of view. It was added as part of some CAPT refactoring.
tinkerbell#669
If CAPT needs this state then the responsibility is on CAPT
to set this. Also, this field is no longer used by Smee or
CAPT.

Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock added a commit to jacobweinstock/tink that referenced this pull request Jul 5, 2024
This default value doesn't make sense from a holistic
point of view. It was added as part of some CAPT refactoring.
tinkerbell#669
If CAPT needs this state then the responsibility is on CAPT
to set this. Also, this field is no longer used by Smee or
CAPT.

Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock added a commit that referenced this pull request Jul 5, 2024
Remove default value for Hardware.Spec.Metadata.State:

## Description

<!--- Please describe what this PR is going to change -->
This default value doesn't make sense from a holistic point of view. Apply a Hardware object to a cluster doesn't by default indicate the hardware is in a provisioning state and we should not assume this with a default value. It was added as part of some CAPT refactoring. #669 If CAPT needs this state then the responsibility is on CAPT to set this. Also, this field is no longer used by Smee or CAPT.

## Why is this needed

<!--- Link to issue you have raised -->

Fixes: #

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->


## How are existing users impacted? What migration steps/scripts do we need?

<!--- Fixes a bug, unblocks installation, removes a component of the stack etc -->
<!--- Requires a DB migration script, etc. -->


## Checklist:

I have:

- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge Signal to Mergify to merge the PR.
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants