Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1603122

Summary: [DOCS] etcd backup procedure in day two procedure mentions commands for etcd V2 API
Product: OpenShift Container Platform Reporter: Joel Rosental R. <jrosenta>
Component: DocumentationAssignee: Kathryn Alexander <kalexand>
Status: CLOSED CURRENTRELEASE QA Contact: ge liu <geliu>
Severity: medium Docs Contact: Vikram Goyal <vigoyal>
Priority: unspecified    
Version: 3.9.0CC: aos-bugs, jmalde, jokerman, jrosenta, mmccomas, vigoyal, xxia
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-01 16:10:02 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 Joel Rosental R. 2018-07-19 08:58:33 UTC
Document URL: 
https://docs.openshift.com/container-platform/3.9/day_two_guide/environment_backup.html#etcd-data-backup_environment-backup

Section Number and Name: 
Backing up etcd data

Describe the issue: 
The procedure for backing up etcd indicates that if etcd V3 API is used apart from the `etcdctl3 snapshot save` command (which should be enough) a V2 command (etcdctl backup) is needed.

Apart from this, OCP 3.9 can only be used with API V3, therefore I think having commands related to API V2 there creates confusion.

Suggestions for improvement: 
Delete commands regarding to V2 API, e.g: etcdctl2 backup

Comment 4 Kathryn Alexander 2018-07-26 20:43:10 UTC
@Wang Haoran, you were very helpful with my last set of doc updates for etcd. Will you PTAL at this PR?

https://github.com/openshift/openshift-docs/pull/11121

Comment 5 Scott Dodson 2018-07-27 12:47:49 UTC
Joel,

I feel the documentation is safest and most clear in its current state. Rather than asking the admin the question of "Are you using v2 or v3?" we're just simply backing up both datastores which is always a safe thing to do.

Are there situations where the commands, as documented currently, fail? I'm not aware of any.

Comment 7 Scott Dodson 2018-07-27 13:00:58 UTC
Perhaps then we should clarify why we're saying to backup both. Something like

"Because clusters upgraded from previous versions of the product may have v2 data stores present we advise backing up both v2 and v3 data even in versions 3.6 and later."


At least in the versions of etcd that we used at the time of migration if you failed to backup the v2 data store and only backed up the v3 data store etcd would fail to start after having been restored.

This is also what the upgrade playbooks do when they backup etcd.

Comment 8 Joel Rosental R. 2018-07-27 13:38:09 UTC
Do you remember by any chance what etcd version was it?

In fact as per the official etcd documentation `etcdctl backup` is not required anymore as there isn't a "backup" concept per se at V3.

Comment 9 ge liu 2018-07-30 05:40:50 UTC
@kalexand, added comment in pr: https://github.com/openshift/openshift-docs/pull/11121, i will close this bug after we reach an agreement, thx

Comment 10 Kathryn Alexander 2018-07-31 15:17:03 UTC
I think the final decision was to keep the commands as they are and add a note explaining that the v3 commands back up both the v2 and v3 data stores. I've sent the note out for peer review and will merge after that review.

Comment 11 openshift-github-bot 2018-07-31 17:44:45 UTC
Commits pushed to master at https://github.com/openshift/openshift-docs

https://github.com/openshift/openshift-docs/commit/c499b985fb4180b54030f980d36ca8bffc10184d
bug 1603122 clarifying need for etcd v2 and v3 datastores

https://github.com/openshift/openshift-docs/commit/79181ec335eb561c244430e1150e6d1b41113153
Merge pull request #11121 from kalexand-rh/BZ1603122

bug 1603122 clarifying need for etcd v2 and v3 datastores

Comment 13 Kathryn Alexander 2018-08-09 17:39:38 UTC
*** Bug 1609574 has been marked as a duplicate of this bug. ***