Bug 1730910
| Summary: | crio service not enabled/started when node is initialized | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Chris Callegari <ccallega> |
| Component: | RHCOS | Assignee: | Steve Milner <smilner> |
| Status: | CLOSED NOTABUG | QA Contact: | Micah Abbott <miabbott> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.z | CC: | bbreard, dustymabe, imcleod, jligon, nstielau, walters |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-18 13:25:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Chris Callegari
2019-07-17 20:41:19 UTC
Master instances and worker instances all fail to initialize with crio service running. Manually starting service and restarting kubelet enables "wait-for bootstrap-complete" to complete successfully. You're using a 4.2 bootimage with a 4.1 installer? This isn't...tested. And I'd say we shouldn't support it unless there's a strong reason. The change here came in https://src.osci.redhat.com/rpms/redhat-release-coreos/c/d34c31c10d025f04f1e04488844f1fe85a6b061c?branch=rhaos-4.2-rhel-8 Thanks for the report Chris!
> You're using a 4.2 bootimage with a 4.1 installer? This isn't...tested. And I'd say we shouldn't support it unless there's a strong reason.
Agreed. Having cri-o start when the kubelet starts up was done purposefully for 4.2+. Is there a specific need for the 4.1 installer to work for 4.2 boot images?
Yikes, I didn't realize I had a version mismatch! That is absolutely not what I'm trying to do. When you say "bootimage" do you mean the AWS AMI? Correct. We have `machine-os-content` (aka os-container`s) and boot images (IE: AMI, qcow2, ova, etc..). No customers should be searching for AMIs by name. Absolutely don't do that, you can easily be picking up development or pre-release builds, as happened here. Use the AMIs from https://docs.openshift.com/container-platform/4.1/installing/installing_aws_user_infra/installing-aws-user-infra.html OK, right, you want https://github.com/openshift/installer/issues/1399 re issue/1139 ... oh yea, that would be a great feature to have.
This test is for customers in AWS trying to install OCP 4 in internet isolated subnets. Sol Eng is ensuring the product can handle the scenario. Finance and telco are the customers demanding the functionality.
The UPI documentation is already stale. We got overridden on a pull request to automate that ami table.
We don't filter by name. We filter by Description. The filter is the following...
params.REGION set in Jenkins pipeline parameters section
export AWS_DEFAULT_REGION=${params.REGION}
export RHCOSAMIID=`aws ec2 describe-images --owners 531415883065 \
--filters "Name=name,Values=rhcos*" \
--query "sort_by(Images, &CreationDate) | [? ! contains(Description, 'Beta')] | [? ! contains(Description, 'devel')] | [-1].ImageId" \
--output text`
|