RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

The migration of OpenShift data from etcd2 -> etcd3 currently fails while running the etcdctl migrate tool.   It errors out immediately whether a custom transformer or the default one is used.

The error (with some extra debugging in the custom transformer used) is:

Starting...
ERROR CODING NODE 0 {Key: , CreatedIndex: 0, ModifiedIndex: 0, TTL: 0}
Reader(0)[write /dev/stdin: bad file descriptor] = 
Err: write /dev/stdin: bad file descriptor
Error:  exit status 1
failed to transform keys

Version-Release number of selected component (if applicable):   3.4.0.11 and etcd 2.3.7 -> etcd3 3.0.12


How reproducible:  always (at least on the OCP 3.4 data sets we have tried)


Steps to Reproduce:
1.   Install OCP 3.4.0.11 with a separate etcd 2.3.7 
2.   Create some projects, pods, etc.   General OCP data
3.   Backup the etcd environment
4.   yum swap etcd etcd3 and verify the OCP env is still operational running etcd3 in etcd2 mode
5.   etcdctl --endpoints $endpoints migrate --data-dir=/var/lib/etcd


Actual results:  Error message (as above)


Expected results:

Successful migration

fix is here: https://github.com/coreos/etcd/pull/6690, we'll need to update our etcdctl binaries.  

Hold off on final update until we've had a bit more time to validate.

Changing sev to high since it blocks migration.

Merged upstream, updating rpm.

Hi Mike,

Can you help to provide some data for etcd for testing this? Seems I can not find OCP 3.4 env for testing it. And I try to reproduce it with some key value with '%' such as "test%" and "%", then migrate datedir from etcd-2.3.7-4 to etcd3-3.0.12-3, also borrow a openshift 3.3 env to test it. But it won't trigger the problem.

It's OK. :) Will following the new bug for the migration problem. And thanks for providing the information.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2890.html