I use grpcurl for grpc request. I have the following request:
grpcurl -plaintext -import-path C:/Users/username -proto file.proto <localhost:port > service_name/methode
The mentioned request will return the following response without the status code. How can I get the status code within the response?
{
"id": "0000000000000",
"name": "AAAAAAAAAA"
}
You cannot (directly).
Error codes are part of the gRPC protocol metadata not the (user-defined) message(s).
With gRPCurl, you've a couple of ways to get the error code.
In Bash, you can use command's exit status:
grpcurl ...
echo $?
See:
Need documentation for gRPC error codes
See gRPC canonical error codes
Or you can use gRPCurl's -format-error flag.
-format-error
When a non-zero status is returned, format the response using the
value set by the -format flag .
Related
Introduction
There is a CLI tool to interact with containerd called ctr. However I would like to achieve the same results without it using curl, after searching on google it can't be done with curl but grpcurl instead.
How can I do basic gRPC calls to containerd?
What I have tried
First I downloaded both grpcurl and api.proto.
Then I listed available services:
vagrant#ubuntu-focal:~/containerd/api/grpc/types$ grpcurl -import-path . -proto api.proto list
types.API
vagrant#ubuntu-focal:~/containerd/api/grpc/types$ grpcurl -import-path . -proto api.proto list types.API
types.API.AddProcess
types.API.CreateCheckpoint
types.API.CreateContainer
types.API.DeleteCheckpoint
types.API.Events
types.API.GetServerVersion
types.API.ListCheckpoint
types.API.Signal
types.API.State
types.API.Stats
types.API.UpdateContainer
types.API.UpdateProcess
Used protoc to create a compiled version instead but didnt seem to change anything.
Finally tried making a request to the method Stats (including containerd's UNIX socket path and -plaintext). However it seems I am messing something up, here is the error (both using --proto and --protoset:
sudo grpcurl -plaintext -protoset myservice.protoset -unix /run/containerd/containerd.sock types.API/Stats
ERROR:
Code: Unimplemented
Message: unknown service types.API
sudo grpcurl -plaintext -proto api.proto -unix /run/containerd/containerd.sock types.API.Stats
ERROR:
Code: Unimplemented
Message: unknown service types.API
Also tried with:
API/Stats
API.Stats
types.API.Stats
I cloned the wrong repo instead of containerd.
To check it working use the following request:
vagrant#ubuntu-focal:~/containerd/api/services/version/v1$ sudo grpcurl -plaintext -proto version.proto -unix /run/containerd/containerd.sock containerd.services.version.v1.Version/Version
{
"version": "1.5.5-0ubuntu3~20.04.2"
}
In this doc A short introduction to Channelz, there is a web tool called grpc-zpages conveniently serve channelz data through a web page.
However, we cannot find any TopChannels data from this web tool. Does someone meet the same issue?
To make this web tool run, there are some changes to the codes
Add the following codes to http_filters of zprox.sh
function envoy_on_response(response_handle)
filter_name = "ENVOY"
response_handle:headers():add("my_Filter", filter_name)
end
to solve the error envoy_on_response() function not found. lua filter will not hook responses
Comment network_mode: 'host' of start_docker.sh to solve the error docker.errors.InvalidArgument: "host" network_mode is incompatible with port_bindings
Replace manual.GenerateAndRegisterManualResolver() with
r := manual.NewBuilderWithScheme("whatever")
r.InitialState(resolver.State{Addresses: []resolver.Address{{Addr: ":10001"}, {Addr: ":10002"}, {Addr: ":10003"}}})
// Set up a connection to the server.
conn, err := grpc.Dial(r.Scheme()+":///test.server",
grpc.WithInsecure(),
grpc.WithResolvers(r),
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`),
)
under grpc 1.37.1
Please make sure you had added channelz service and reflection service to the server. If your service is a client, you need to make the client has a grpc server also. After call server and the channel is connected, the related data could be fetched.
The grpc-zpages is not maintain anymore, and it is hard to use. I suggest to use channelzcli replace.
I also had trouble using the web tool and ended up using grpcurl.
One thing that took me a while to realize is that in order to activate channelz on your grpc client you need to run a grpc server and enable channelz on your client service alongside your grpc client
Some grpcurl useful commands for Channelz:
Query for the Channelz service API, to see all available methods:
grpcurl -plaintext -msg-template localhost:50052 describe grpc.channelz.v1.Channelz
Query method template to understand what parameters it requires:
grpcurl -plaintext -msg-template localhost:50052 describe .grpc.channelz.v1.GetSocketReques
Client commands examples (make sure to use the client port):
grpcurl -plaintext localhost:50052 grpc.channelz.v1.Channelz/GetTopChannels
grpcurl -plaintext -d '{"subchannel_id":"14"}' localhost:50052 grpc.channelz.v1.Channelz/GetSubchannel
grpcurl -plaintext -d '{"socket_id":"34"}' localhost:50052 grpc.channelz.v1.Channelz/GetSocket
Server commands (make sure to use the server port):
grpcurl -plaintext localhost:50051 grpc.channelz.v1.Channelz/GetServers
grpcurl -plaintext -d '{"server_id":"2"}' localhost:50051 grpc.channelz.v1.Channelz/GetServerSockets
grpcurl -plaintext -d '{"socket_id":"21"}' localhost:50051 grpc.channelz.v1.Channelz/GetSocket
I'm facing something new in my experience. An updated Yocto environment fails to build while fetching MariaDB:
WARNING: mariadb-5.5.64-r0 do_fetch: Failed to fetch URL https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz, attempting MIRRORS if available
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-BIEhFRRkoA"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/scripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin/arm-openstlinux_eglfs-linux-gnueabi:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot/usr/bin/crossscripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/bitbake/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/hosttools"; export HOME="/home/osboxes"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/downloads 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz' --progress=dot -v failed with exit code 8, output:
--2019-11-03 12:10:45-- https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving downloads.mariadb.org (downloads.mariadb.org)... 116.203.207.31, 2a01:4f8:c2c:b04e::1
Connecting to downloads.mariadb.org (downloads.mariadb.org)|116.203.207.31|:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz [following]
--2019-11-03 12:10:46-- http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving ftp.hosteurope.de (ftp.hosteurope.de)... 80.237.136.138, 2a01:488:10:1::50ed:888a
Connecting to ftp.hosteurope.de (ftp.hosteurope.de)|80.237.136.138|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-11-03 12:10:46 ERROR 404: Not Found.
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure for URL: 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz'. Unable to fetch URL from any source.
ERROR: mariadb-5.5.64-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/temp/log.do_fetch.11382
ERROR: Task (/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb_5.5.64.bb:do_fetch) failed with exit code '1'
Now I see the URLs are hardcoded into: layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb.inc:
SUMMARY = "A robust, scalable, and reliable SQL server"
HOMEPAGE = "http://mariadb.org"
SECTION = "libs"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
SRC_URI = "https://downloads.mariadb.org/f/${BP}/source/${BP}.tar.gz \
file://fix-cmake-module-path.patch \
file://remove-bad-path.patch \
file://fix-mysqlclient-r-version.patch \
file://my.cnf \
file://mysqld.service \
file://install_db.service \
file://install_db \
file://mysql-systemd-start \
file://configure.cmake-fix-valgrind.patch \
file://fix-a-building-failure.patch \
file://change-cc-to-cc-version.patch \
file://0001-disable-ucontext-on-musl.patch \
"
Hence, I tried to retrieve the same file (mariadb-5.5.64.tar.gz) on the Internet and I found this:
https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz/from/http%3A//ftp.hosteurope.de/mirror/archive.mariadb.org/?serve
that seems very close to the one above, but the working one has another path as suffix.
I don't understand if they (the mariadb maintainers) changed the URLs or there is an error in the meta-openembedded recipe.
The maintainers of FOSS software, in this case the MariaDB Foundation, usually don't make promises that download URLS will remain unchanged. MariaDB uses a scheme to help downloaders find a nearby mirror site, and that's what you found.
Those mirrorfinders rely on stuff like http redirect operations. Browsers are good at handling those operations. Downloading code built into other programs may not be.
You may find it helpful to edit that URL in that recipe to point to the exact ftp file you need. It appears to be in this ftp folder.
http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-5.5.64/source/
I need to perform a get request from nifi to couchbase. The curl command is:
curl http://HOST:PORT/query/service -d "statement=select item.Date from bucket unnest bucket as item" -u USER:PASSWORD
I tried using InvokeHttp and ExecuteStreamCommand but it keeps returning errors(status code 400). The full error message is:
{ "requestID": "bff62c0b-36fd-401d-bca0-0959e0944323", "errors":
[{"code":1050,"msg":"No statement or prepared value"}], "status":
"fatal", "metrics": {"elapsedTime": "113.31µs","executionTime":
"74.321µs","resultCount": 0,"resultSize": 0,"errorCount": 1
It's important to say that I prefer that the http request will be triggered by an incoming flowfile. I tried using the processors in various of ways but non of them worked.
When I run the command from the nifi server it works fine.
Thanks for the help
the -d parameter of the curl utility forces HTTP POST command
and application/x-www-form-urlencoded mime-type.
so, in the nifi InvokeHTTP select the following parameters
HTTP Method = POST
Remote URL = <your url here>
Basic Authentication Username = <username>
Basic Authentication Password = <password>
Content-Type = application/x-www-form-urlencoded
and the body of the flow file should be
statement=select item.Date from bucket unnest bucket as item
I don't know nifi, but based on the error message, the "statement=" part of the request isn't being included, or you are not sending the request as a POST command.
I am learning OpenStack now and I want to list all accessible volumes on my OpenStack controller by HTTP get request with x_auth_token:
http://{OpenStack controller IP}:8776/v3/{project_id}/volumes
(Reference URL: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=#list-accessible-volumes)
But, the request body always as below:
{
"badRequest":{
"message": "Malformed request url",
"code": 400
}
}
I have try many times but they all didn't work.
So, I want to know, what the request url should be here?
Thanks in advance.....
One of the possible reasons is that your project_id is incorrect or doesn't match your credential, take a look at this link. In order to solve this problem you can:
1. Try openstack command with debug option.
openstack --debug volume list
#or
cinder --debug list
you could get the request and response details:
REQ: curl -g -i -X GET http://ip:port/v3/{project_id}/volumes/detail -H "User-Agent: python-cinderclient" -H "Accept: application/json" -H "X-Auth-Token: {token_value}"
Make sure you have input every required headers(context-type/x-auth-token/...).
Try to ask for help in irc channel #openstack-cinder