-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Use install-configs when invoking installer #2353
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
Conversation
ci-operator/jobs/openshift/installer/openshift-installer-master-presubmits.yaml
Outdated
Show resolved
Hide resolved
ci-operator/templates/openshift/installer/cluster-launch-installer-e2e.yaml
Outdated
Show resolved
Hide resolved
These variables were removed from the installer recently (in favor of dynamically generated console credentials) and have no effect.
Tested locally with AWS. This seems to work as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/lgtm cancel |
The installer is moving away from environment variables. They were originally added as a work-around for CI, but now that install-configs can be read directly, these should be used instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: crawford, michaelgugino 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:
Approvers can indicate their approval by writing |
@crawford: Updated the following 3 configmaps:
In response to this:
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. |
mkdir /tmp/artifacts/installer && | ||
/bin/openshift-install version >/tmp/artifacts/installer/version | ||
|
||
export _CI_ONLY_STAY_AWAY_OPENSHIFT_INSTALL_AWS_USER_TAGS="{\"expirationDate\": \"$(date -d '4 hours' --iso=minutes --utc)\"}" | ||
/bin/openshift-install --dir=/tmp/artifacts/installer --log-level=debug create install-config | ||
export CLUSTER_ID=$(uuidgen --random) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use JOB_NAME_HASH
? This would help us identify which resources are created by particular CI job
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cluster ID has to be a version 4 UUID. If JOB_NAME_HASH
satisfies that constraint we can use it. Do you know if it does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right, it doesn't. Seems this value would be logged in the container logs, so resource can be tracked down to the CI job
- name: OPENSHIFT_INSTALL_PLATFORM | ||
value: ${CLUSTER_TYPE} | ||
- name: OPENSHIFT_INSTALL_AWS_REGION | ||
value: us-east-1 | ||
- name: OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now silently dropped, so CI would use pinned release instead of latest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that variable is still respected; even after my installer PR.
else | ||
echo "Unsupported cluster type '${CLUSTER_NAME}'" | ||
exit 1 | ||
fi | ||
|
||
/bin/openshift-install --dir=/tmp/artifacts/installer --log-level=debug create ignition-configs & |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ignition-configs
would destroy install-config.yml
- is this an installer bug? In any case in CI we should be backing install config since its now cannot be reconstructed using env vars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is core to the design of the installer (so no, not a bug). Why is the install config needed after the Ignition Configs are generated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd keep the backup to ensure that the all the vars got templated correctly, this is not required though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The installer's state file (.openshift_install_state.json
) should be archived, so the install-config can be pulled out of there if we need to inspect it after the fact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI stores this file, but it doesn't seem to contain any config - https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_installer/861/pull-ci-openshift-installer-master-e2e-aws/2219/artifacts/e2e-aws/installer/.openshift_install_state.json - a bug in PR 861?
nevermind, it does - installconfig.InstallConfig
pullSecret: | | ||
${PULL_SECRET} | ||
sshKey: | | ||
${SSH_PUB_KEY} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be left blank for BYOR - public key is being injected via playbook
The change should first land in the installer, see openshift/installer#861
…SECRET and similar These are local variables; we don't need to leak them down into child processes. At least some of these were introduced in 4134347 (Use install-configs when invoking installer, 2018-12-10, openshift#2353). The motivation behind the old approach is not clear to me, but I suspect overly broad pattern-matching ;).
The installer is moving away from environment variables. They were
originally added as a work-around for CI, but now that install-configs
can be read directly, these should be used instead.
I have not tested these changes!cc @wking