Be consistent about whether we should use v2 to connect or not, and fix
teh monclient check to use the same logic.
Signed-off-by: Sage Weil <sage@redhat.com>
to avoid conflict with other `make check` runs in the same host
See-also: http://tracker.ceph.com/issues/36737
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/25599/head:
mds: do not log internal journal error
mds: clean up log level 2 messages
mds: log session open stats
Reviewed-by: Zheng Yan <zyan@redhat.com>
We check need_addr at the top without a lock held, so we need to be sure
we finished our work before we clear it, or else when there are two racing
threads the first will get the clock and clear the value and the second
will do nothing and see the unlearned value before the first finishes.
Signed-off-by: Sage Weil <sage@redhat.com>
Switch it to be v2. Reject the case where the client sends and addrvec, though;
that should only happen for clients that did_bind, and they should only connect to
v2 if they have a v2 bound addr.
Signed-off-by: Sage Weil <sage@redhat.com>
We could have a fault on a server-side of a non-lossy connectoin where
there is a fault and we have outgoing data queued. Since we are a server,
we cannot connect; we should just go into standby and wait for the other
end to reconnect, or for someone to mark us down.
This fixes a failure reproduced by Messenger/MessengerTest.SyntheticInjectTest/0
where it would assert(!policy.server) in the connect code.
Signed-off-by: Sage Weil <sage@redhat.com>
If of relying on the peer to tell us what address we are connecting from,
look at how our local socket is bound, and use that address.
This removes the possibility for error because we will infer our address
locally and that will be the one place it is decide; the server will just
use our value. As things were previously, we had to make the local and
remote inference match, which was fragile.
This does take away the client's ability to discover if it is traversing
NAT to reach the server and learning its public/external address. I
don't think anybody has ever tested this, so it probably didn't even work,
and I've never heard it come up as a requirement.
Signed-off-by: Sage Weil <sage@redhat.com>
this change reverts "install-deps.sh: workaround setuptools' dependency on six"
This reverts commit 30ce5e5546.
tl;dr: this change addresses the failures of "make check" runs on arm64
builders when they try to build `mgr-dashboard-test-venv` target.
long story: without this change, we will fail to pull in
setuptools >= 36, and as a result pip will fail to import
`setuptools.build_meta` in `pip/_vendor/pep517/_in_process.py`. and will
a `BackendUnavailable` exception thrown by `_call_hook()` in
`pip/_vendor/pep517/wrappers.py`. since the issue addressed by 30ce5e55
has been addressed since setuptools >= 36.0.1, we should be safe to
upgrade to the latest setuptools now.
Signed-off-by: Kefu Chai <kchai@redhat.com>
When disable quota by setting quota.max_files or quota.max_bytes
to zero, client does not receive the quota broadcast message.
Signed-off-by: Junhui Tang <tangjunhui@sangfor.com.cn>
Fixes: https://tracker.ceph.com/issues/38054
Fixes: http://tracker.ceph.com/issues/38030
ES attribute is stored as content_type, while we were searching
for contenttype.
Allow searching by contenttype, content_type, and also lastmodified,
and last_modified.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
Fixes: http://tracker.ceph.com/issues/38028
Since we don't necessarily keep attr headers with null terminating char,
need to be careful when trying to trim them.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
Fixes: http://tracker.ceph.com/issues/36092
send_data_hint is passed so that the lower http client layer
to know in in cases where it's an http request that usually doesn't
send data (e.g., GET) that the request will actually send data,
and initialize the curl client correctly. In a case that was
used by the elasticsearch mechanism it wasn't passed correctly.
Now made it a data member in RGWHTTPClient, which also cleans
the interface a bit.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
using std::pair as the version struct. Another decoder class is currently
introduced as we have a nested json type for version right now.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
For ES endpoints terminated with a username and password, either via xpack or
fronted by another webserver with http basic auth, we now support "username" and
"password" configurable which should be capable of doing HTTP basic
authentication
Fixes: https://tracker.ceph.com/issues/23655
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
from Elasticsearch 5.0+ the type string is deprecated, while it is still allowed
in 5.0, it returns a 400 error on 6.0 clusters as this type is fully removed. We
now determine the es version while initializing the cluster from elasticsearch's
default endpoint and use that to determine what string type to use. This way we
support both 2.x and 5.x,6.x es versions as we default to string type for
clusters < 5.0
Fixes: http://tracker.ceph.com/issues/22877
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Getting the basic information from elasticsearch, while we're only currently
interested in elasic search version, other data such as the ES cluster name etc
may be useful in the future as well.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
This commit introduces an enum mapping various ES types. Also encode_json now
has a new member for string type so that this can be changed easily when
upgrading ES versions for eg. wherein new ES engines do not support the string
type anymore.
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
If we don't know our address yet, send the peer a 0.0.0.0 or :: address with an empty
port and a populated nonce. That way the peer can infer our final addr the same way
we do from learned_addr.
Signed-off-by: Sage Weil <sage@redhat.com>
If we are a client and didn't bind, then we should not fill in the port for our
address. The one the peer sent us is just the random port our outgoing connection
happened to land on!
Signed-off-by: Sage Weil <sage@redhat.com>