Add english version of CMS docs #4272
Conversation
✅ Documentation buildRevision built successfully |
❌ Documentation buildRevision build failed Build logsErrors (2)❌ No such file or has no access to /en/manual/maintenance-without-downtime.md ❌ No such file or has no access to /ru/devops/..manual/maintenance-without-downtime.md |
❌ Documentation buildRevision build failed Build logsErrors (3)❌ Link is unreachable: ../../administration/production-storage-config.md#reliability in /en/maintenance/manual/maintenance-without-downtime.md ❌ Link is unreachable: ../../administration/production-storage-config.md#reliability in /ru/maintenance/manual/maintenance-without-downtime.md ❌ Link is unreachable: ./concepts/cluster/common_scheme_ydb.md#tablets in /en/maintenance/manual/maintenance-without-downtime.md |
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully Build logsWarnings (159)
Log was truncated. (144 records) |
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
✅ Documentation buildRevision built successfully Build logsWarnings (159)
Log was truncated. (144 records) |
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
| ``` | ||
| $ ydbops node maintenance --host <node_fqdn> | ||
| ``` | ||
| When executing this command, ydbops will acquire an exclusive lock on the node in CMS. |
There was a problem hiding this comment.
This paragraph sounds weird: typically, multiple YDB nodes are on a single host, and such a command probably needs to acquire locks for all of them. Or maybe this implies only static/storage nodes, but this would need to be explicitly clarified, too.
There was a problem hiding this comment.
Changed parameter to <node_id> to make it more clear. I just took this command from ydb-platform/ydbops#2
It is under active development. When the final variant of the command is chosen, the text in this article will be changed.
There was a problem hiding this comment.
@pixcc I don't think this change fixes the problem: in this article, we shouldn't use "node" and "host" interchangeably. This command sounds more like a maintenance of all (or some) nodes on a given host but not of a single node. Meanwhile, the surrounding text sounds like it is about a single node.
There was a problem hiding this comment.
I removed command to eliminate ambiguity.
It's not 100% clear whether the final version of the command will take out a host for maintenance (with all nodes) or individual nodes, so I've settled on a simple node case for now.
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/maintenance/manual/maintenance-without-downtime.md
Outdated
Show resolved
Hide resolved
|
|
||
| To perform a rolling restart of the entire cluster you can use the command: | ||
| ``` | ||
| $ ydbops restart --endpoint grpc://<cluster-fqdn> --availability-mode strong |
There was a problem hiding this comment.
Doesn't this have some additional requirements? For instance, the last time I tried (a while ago), it couldn't restart a cluster deployed with Ansible because it relied on some different systemd unit naming.
There was a problem hiding this comment.
Things have changed a bit. By default the ydb-server-storage.service systemd name will be used, but it is possible to specify a different systemd unit name with --systemd-unit flag (here is a relevant --help output which contains this flag: https://pastebin.com/Jqcx31Jn).
Just for context: the fact that we have two different default unit names for deploying with Ansible and for everything else (cloud environments etc.) - is horrible and we just have to live with it for a while.
It is probably a good idea to include the mention of --system-unit flag into the docs, but not in too much detail, maybe one sentence only. E.g. "If your systemd unit name is different from the default one, you may need to override it with --systemd-unit flag"
There was a problem hiding this comment.
Added aditional requirements
github-actions
bot
added
the
documentation
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
Changelog category
Additional information
Russian version - #2097