🌱 apply our own rules for host availability

[dhellmann]

Do not rely on the host's Available() method to decide when a host can
be selected for provisioning.

[dhellmann]

/retest

[dhellmann]

/test-integration

[zaneb]

/approve

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhellmann, zaneb

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [dhellmann]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[s3rj1k]

@dhellmann what about ClearError() SetErrorMessage() ?

[dhellmann]

@dhellmann what about ClearError() SetErrorMessage() ?

I added another patch to the series to remove those.

I think we can deal with the other public methods separately, to avoid making this PR gigantic.

[dhellmann]

/test-integration

[s3rj1k]

@dhellmann Do you intend to make a stable API promise?

I mean the only reason that I can think of removing those methods and make them private is to prepare a codebase for a new API version release.

[dhellmann]

@dhellmann Do you intend to make a stable API promise?

I mean the only reason that I can think of removing those methods and make them private is to prepare a codebase for a new API version release.

I see this as part of continual cleanup. Those methods shouldn't have been implemented the way they are to begin with. I don't really think it's necessary to commit to making them a stable API.

We do try to keep other parts of the code stable, like github.com/metal3-io/baremetal-operator/pkg/bmc, but even in that case it's possible to address changes in the API when a dependency is updated in a consuming project.

Are you anticipating a specific issue from these changes? Or just concerned that we don't consider "internals" as needing to have stable APIs?

[s3rj1k]

Are you anticipating a specific issue from these changes? Or just concerned that we don't consider "internals" as needing to have stable APIs?

Just concerned that some of the internals could actually be used by external projects, good example would be HasError() method.

On a side note not directly connected to this PR, can we have more frequent tag releases for code under metal3-io umbrella?
This should help with vendoring.

[maelk]

/lgtm