this change is for improve the readability. to emphasis that the
next steps are performed only if a connection to monitor is
established.
Signed-off-by: Kefu Chai <kchai@redhat.com>
for smaller memory foot print. as we don't have lots of mon_command in
flight, hence not likely to benefit from a O(log(n)) lookup.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this behavior matches that of `MonClient::_resend_mon_commands()`. so
far the only user which sends mon command in crimson is
`OSD::_add_me_to_crush()`, but there is still (rare) chance that the connected
monitor cannot be reached when we send the command to it, in that case,
we should retry when the connection is re-established.
Signed-off-by: Kefu Chai <kchai@redhat.com>
as the reason why MMonCommand uses a vector is but for legacy reasons,
there is no need to expose this via the interface.
Signed-off-by: Kefu Chai <kchai@redhat.com>
both of them fall into the category of jobs which we should do after
the connection to monitor is established.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we always send all pending_messages, and clear it when establishing a
connection to mon, so there is no need to check for it when calling
`send_message()`.
Signed-off-by: Kefu Chai <kchai@redhat.com>
before this change, we guard the `send_pendings()` call only in
`Client::send_message()`, after this change, all of the
`send_pendings()` calls are guarded with this check.
more consistent this way.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Lack of this feature was the root cause of an issue in
teuthology testing in which a socket failure injection
happened exactly during `mon_subscribe`; after the OSD
reconnected, the message hasn't been resent and entire
boot process has frozen.
```
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - [osd.2(client) v2:172.21.15.204:6804/33459@57376 >> mon.0 v2:172.21.15.204:3300/0] --> #6 === mon_subscribe({osdmap=1}) v3
(15)
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - authenticated_encrypt_update plaintext.length()=80 buffer.length()=80
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - authenticated_encrypt_final buffer.length()=96 final_len=0
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - authenticated_encrypt_update plaintext.length()=48 buffer.length()=48
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - authenticated_encrypt_update plaintext.length()=16 buffer.length()=64
DEBUG 2021-02-25 11:42:53,757 [shard 0] ms - authenticated_encrypt_final buffer.length()=80 final_len=0
INFO 2021-02-25 11:42:53,758 [shard 0] ms - [osd.2(client) v2:172.21.15.204:6804/33459@57376 >> mon.0 v2:172.21.15.204:3300/0] execute_ready(): fault at READY on lossy
channel, going to CLOSING -- std::system_error (error crimson::net:4, read eof)
```
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
* refs/pull/39680/head:
mds: allow `fs authorize` command to work
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
* refs/pull/39710/head:
qa: run fs:verify on all distros
Reviewed-by: Venky Shankar <vshankar@redhat.com>
Reviewed-by: Yuri Weinstein <yweins@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
This PR breaks the "Deploying a New Ceph Cluster"
section into several sub-sections, so that each sub-section
pertains to only one subject. I've also added some explanatory
text that puts the instructions into context more than they were
before.
Signed-off-by: Zac Dover <zac.dover@gmail.com>
This PR rewrites the section "Bootstrap A New
Cluster" in the Cephadm Guide, in the Install
Chapter. I've broken this section up into what
seem to me to be the topics that the content
naturally divides into.
Signed-off-by: Zac Dover <zac.dover@gmail.com>
Before the commit the `crimson::mon:Connection::reply`
was commented as being specific to the ProtocolV1.
However, the code suggests this member participates also
in V2-related paths like `Connection::renew_tickets()`
where `do_auth()` is called from. `do_auth()` generates
`MAuth` which causes a monitor to send `MAuthReply`.
The `Connection::reply` synchronizes sending the auth
request with response handling.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
At the moment crimson offers only a partial and buggy
support for ProtocolV1. When it enters the production,
V1 will be long obsolete, so spending time on improving
it doesn't seem to be a sound investment while offering
half-baked feature can be worse that lacking it entirely.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
* refs/pull/39631/head:
osd/OSDMap: don't warn on NEW osd ids
mon/OSDMonitor: behave if inc map sets weight on not-yet-existing OSD
mon/OSDMonitor: do not mark newly created OSDs OUT
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
before this change, `this` is wrapped by a smart pointer which is
in turn captured by multiple continuations. the continuation with the
longest life cycle is the one passed to `seastar::repeat()`. where
the underlying `repeater` captures the continuation as its member variable.
and `repeater` is not destroyed before `seastar::repeat()` returns.
so, we only need to capture `opref` in the continuation passed to
`seastar::repeat()`.
Signed-off-by: Kefu Chai <kchai@redhat.com>
