Difference between revisions of "Trove/datastore-visibility"

Latest revision as of 18:49, 31 October 2014

Description

This blueprint suggests adding a visibility attribute to the datastore versions. This enables the datastore to be still active, but not visible to the users.

Blueprint: https://blueprints.launchpad.net/trove/+spec/datastore-visibility

Justification/Benefits

There might be some datastores, which the deployers require to be active but not visible to customers in production environment. This visibility flag ensures that only the datastore versions which have been marked as public are visible in the list. Example use case: Say we want to have an active datastore A in production and not expose it to customers yet. The visibility flag will ensure it is visible on the datastore list call only to admins.

Impacts

Configuration

None

Database

This involves

• database migration of adding a column visibility to the datastore_versions table.

• new table datastore_version_members which consists of columns - id, datastore_version_id, tenant_id

ReST API

A. visibility attribute to the datastore version. It can be public/private/unlisted.
B. adding a datastore version members table to add tenants for private datastores.

(1) If visibility is public, then
all users

*can view it in the list and 
*make a GET call on the datastore version

all admin

*can view it in the list and 
*make a GET call on the datastore version

(2) If visibility is private, then
users who are members of the datastore version

*can view it in the list and 
*make a GET call on the datastore version

all admin

*can view it in the list and 
*make a GET call on the datastore version
*add and remove tenants as members of a datastore version

(3)If visibility is unlisted, then
all users

*can make a GET call on the datastore version

all admin

*can view it in the list and 
*make a GET call on the datastore version

Admin calls related to datastore versions

1. Set visibility

POST /{tenant_id}/mgmt/datastores/{datastore}/versions/{id}

{
    "datastore_version": {
        "visbility": "<visibility value>"
    }
}

2. Get datastore version
A visibility field added only for admin users.

GET /{tenant_id}/datastores/{datastore_id}/versions/{id}

{
    "version": {
        "active": true, 
        "datastore": "9dd70f56-72e9-444b-9881-f564ac955056", 
        "id": "65747630-1ce7-4be0-92d4-8695825a475b", 
        "image": "32070be9-3cab-4cee-be05-524b4f379447", 
        "links": [
            {
                "href": "https://172.16.117.178:8779/v1.0/9a4e7142f34b4ce990a276c82b7beb15/datastores/versions/65747630-1ce7-4be0-92d4-8695825a475b", 
                "rel": "self"
            }, 
            {
                "href": "https://172.16.117.178:8779/datastores/versions/65747630-1ce7-4be0-92d4-8695825a475b", 
                "rel": "bookmark"
            }
        ], 
        "name": "5.5", 
        "packages": "mysql-server-5.5", 
        "visibility": "public"
    }
}

Admin calls related to datastore version members

1. Add a member

POST /{tenant_id}/mgmt/datastores/{datastore}/versions/{id}/members

{"member": "<TENANT_ID>"}

2. Delete a member

DELETE /{tenant_id}/mgmt/datastores/{datastore}/versions/{id}/members/{member_id}

3. Get a member

GET  /{tenant_id}/mgmt/datastores/{datastore}/versions/{id}/members/{member_id}


Response:

{ "datastore_version_member":
  { "id": "<MEMBER_ID>",
    "datastore_version_id": "<DATASTORE_VERSION_ID>",
    "member": "<TENANT_ID>"
  }
}

4. List members for datastore version

GET  /{tenant_id}/mgmt/datastores/{datastore}/versions/{id}/members

Response:

{ "datastore_version_members":[
   { "id": "<MEMBER_ID>", 
     "datastore_version_id": "<DATASTORE_VERSION_ID>", 
     "member": "<TENANT_ID>"},
   { "id": "<MEMBER_ID>", 
     "datastore_version_id": "<DATASTORE_VERSION_ID>",
     "member": "<TENANT_ID>"}]
}

5. Get members by tenant id

GET /{tenant_id}/mgmt/datastores/{datastore}/versions/members/{tenant_id}

Response:

{ "datastore_version_members":[
   { "id": "<MEMBER_ID>",
      "datastore_version_id": "<DATASTORE_VERSION_ID>",
      "member": "<TENANT_ID>"
   },
   { "id": "<MEMBER_ID>",
     "datastore_version_id": "<DATASTORE_VERSION_ID>",
     "member": "<TENANT_ID>"
    }]
}

Comments/Questions From Community

FAQ:

(1) Why is the flag a string visibility vs a boolean is_public?
In glance, we have is_public as a boolean flag. But as we started introducing new features like image sharing, we realized that having a boolean made it harder to add more visibility related features. Hence, in order to keep it extensible, the visibility flag. The currently supported values for it will be 'public' which are visible to users and 'private' which are not visible to users.

(2)What happens if a user that is not added as a member tries to create an instance with a datastore version whose visibility is private,i.e. gets hold of the UUID of the hidden datastore version?
The create will fail. It will behave like the datastore version does not exist.

(3)What happens if a user that is not added as a member tries to create an instance with a datastore version whose visibility is unlisted,i.e. gets hold of the UUID of the datastore version?
The create will be successful.