Bucket created using REST API has wrong bucket type

Couchbase Server
1

In spite of specifying bucket type as couchbase, still creates Membase buckets. Steps to reproduce as follows:

Run image:

docker run -p 8091-8093:8091-8093 -p 11207:11207 -p 11210-11211:11210-11211 -p 18091-18092:18091-18092 couchbase/server:enterprise-4.1.0

Create bucket:

curl -v -X POST -u Administrator:password \
-d 'name=test' -d 'ramQuotaMB=100' -d 'bucketType=couchbase' \
-d 'replicaNumber=0' -d 'replicaIndex=0' -d 'proxyPort=0' \
-d 'flushEnabled=1' \
-d 'authType=sasl' -d 'saslPassword=changeit' \
http://192.168.99.100:8091/pools/default/buckets

*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 8091 (#0)
* Server auth using Basic with user 'Administrator'
> POST /pools/default/buckets HTTP/1.1
> Host: 192.168.99.100:8091
> Authorization: Basic QWRtaW5pc3RyYXRvcjpwYXNzd29yZA==
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Length: 139
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 139 out of 139 bytes
< HTTP/1.1 202 Accepted
< Server: Couchbase Server
< Pragma: no-cache
< Location: /pools/default/buckets/test
< Date: Tue, 12 Apr 2016 04:31:03 GMT
< Content-Length: 0
< Cache-Control: no-cache
< 
* Connection #0 to host 192.168.99.100 left intact

Get bucket info:

curl -v -u Administrator:password http://192.168.99.100:8091/pools/default/buckets/test

*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 8091 (#0)
* Server auth using Basic with user 'Administrator'
> GET /pools/default/buckets/test HTTP/1.1
> Host: 192.168.99.100:8091
> Authorization: Basic QWRtaW5pc3RyYXRvcjpwYXNzd29yZA==
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Couchbase Server
< Pragma: no-cache
< Date: Tue, 12 Apr 2016 04:33:07 GMT
< Content-Type: application/json
< Content-Length: 6762
< Cache-Control: no-cache
< 
{"name":"test","bucketType":"membase","authType":"sasl"...
2

It actually is a ‘couchbase’ bucket type. We didn’t want to break compatibility when introducing new features to the bucket (so membase buckets could just add features to become couchbase) so you’ll see further in that description a list of bucket features.

I know it looks a bit odd here, but I’m sure you can understand we wanted people to be able to rebalance upgrade from 1.7 to 1.8 to 2.0 without anything breaking.

3

Thanks for your response.

I know it looks a bit odd here

So you offer 2 types of buckets and you named both of them ‘membase’? That’s not odd at all.

we wanted people to be able to rebalance upgrade from 1.7 to 1.8 to 2.0 without anything breaking

Glad that we all don’t think this way because otherwise human beings would still be living in the caves, because it had started that way and doing something different would break backward compatibility.

4

I don’t think that analogy holds. A piece of software running in an application isn’t sentient and it can’t defend itself. It can’t see that the new hut over there is a much better replacement for the cave and move in. A person can.

If we’d changed that attribute to satisfy our vanity (since the technical issue was handled with the bucket capabilities!), we would have broken a number of apps on upgrade.

With the benefit of hindsight, it looks like the bug was having a bucketType attribute at all. Instead, it seems that maybe we should have had a minimum set of capabilities and a set of capabilities beyond that. That’s what we shifted to. a 4.0 bucket has a N1QL query capability at a query service port. A 3.0 bucket doesn’t have that.