✨ Add Golang-based deploy-cli

[mquhuy]

What this PR does / why we need it:
This package does the jobs that are currently handled by deploy.sh. It will help installing BMO, Ironic with suitable configuration.

This PR has been successfully tested here: metal3-io/metal3-dev-env#1447

Co-author: @maxrantil

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kashifest for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[kashifest]

cc @adilGhaffarDev @lentzi90 @Rozzii @kashifest

[Rozzii]

/cc @dtantsur @elfosardo @zaneb I think you would like to check this out also

[metal3-io-bot]

@Rozzii: GitHub didn't allow me to request PR reviews from the following users: I, to, out, check, this, also, would, like, you, think.

Note that only metal3-io members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @dtantsur @elfosardo @zaneb I think you would like to check this out also

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.

[mquhuy]

/test metal3-bmo-e2e-test-pull

[mquhuy]

cc @adilGhaffarDev @lentzi90 @Rozzii @kashifest

/cc @adilGhaffarDev @lentzi90 @Rozzii @kashifest
Just so that you guys are added to reviewers list

[NymanRobin]

Looks good just some small things I noticed 😄

[tuminoid]

I has open comments etc as well, but in general I don't want this in BMO 0.7 yet, IMO better merge it only after we've cut the release, so it can have a cycle to be tested, polished and integrated.
/hold

Let me know if you disagree.

[mquhuy]

I has open comments etc as well, but in general I don't want this in BMO 0.7 yet, IMO better merge it only after we've cut the release, so it can have a cycle to be tested, polished and integrated. /hold

Let me know if you disagree.

I'm not sure what you mean by "cut the release"?

IMO waiting for a whole release to merge this is a waste of time. It's passed all CI tests, so if we don't merge it and let people use it, how can we further test it then? We still keep deploy.sh, and use it in CI, so this new package is n't gonna harm anything. It's not a part of BMO code either.

Edit: Sorry now I think I got your point. If it just means we will wait till after 0.7 release, then we merge this, I wouldn't mind. Anw, as I said, it wouldn't hurt to have it in 0.7 either.

[tuminoid]

I has open comments etc as well, but in general I don't want this in BMO 0.7 yet, IMO better merge it only after we've cut the release, so it can have a cycle to be tested, polished and integrated. /hold
Let me know if you disagree.

I'm not sure what you mean by "cut the release"?

IMO waiting for a whole release to merge this is a waste of time. It's passed all CI tests, so if we don't merge it and let people use it, how can we further test it then? We still keep deploy.sh, and use it in CI, so this new package is n't gonna harm anything. It's not a part of BMO code either.

Edit: Sorry now I think I got your point. If it just means we will wait till after 0.7 release, then we merge this, I wouldn't mind. Anw, as I said, it wouldn't hurt to have it in 0.7 either.

Yes, I meant 0.7, but if its not replacing deploy.sh, and deploy.sh is still the documented way, then it doesn't matter so much.

I was rather thinking that we make this one replace deploy.sh after we've cut 0.7, so it gets tested in CI for a release cycle as primary tool, and there wouldn't be two tools to maintain.

How does that sound?

[mquhuy]

I was rather thinking that we make this one replace deploy.sh after we've cut 0.7, so it gets tested in CI for a release cycle as primary tool, and there wouldn't be two tools to maintain.

How does that sound?

Yep that would be great! We will have to do that change in dev-env though, so doesn't matter if we merge this PR or not.

[tuminoid]

I was rather thinking that we make this one replace deploy.sh after we've cut 0.7, so it gets tested in CI for a release cycle as primary tool, and there wouldn't be two tools to maintain.
How does that sound?

Yep that would be great! We will have to do that change in dev-env though, so doesn't matter if we merge this PR or not.

Yes I'm aware of that. However we need to maintain this in 0.7 if we merge it before cutting release, so I think we are agreeing on merging only after 0.7?

[mquhuy]

Yes I'm aware of that. However we need to maintain this in 0.7 if we merge it before cutting release, so I think we are agreeing on merging only after 0.7?

Yeah let's merge after 0.7 then

[mquhuy]

/unhold We have BMO 0.8 released.

[mquhuy]

/unhold