Etcd: "Enabling HTTPS" documentation for v3?

[vkhromov]

There is a document describing how to migrate an existing etcd cluster from HTTP communication to encrypted HTTPS.
The document uses v2-based CLI, some of those commands have different args or output format in their v3 equivalent, and some of them (like etcdctl cluster-health) doesn't seem to exist in v3. The document is also marked as deprecated and there is a recommendation to use the GitHub repository for the more recent documentation.
Unfortunately, it seems there is no document describing such migration in the current GitHub repository. Moreover, such document probably better uses v3-based CLI, as more and more etcd installations are moving away from v2.

[spzala]

I also do not see the doc page mentioned here in the master doc. Not sure if it was not moved because of a specific reason or we missed moving it /cc @gyuho @hexfusion

[hexfusion]

I am not sure how common this use-case is honestly, this type of reconfiguration is probably best documented as a snapshot restore operation. In which case we already document all of the necessary runtime configurations [1].

We also already document cluster reconfiguration [2]. But if you wanted to put this all together will full examples and link it from runtime-configuration docs [2] it could be useful.

[1] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/security.md
[2] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/runtime-configuration.md#cluster-reconfiguration-operations

[vkhromov]

That's true that the required steps and changes for the migration could be deduced from the existing docs. Probably the most important property of [1] is that it describes the migration without the etcd cluster downtime, which is not so trivial to archive considering the nature of migration. Particularly, the migration using the snapshot restore operation does require the cluster downtime.

[1] https://coreos.com/etcd/docs/latest/etcd-live-http-to-https-migration.html

[hexfusion]

Particularly, the migration using the snapshot restore operation does require the cluster downtime.

True there is no silver lining here reconfiguring a cluster is risky and snapshot requires downtime.

[kaustubhmallik]

Is this still available to pick up? If so, I would love to go ahead and work on it.

[vkhromov]

@kaustubhmallik it doesn't seem to meet any significant interest from the project owners, so I stopped working on the issue.
Anyway, please feel free to move ahead if you'd like, otherwise I'm going to close the issue.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.