Description of problem: When installing the OSCP 3.4, the etcd3 or etcd>3.0.x could be installed. This is not correct as the valid etcd version for OSCP 3.4 should be 3.0.X. There should be some excluder or hard dependency for the packages as during the prod installation the incorrect version could be installed. https://access.redhat.com/articles/2176281
Hi, The etcd package is comming from rhel-7-server-extras-rpms, not from the ose package.
Is there an actual problem encountered here? OCP 3.4 should work fine with etcd 3.0 or 3.1.
Or 3.2.
Hello Scott, based on https://access.redhat.com/articles/2176281 the 3.4 should be only 3.0. The 3.5 should be ok with 3.0 or 3.1. Unfortunately, there is already etcd version 3.2 available from rhel-7-server-extras-rpms ? Thx
Then that document needs to be updated. Until an actual defect related to OCP 3.4 and etcd is observed this is NOTABUG.
(In reply to jooho lee from comment #6) > @Scott > > Is there any chance upgrading etcd to etcd3 accidentally? If so, the scheme > should be a problem. No, you'd have to manually alter the master config to start using v3 storage. This should not be a problem.
Re-opening this bug, since the upgrade from etcd3.1 to etcd3.2 break the etcd cluster. The reason for this, is that: ETCD_CA_FILE is deprecated and replaced by ETCD_TRUSTED_CA_FILE ETCD_PEER_CA_FILE is deprecated and replaced by ETCD_PEER_TRUSTED_CA_FILE Reference: https://coreos.com/etcd/docs/latest/v2/configuration.html#security-flags So I'm wondering if we can avoid people to accidentally run a plain " yum update" and fall into this issue. ** More information about this upgrade problem in BZ [1529575](https://bugzilla.redhat.com/show_bug.cgi?id=1529575)
https://bugzilla.redhat.com/show_bug.cgi?id=1529575 is a distinct bug related to etcd 3.2 options and etcd 3.1 configuration file and we're addressing that separately.