Hopefully this suggestion isn't completely insane. What if we update the schema to accommodate *all* the member related calls, that is, member-create, member-show, and member-update? I think the following will work. I tested it out quickly in the online json-validator, and it does seem to handle the current request bodies and request response.
{
"id": "http://openstack.org/glance/member/schema#",
"$schema": "http://json-schema.org/draft-04/schema#",
"description": "OpenStack Glance image member schema for member-create, member-detail, and member-update requests.",
"type": "object",
"oneOf": [
{ "$ref": "#/definitions/image-member-create-request" },
{ "$ref": "#/definitions/image-member-detail-response" },
{ "$ref": "#/definitions/image-member-update-request" }
],
"definitions": { "image-member-create-request": { "additionalProperties": false, "properties": { "member": { "description": "An identifier for the image member (tenantId). (The image_id of the image to which this request applies is specified in the path of the request.)", "maxLength": 255, "type": "string"
}
}, "required": [ "member"
]
}, "image-member-detail-response": { "additionalProperties": false, "properties": { "created_at": { "description": "Date and time of image member creation", "readOnly": true, "type": "string"
}, "image_id": { "description": "An identifier for the image", "pattern": "^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$", "readOnly": true, "type": "string"
}, "member_id": { "description": "An identifier for the image member (tenantId)", "maxLength": 255, "readOnly": true, "type": "string"
}, "schema": { "readOnly": true, "type": "string"
}, "status": { "description": "The status of this image member", "enum": [ "pending", "accepted", "rejected" ], "readOnly": true, "type": "string"
}, "updated_at": { "description": "Date and time of last modification of image member", "readOnly": true, "type": "string"
}
}, "required": [ "created_at", "image_id", "member_id", "schema", "status", "updated_at"
]
}, "image-member-update-request": { "additionalProperties": false, "properties": { "status": { "description": "Status to which the image member should be set. (The image_id and member_id are specified in the path of the request.)", "enum": [ "pending", "accepted", "rejected" ], "type": "string"
}
}, "required": [ "status"
]
}
}
}
Pros:
1. present behavior of api is maintained
2. not much change in code (just the schema generation code, i think)
3. I don't think this will require any glanceclient changes
Cons:
1. schema is kind of complicated, but the oneOf structure makes it fairly human readable, and of course machines aren't going to care
Hopefully this suggestion isn't completely insane. What if we update the schema to accommodate *all* the member related calls, that is, member-create, member-show, and member-update? I think the following will work. I tested it out quickly in the online json-validator, and it does seem to handle the current request bodies and request response.
http:// jsonschemalint. com/draft4/ #
Here's the schema:
{ openstack. org/glance/ member/ schema#", json-schema. org/draft- 04/schema#", image-member- create- request" }, image-member- detail- response" }, image-member- update- request" }
"image- member- create- request" : {
"additiona lProperties" : false,
"propertie s": {
"member" : {
" description" : "An identifier for the image member (tenantId). (The image_id of the image to which this request applies is specified in the path of the request.)",
" maxLength" : 255,
" type": "string"
"required" : [
"member"
"image- member- detail- response" : {
"additiona lProperties" : false,
"propertie s": {
"created_ at": {
" description" : "Date and time of image member creation",
" readOnly" : true,
" type": "string"
"image_ id": {
" description" : "An identifier for the image",
" pattern" : "^([0-9a- fA-F]){ 8}-([0- 9a-fA-F] ){4}-([ 0-9a-fA- F]){4}- ([0-9a- fA-F]){ 4}-([0- 9a-fA-F] ){12}$" ,
" readOnly" : true,
" type": "string"
"member_ id": {
" description" : "An identifier for the image member (tenantId)",
" maxLength" : 255,
" readOnly" : true,
" type": "string"
"schema" : {
" readOnly" : true,
" type": "string"
"status" : {
" description" : "The status of this image member",
" enum": [
"pending" ,
"accepted" ,
"rejected"
] ,
" readOnly" : true,
" type": "string"
"updated_ at": {
" description" : "Date and time of last modification of image member",
" readOnly" : true,
" type": "string"
"required" : [
"created_ at",
"image_ id",
"member_ id",
"schema" ,
"status" ,
"updated_ at"
"image- member- update- request" : {
"additiona lProperties" : false,
"propertie s": {
"status" : {
" description" : "Status to which the image member should be set. (The image_id and member_id are specified in the path of the request.)",
" enum": [
"pending" ,
"accepted" ,
"rejected"
] ,
" type": "string"
"required" : [
"status"
"id": "http://
"$schema": "http://
"description": "OpenStack Glance image member schema for member-create, member-detail, and member-update requests.",
"type": "object",
"oneOf": [
{ "$ref": "#/definitions/
{ "$ref": "#/definitions/
{ "$ref": "#/definitions/
],
"definitions": {
}
},
]
},
},
},
},
},
},
}
},
]
},
}
},
]
}
}
}
Pros:
1. present behavior of api is maintained
2. not much change in code (just the schema generation code, i think)
3. I don't think this will require any glanceclient changes
Cons:
1. schema is kind of complicated, but the oneOf structure makes it fairly human readable, and of course machines aren't going to care