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

TELCODOCS-368: Deploying an OCP cluster manually without Assisted Installer (regardless of use case) #38068

Closed
wants to merge 1 commit into from

Conversation

johnwilkins
Copy link
Contributor

@johnwilkins johnwilkins commented Oct 27, 2021

Adds modules for generating the ISO manually and monitoring the installation manually. It also renames the doc back to Single Node OpenShift (SNO), which was originally removed because it was not present in a spreadsheet that peer reviewers used to verify names.

Fixes: TELCODOCS-368

See https://issues.redhat.com/browse/TELCODOCS-368 for additional details.

Preview URL: https://deploy-preview-38068--osdocs.netlify.app/openshift-enterprise/latest/installing/installing_sno/install-sno-preparing-to-install-sno.html

For release(s): 4.9, 4.10
Signed-off-by: John Wilkins jowilkin@redhat.com

@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 27, 2021
@johnwilkins johnwilkins changed the title TELCODOCS-368: WIP: TELCODOCS-368: Deploying an OCP cluster manually without Assisted Installer (regardless of use case) Oct 27, 2021
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 27, 2021
@netlify
Copy link

netlify bot commented Oct 27, 2021

✔️ Deploy Preview for osdocs ready!

🔨 Explore the source changes: 95dfe1933995012dc937d115db4a1a50c24a8626

🔍 Inspect the deploy log: https://app.netlify.com/sites/osdocs/deploys/6179d01430160f000707d65a

😎 Browse the preview: https://deploy-preview-38068--osdocs.netlify.app

@netlify
Copy link

netlify bot commented Oct 27, 2021

✔️ Deploy Preview for osdocs ready!

🔨 Explore the source changes: 920644b

🔍 Inspect the deploy log: https://app.netlify.com/sites/osdocs/deploys/619be54565cc2f0008402ccc

😎 Browse the preview: https://deploy-preview-38068--osdocs.netlify.app

@romfreiman
Copy link

@romfreiman
Copy link

Networking wise: I would take the relevant parts from here:
https://docs.openshift.com/container-platform/4.8/installing/installing_bare_metal/installing-bare-metal.html#installation-dns-user-infra_installing-bare-metal

api-int depends whether the installation was done with assisted installer or not - if without, the user will have to configure it as well externally.

Copy link
Contributor

@aireilly aireilly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments, some nits. Looks good John!

@pamoedom
Copy link

pamoedom commented Nov 5, 2021

Hi @johnwilkins, I'm the new QA contact for BZ#2017242, regarding SNO documentation improvement there is a pair of things I would like to discuss here:

First of all, IMHO, I think we need to distinguish between SingleReplica cluster (SNO), which can be also manually achieved with a standard installation of only 1 master node using the default installation method, and between SNO BIP (bootstrap in place), which requires the creation of the special bootstrap-in-place-for-live-iso ignition config asset. What do you think about this @romfreiman?

FWIW, here you have a simple command that can be used to confirm that the cluster is SingleReplica (SNO):

$ oc get infrastructures cluster -o jsonpath="{.status.infrastructureTopology}{'\n'}"

Secondly, apart from ISO and USB, I think we should also include a third installation method using iPXE live mode, this mode is very useful for automated scenarios, specially when pre-installation operations are involved like disk encryption, here you have a basic example of the necessary iPXE code as reference:

#!ipxe
kernel http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> initrd=main coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img ignition.config.url=http://<HTTP_server>/bootstrap-in-place-for-live-iso.ign ignition.firstboot ignition.platform.id=metal
initrd --name main http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img 
boot

NOTE: the main goal of BZ#2017242 (removing the statement indicating that upgrade is not supported) is already covered, thanks.

Best Regards.

@johnwilkins
Copy link
Contributor Author

johnwilkins commented Nov 8, 2021

Hardware requirements: it's not 8 CPU cores but better to be aligned on the terms with: https://docs.openshift.com/container-platform/4.8/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal

See: #38183

