*: remove support for environment variables

[crawford]

The environment variables were originally added to make CI testing a
little easier, since the installer didn't support consumption of
provided assets (e.g. the install config). Now that the installer
supports consumption, there is no need for most of the environment
variables anymore. The variables have actually been confusing to users,
so their removal should simplify the mental model.

[crawford]

Requires openshift/release#2353.

[wking]

How are we planning on rolling this out? The gentlest way (at this point in our unstable development) would probably be to drop the docs in one PR, and then (after giving folks a week to react to the change-log's deprecation notice) to drop the implementation in the next release. Or we can land them both in one PR? Now that we're cutting frequent, pinned release, I'm comfortable with either. Folks who run master should read the Git history, and folks who run pinned releases can see the API change in the change-log and decide whether or not they can update. The only issue with that would be the BYOR folks who got bit by #644 (so CC @vrutkovs about this change) and are probably floating on master without reading our Git history ;).

[michaelgugino]

I think if you're going to remove the environment variables you should also remove the prompts altogether. Just give people an example install-config to fill out. Dynamically generating a file just to turn around and have to edit it is burdensome and my suspicion is that the install-config file will be lacking proper documentation because 'you really shouldn't mess with it anyway' kind of thing.

[crawford]

I think if you're going to remove the environment variables you should also remove the prompts altogether. Just give people an example install-config to fill out.

We still want the prompts for those users which don't want to do any customization and just want to get a cluster up and running as quickly as possible.

Dynamically generating a file just to turn around and have to edit it is burdensome and my suspicion is that the install-config file will be lacking proper documentation because 'you really shouldn't mess with it anyway' kind of thing.

The install-config is the thing we want people messing with though. We just haven't finalized it's shape and therefore haven't spent much time on documentation. The multiple-invocation nature of the installer is central to providing escape hatches at many different levels. Yes, it may be burdensome, but that is the price you pay for deeper customization. We don't want to drag everyone down into the weeds because a few users need to heavily customize their setup.

[crawford]

How are we planning on rolling this out?

I want to get this out as quickly as possible before too many people become reliant on them. I'm fine dumping it into the next release without any deprecation period.

[abhinavdahiya]

This is 💯
/approve

[ironcladlou]

lgtm, I'm okay ripping off the bandaid and getting to work on environment-less workflows.

[vrutkovs]

/retest

[crawford]

Error executing openshift-install: waiting for bootstrap-complete: timed out waiting for the condition

This has been killing us lately.

[crawford]

Error executing openshift-install: waiting for bootstrap-complete: timed out waiting for the condition

Hopefully openshift/cluster-openshift-apiserver-operator#91 helps.

/retest

[crawford]

aws_instance.master.0: Error launching source instance: timeout while waiting for state to become 'success' (timeout: 30s)

Come on AWS...

/pray
/retest

[crawford]

This error appears to be caused by "Server.InsufficientInstanceCapacity" on AWS's end. We might need to switch off of t3.medium until AWS installs more hardware (cc @wking).

[crawford]

We currently do not have sufficient t3.medium capacity in the Availability Zone you requested (us-east-1a). Our system will be working on provisioning additional capacity. You can currently get t3.medium capacity by not specifying an Availability Zone in your request or choosing us-east-1d, us-east-1b, us-east-1c, us-east-1f.

[vrutkovs]

/retest

[wking]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, crawford, wking

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 [abhinavdahiya,crawford,wking]

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

[alejovicu]

Maybe the documentation of SSH Access in docs/dev/libvirt-howto.md should be updated to remove the reference to the envars:
OPENSHIFT_INSTALL_CLUSTER_NAME
OPENSHIFT_INSTALL_BASE_DOMAIN
OPENSHIFT_INSTALL_LIBVIRT_URI

[wking]

@alejovicu, file a follow-up?

[ghost]

@wking
So after this, how can we do things with CI? Is it still supported?

[wking]

So after this, how can we do things with CI?

The CI updates happend in openshift/release#2353. Did you need something besides that?

[ghost]

@wking Got you, means we have to make install-config.yaml as a template and generate target file via a template system which maybe build in ansible or other things, or draft one.

[gpei]

@wking Got you, means we have to make install-config.yaml as a template and generate target file via a template system which maybe build in ansible or other things, or draft one.

yeah, like this Jinja2 template file https://github.com/vrutkovs/openshift-40-centos/blob/master/install-config.yml.j2

But one more concern is that the template is still a static file, once some changes made in new generated install-config.yaml, we need to apply corresponding updates to our template as well. Especially in the future, customers may have more customized requests to the installer. So we may always have to update the template, it still will be a challenge for CI jobs IMO.

[crawford]

once some changes made in new generated install-config.yaml, we need to apply corresponding updates to our template as well

This is true of any input, including environment variables. As we added, removed, and renamed variables, CI had to be kept up-to-date just the same. As developers make changes here, they will be responsible for making the necessary changes to CI.