Automated Workflow for Agent-based Installer

[dhellmann]

"Cluster 0" deployments, for the first cluster in an environment, are
unique because they occur in situations where there may not be a lot of
other infrastructure to support long-running services normally associated
with automated provisioning for on-premises use cases. Nevertheless,
users and partners want to automate these deployments. The assisted
installer GUI provides an excellent user experience for manually deploying
clusters. This enhancement covers the automation use case.

/priority important-soon

[dhellmann]

/cc @avishayt @celebdor @lranjbar @mhrivnak @patrickdillon @pawanpinjarkar @rwsu @julienlim

[openshift-ci]

@dhellmann: GitHub didn't allow me to request PR reviews from the following users: julienlim.

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

In response to this:

/cc @avishayt @celebdor @lranjbar @mhrivnak @patrickdillon @pawanpinjarkar @rwsu @julienlim

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.

[dhellmann]

I know @rwsu is out this week, so I'll place a hold to ensure he has time to double check that I've captured the details of what he's already done in the prototype correctly.

/hold

[dhellmann]

/cc @staebler

let me know if I should add you to the formal reviewer list for this, I'd be happy to do that.

[staebler]

/cc @staebler

let me know if I should add you to the formal reviewer list for this, I'd be happy to do that.

You don't need to add me to the formal review list, but I will add my review.

[staebler]

My initial overall reaction to this proposal is that I am surprised at the extent of the input needed for the create image command.

[zaneb]

This looks basically ready to merge to me. I'll give it another day or two before approving.

[zaneb]

The idea of the agent-config file is to provide a place to add config that otherwise might be in the install-config but is specific to the agent-based installation method, because it needs to be configured in the image before installation starts. I'd expect this to be very small, but potential candidates we've identified are:

• node0 selection
• root disk multipathing
• network config (exists in install-config for baremetal platform, but not for others)
• hostnames

Some of these have equivalents in the ZTP CRDs, some do not, but all of them are painful to construct by hand.

[patrickdillon]

Of the new changes, agent-config.yaml seems to have gotten more concrete and LGTM.

Everything here /lgtm from an installer perspective.

[dhellmann]

The enhancement template was restructured this week. The Drawbacks section is present in this doc, but does not use the same heading level so the linter is failing.

/override ci/prow/markdownlint

[openshift-ci]

@dhellmann: Overrode contexts on behalf of dhellmann: ci/prow/markdownlint

In response to this:

The enhancement template was restructured this week. The Drawbacks section is present in this doc, but does not use the same heading level so the linter is failing.

/override ci/prow/markdownlint

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.

[dhellmann]

We agreed in the cluster lifecycle architecture call yesterday to put out a last call for comments on this enhancement, with a goal of merging it by the end of the day on 3 May.

[LalatenduMohanty]

I am not sure what Those steps may also be performed by **cluster creator** if no software component is available. means. Do you mean the steps of deployment can be handled manually if no automation exists?

[zaneb]

Yes, it means you can boot the ISO manually if your are so inclined.

[LalatenduMohanty]

The PR looks good to me.

[LalatenduMohanty]

@dhellmann I did not add lgtm label because I am not in the review list. But if you want to add add it then let me know.

[dhellmann]

@dhellmann I did not add lgtm label because I am not in the review list. But if you want to add add it then let me know.

Thanks. A simple "lgtm" comment from anyone is fine. Zane can verify that all of the reviewers have left one and add both labels at once when this is ready to merge.

[mhrivnak]

Some discussion has been happening in a separate FAQ document. An important point came up about validations for optional operators that I think is relevant here. Paraphrasing, it was expressed that pre-installation validations that are specific to operators that handle storage, virt, etc. are more acceptable for the agent-based installation that is available on console.redhat.com, but would be less desirable for an installer that is shipped inside an openshift release due to coupling of requirements across products.

I think that's an important issue to address, especially if deciding to deliver this new install capability through the openshift-install binary is going to limit its value to users. Here was my comment:

The main reason that a small number of operators are selectable on console.redhat.com is for the pre-install validations. If the hardware specs are not sufficient to run ODF, virt, etc, we want to tell the user upfront rather than let them go through a cluster installation, try to install and use the operator (disconnected operator installation is no fun...), and only then fail after all that time and work. The value of ensuring user success upfront was determined to be worth the price of maintaining a small list of validations for a few specific operators. IOW a small bit of coupling improves the UX significantly.

Since a primary use case here is to enable a user who wants to establish a local point of management within their disconnected environment, validating their complete intent upfront seems to make sense. If putting this tool "inside OCP" precludes that sort of thinking, maybe that's not the best delivery model for the use case.

Were other delivery models considered and/or ruled out? What about shipping this as part of multi-cluster engine, where it could provide a complete story for creating a first local point of management? Or maybe we can still provide that complete story even while shipping as part of the OCP payload?

[dhellmann]

That was an early decision that we captured in an internal document but didn't repeat here. It basically came down to wanting to integrate the various tools, rather than create another standalone thing. I'll share that doc with you.

[zaneb]

I don't think we should block on this, but we will probably want to find another term since the manifests created by agent create manifests have a wholly different role to those created by the regular create manifests.

[dhellmann]

Let's work that out with the installer team when we write that command and then come back and update this enhancement.

[dhellmann]

/override ci/prow/markdownlint

The same linter error from the template update.

enhancements/agent-installer/automated-workflow-for-agent-based-installer.md missing "### Drawbacks"

[openshift-ci]

@dhellmann: Overrode contexts on behalf of dhellmann: ci/prow/markdownlint

In response to this:

/override ci/prow/markdownlint

The same linter error from the template update.

enhancements/agent-installer/automated-workflow-for-agent-based-installer.md missing "### Drawbacks"

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]

@dhellmann: all tests passed!

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.

[zaneb]

The appointed hour passed yesterday and there have been no further comments today, so let's go ahead and merge this so the team is clear on the direction.
/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zaneb

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:

• OWNERS [zaneb]

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