Open remilapeyre opened 4 years ago
@remilapeyre Given your curl commands above it looks like the catalog/services endpoint was returning an error but the catalog/nodes one was not.
This is expected behavior. Nodes are not namespaced (we probably need to document all of this better). That endpoint ignores the ns query param just like sending any other unknown query param.
Oh, ok, I got confused because of the ns
parameter in /catalog/register
. This makes sense, thanks!
By the way, the behavior when specifying the namespace default
is slightly confusing:
$ curl 'http://localhost:8500/v1/catalog/services?ns=default'
Bad request: Invalid query parameter: "ns" - Namespaces is a Consul Enterprise feature
$ curl -X POST -d '{ "SourceName": "web",
"SourceNS": "default",
"DestinationName": "db",
"DestinationNS": "default",
"SourceType": "consul",
"Action": "allow"
}' http://127.0.0.1:8500/v1/connect/intentions
{
"ID": "5e2cc2d6-fa14-0d0e-e847-b79422363a67"
}
$ curl -X PUT -d '{
"Name": "example-role",
"Description": "Showcases all input parameters",
"Namespace": "default"
}' http://127.0.0.1:8500/v1/acl/role
Bad request: Role decoding failed: json: unknown field "Namespace" - Namespaces is a Consul Enterprise feature
It seems to me that default
should be accepted eveywhere as it will make writing tools that work both with Consul Community and Consul Enterprise easier. I had to handle both explicitly at https://github.com/terraform-providers/terraform-provider-consul/pull/183/commits/25885b722f3f1a8e3abec0e06fb4bfab2e3a5865#diff-2348923b31627050bb4a988d8e762e8cR110-R116 for example.
The Config Entries also have this behavior, they all accept and return a Namespace
argument in Enterprise that defaults to default
but Community Edition will refuse it.
The
/v1/catalog/services
does not return an error when specifying a namespace in the Community Edition, I think it's the only endpoint that does that:Is the call to
parseEntMetaNoWildcard()
just missing?