@romfreiman @codyhoag That says it's from the UPI bare metal docs, but the requirements listed in that table suggest virtual CPUs and virtual RAM. @codyhoag this is probably a docs bug? My requirements came from the original SNO dev preview document and require a bit more resources because we're running both a control plane and worker (and its workload) on a single node. So it probably should have a bit more in the way of minimum resources, no?

@codyhoag
Copy link
Contributor

codyhoag commented Nov 8, 2021

@romfreiman @codyhoag That says it's from the UPI bare metal docs, but the requirements listed in that table suggest virtual CPUs and virtual RAM. @codyhoag this is probably a docs bug? My requirements came from the original SNO dev preview document and require a bit more resources because we're running both a control plane and worker (and its workload) on a single node. So it probably should have a bit more in the way of minimum resources, no?

@johnwilkins The minimum resources table was verified by stakeholders in a recent initiative a few months ago (started in #35793). Bare metal UPI was one of the providers that was confirmed for those minimum resource requirements. In terms of SNO, makes sense that the requirements would be larger, but I don't have any background on that.

Edit: checking with installer team on "virtual" usages in resource requirements for bare metal

@eranco74
Copy link

eranco74 commented Nov 9, 2021

Hardware requirements: it's not 8 CPU cores but better to be aligned on the terms with: https://docs.openshift.com/container-platform/4.8/installing/installing_bare_metal/installing-bare-metal.html#minimum-resource-requirements_installing-bare-metal
See: #38183

@romfreiman @codyhoag That says it's from the UPI bare metal docs, but the requirements listed in that table suggest virtual CPUs and virtual RAM. @codyhoag this is probably a docs bug? My requirements came from the original SNO dev preview document and require a bit more resources because we're running both a control plane and worker (and its workload) on a single node. So it probably should have a bit more in the way of minimum resources, no?

Single node requirements should be:
8 vCPU cores (One vCPU is equivalent to one physical core when simultaneous multithreading (SMT), or hyperthreading)
32GB of RAM
120GB Disk

@pamoedom
Copy link

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 10, 2021
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Nov 10, 2021
@pamoedom
Copy link

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 10, 2021
@johnwilkins johnwilkins changed the title WIP: TELCODOCS-368: Deploying an OCP cluster manually without Assisted Installer (regardless of use case) TELCODOCS-368: Deploying an OCP cluster manually without Assisted Installer (regardless of use case) Nov 11, 2021
@openshift-ci openshift-ci bot removed do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. lgtm Indicates that a PR is ready to be merged. labels Nov 11, 2021
@pamoedom
Copy link

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 15, 2021

. Retrieve the {op-system-first} ISO:
+
[source,terminal]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have guidance restricting our use of jq commands: "Do not use jq in commands (unless it is truly required), because this requires users to install the jq tool. Oftentimes, the same or similar result can be accomplished using jsonpath for oc commands."

Is there an alternate command that would work here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left it in for now. Need to hear from QE and engineering.

_topic_map.yml Outdated Show resolved Hide resolved
@bmcelvee
Copy link
Contributor

A few edits/suggestions/questions from me. It's looking good, though!

@bmcelvee bmcelvee added this to the Next Release milestone Nov 17, 2021
@openshift-ci openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 21, 2021
@tradej
Copy link

tradej commented Nov 22, 2021

John is on PTO, @ktothill will look into resolving the conflict.

@openshift-ci
Copy link

openshift-ci bot commented Nov 22, 2021

New changes are detected. LGTM label has been removed.

@openshift-ci openshift-ci bot removed lgtm Indicates that a PR is ready to be merged. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Nov 22, 2021
…e ISO and a manual procedure for monitoring install..
@openshift-ci
Copy link

openshift-ci bot commented Nov 24, 2021

@johnwilkins: PR needs rebase.

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 openshift-ci bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Nov 24, 2021
@aireilly
Copy link
Contributor

Attempting to complete this work in #39205 while John is on PTO.

@aireilly
Copy link
Contributor

aireilly commented Dec 9, 2021

This PR can be closed. This work was merged in #39205

@mburke5678 mburke5678 closed this Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch/enterprise-4.9 branch/enterprise-4.10 needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants