BareMetalHost API v1beta1

[s3rj1k]

If my opinion counts, I like that, removing legacy with API version bump

[Rozzii]

/cc @kashifest @tuminoid @lentzi90

[dtantsur]

/cc @zaneb

[kashifest]

I am heavily in favor of new API version for BMH. I am interested to know how would we maintain versioning API for BMH in general for future? Would we go to v1beta2 for example and what would be criterions to go to beta2? Shall we document it somewhere if not existing already? Thanks @dtantsur for taking care of this, happy top help in this.

[dtantsur]

Would we go to v1beta2 for example and what would be criterions to go to beta2?

I don't know the kubernetes practices for sure, but I'd not expect us to plan beta2 right now. We may need to do it if we decide that our API has to change again before v1 (e.g. to include Zane's ideas about splitting BareMetalHost object).

[dtantsur]

Updated the document with my reasoning against v1alpha2 and added a proposal by Zane to rename online to poweredOn.

[Rozzii]

/lgtm

[dtantsur]

@zaneb could you take another look and see if this design can get approved?

[Rozzii]

Hi @zaneb @dtantsur

I would like to introduce maxSizeGigabye rootDeviceHint field as part of the v1alpha1 stabilization process, I have detailed my plan here: https://github.com/metal3-io/baremetal-operator/issues/1308. Please take a look and let me know about your opinion.

[dtantsur]

@zaneb and others: the new revision has changed the approach to the new version by making the transition smoother and ensuring conversion without losses. Please review.

@Rozzii I welcome this, but this can be done without a new version since it's 100% compatible, no?

[Rozzii]

@zaneb and others: the new revision has changed the approach to the new version by making the transition smoother and ensuring conversion without losses. Please review.

@Rozzii I welcome this, but this can be done without a new version since it's 100% compatible, no?

Yes I believe this would be 100% backward compatible , but I would still modify the API with this I thought all change to the API would cause a version bump.

[Rozzii]

I will paste here a link, just to better highlight the parallel discussion about the branching https://github.com/metal3-io/metal3-docs/pull/345 @zaneb @dtantsur @kashifest

[zaneb]

For me the question in https://github.com/metal3-io/metal3-docs/pull/332/files#r1245928458 is still not answered by this. The part about the storage version is now explicit, but there's no mention of when the controller starts using the new version.

In fact there's no mention at all of changing the version the controller uses, despite all the preliminary work that has gone into it ("Refactor the BMO code to avoid referring directly to the current version"). I gather that the backward-compatibility changes included here mean we can theoretically continue indefinitely using the older client. So it sounds like we're signing future-us up for a big-bang rewrite of the controller at some unknown time?

[dtantsur]

@zaneb updated, PTAL.

[elfosardo]

/lgtm

[metal3-io-bot]

@elfosardo: adding LGTM is restricted to approvers and reviewers in OWNERS files.

In response to [this](https://github.com/metal3-io/metal3-docs/pull/332#issuecomment-1746966525): >/lgtm 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/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[Rozzii]

/approve

[Rozzii]

/lgtm

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lentzi90, Rozzii

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: - ~~[design/OWNERS](https://github.com/metal3-io/metal3-docs/blob/main/design/OWNERS)~~ [Rozzii] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[dtantsur]

Okay, the new revision leaves the actual code removal an open question. @zaneb @kashifest @lentzi90 could you please take another look and lgtm/approve? I think that was the last concern.

[kashifest]

/lgtm