Re: [openstack-dev] [python-glanceclient] Return request-id to caller
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 11 December 2015 09:19
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
>
>
>
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 10 December 2015 12:56
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
>
>
>
> -Original Message-
> From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com]
> Sent: 09 December 2015 23:54
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
>
> > Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
> >> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
> >>> Hi Devs,
> >>>
> >>>
> >>>
> >>> We are adding support for returning ?x-openstack-request-id? to the
> >>> caller as per the design proposed in cross-project specs:
> >>>
> >>> http://specs.openstack.org/openstack/openstack-specs/specs/
> >>> return-request-id.html
> >>>
> >>>
> >>>
> >>> Problem Description:
> >>>
> >>> Cannot add a new property of list type to the warlock.model object.
> >>>
> >>>
> >>>
> >>> How is a model object created:
> >>>
> >>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
> >>>
> >>>
> >>>
> >>> Here after getting the response we call model() method. This model()
> >>> does the job of creating a warlock.model object(essentially a dict)
> >>> based on the schema given as argument (image schema retrieved from
> >>> glance in this case). Inside
> >>> model() the raw() method simply return the image schema as JSON
> >>> object. The advantage of this warlock.model object over a simple
> >>> dict is that it validates any changes to object based on the rules
> >>> specified
> in the reference schema.
> >>> The keys of this model object are available as object properties to
> >>> the caller.
> >>>
> >>>
> >>>
> >>> Underlying reason:
> >>>
> >>> The schema for different sub APIs is returned a bit differently. For
> >>> images, metadef APIs glance.schema.Schema.raw() is used which
> >>> returns a schema containing ?additionalProperties?: {?type?:
> >>> ?string?}. Whereas for members and tasks APIs
> >>> glance.schema.Schema.minimal() is used to return schema object which
> does not contain ?additionalProperties?.
> >>>
> >>>
> >>>
> >>> So we can add extra properties of any type to the model object
> >>> returned from members or tasks API but for images and metadef APIs
> >>> we can only add properties which can be of type string. Also for the
> >>> latter case we depend on the glance configuration to allow additional
> properties.
> >>>
> >>>
> >>>
> >>> As per our analysis we have come up with two approaches for
> >>> resolving this
> >>> issue:
> >>>
> >>>
> >>>
> >>> Approach #1: Inject request_ids property in the warlock model
> >>> object in glance client
> >>>
> >>> Here we do the following:
> >>>
> >>> 1. Inject the ?request_ids? as additional property into the model
> >>> object (returned from model())
> >>>
> >>> 2. Return the model object which now contains request_ids property
> >>>
> >>>
> >>>
> >>> Limitations:
> >>>
> >>> 1. Because the glance schemas for images and metadef only allows
> >>> additional properties of type string, so even though natural type of
> >>> request_ids should be list we have to make it as a comma separated
> >>> ?string? of request ids as a compromise.
> >>>
> >>> 2. Lot of extra code is needed to wrap objects returned from the
> >>> client API so that the caller can get request ids. For example we
> >>> need to write wrapper classes for dict, list, str, tuple, generator.
> >>>
> >>> 3. Not a good design as we
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 10 December 2015 12:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller
-Original Message-
From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com]
Sent: 09 December 2015 23:54
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller
> Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
>> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
>>> Hi Devs,
>>>
>>>
>>>
>>> We are adding support for returning ?x-openstack-request-id? to the
>>> caller as per the design proposed in cross-project specs:
>>>
>>> http://specs.openstack.org/openstack/openstack-specs/specs/
>>> return-request-id.html
>>>
>>>
>>>
>>> Problem Description:
>>>
>>> Cannot add a new property of list type to the warlock.model object.
>>>
>>>
>>>
>>> How is a model object created:
>>>
>>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
>>>
>>>
>>>
>>> Here after getting the response we call model() method. This model()
>>> does the job of creating a warlock.model object(essentially a dict)
>>> based on the schema given as argument (image schema retrieved from
>>> glance in this case). Inside
>>> model() the raw() method simply return the image schema as JSON
>>> object. The advantage of this warlock.model object over a simple
>>> dict is that it validates any changes to object based on the rules
>>> specified in the reference schema.
>>> The keys of this model object are available as object properties to
>>> the caller.
>>>
>>>
>>>
>>> Underlying reason:
>>>
>>> The schema for different sub APIs is returned a bit differently. For
>>> images, metadef APIs glance.schema.Schema.raw() is used which
>>> returns a schema containing ?additionalProperties?: {?type?:
>>> ?string?}. Whereas for members and tasks APIs
>>> glance.schema.Schema.minimal() is used to return schema object which does
>>> not contain ?additionalProperties?.
>>>
>>>
>>>
>>> So we can add extra properties of any type to the model object
>>> returned from members or tasks API but for images and metadef APIs
>>> we can only add properties which can be of type string. Also for the
>>> latter case we depend on the glance configuration to allow additional
>>> properties.
>>>
>>>
>>>
>>> As per our analysis we have come up with two approaches for
>>> resolving this
>>> issue:
>>>
>>>
>>>
>>> Approach #1: Inject request_ids property in the warlock model
>>> object in glance client
>>>
>>> Here we do the following:
>>>
>>> 1. Inject the ?request_ids? as additional property into the model
>>> object (returned from model())
>>>
>>> 2. Return the model object which now contains request_ids property
>>>
>>>
>>>
>>> Limitations:
>>>
>>> 1. Because the glance schemas for images and metadef only allows
>>> additional properties of type string, so even though natural type of
>>> request_ids should be list we have to make it as a comma separated
>>> ?string? of request ids as a compromise.
>>>
>>> 2. Lot of extra code is needed to wrap objects returned from the
>>> client API so that the caller can get request ids. For example we
>>> need to write wrapper classes for dict, list, str, tuple, generator.
>>>
>>> 3. Not a good design as we are adding a property which should
>>> actually be a base property but added as additional property as a
>>> compromise.
>>>
>>> 4. There is a dependency on glance whether to allow
>>> custom/additional properties or not. [2]
>>>
>>>
>>>
>>> Approach #2: Add ?request_ids? property to all schema definitions
>>> in glance
>>>
>>>
>>>
>>> Here we add ?request_ids? property as follows to the various APIs (schema):
>>>
>>>
>>>
>>> ?request_ids?: {
>>>
>>> "type": "array",
>>>
>>> "items": {
>>>
>>>"type": &qu
[openstack-dev] [python-glanceclient] Return request-id to caller
Hi Devs,
We are adding support for returning 'x-openstack-request-id' to the caller as
per the design proposed in cross-project specs:
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
Problem Description:
Cannot add a new property of list type to the warlock.model object.
How is a model object created:
Let's take an example of glanceclient.api.v2.images.get() call [1]:
Here after getting the response we call model() method. This model() does the
job of creating a warlock.model object(essentially a dict) based on the schema
given as argument (image schema retrieved from glance in this case). Inside
model() the raw() method simply return the image schema as JSON object. The
advantage of this warlock.model object over a simple dict is that it validates
any changes to object based on the rules specified in the reference schema.
The keys of this model object are available as object properties to the caller.
Underlying reason:
The schema for different sub APIs is returned a bit differently. For images,
metadef APIs glance.schema.Schema.raw() is used which returns a schema
containing "additionalProperties": {"type": "string"}. Whereas for members and
tasks APIs glance.schema.Schema.minimal() is used to return schema object which
does not contain "additionalProperties".
So we can add extra properties of any type to the model object returned from
members or tasks API but for images and metadef APIs we can only add properties
which can be of type string. Also for the latter case we depend on the glance
configuration to allow additional properties.
As per our analysis we have come up with two approaches for resolving this
issue:
Approach #1: Inject request_ids property in the warlock model object in glance
client
Here we do the following:
1. Inject the 'request_ids' as additional property into the model
object(returned from model())
2. Return the model object which now contains request_ids property
Limitations:
1. Because the glance schemas for images and metadef only allows additional
properties of type string, so even though natural type of request_ids should be
list we have to make it as a comma separated 'string' of request ids as a
compromise.
2. Lot of extra code is needed to wrap objects returned from the client API so
that the caller can get request ids. For example we need to write wrapper
classes for dict, list, str, tuple, generator.
3. Not a good design as we are adding a property which should actually be a
base property but added as additional property as a compromise.
4. There is a dependency on glance whether to allow custom/additional
properties or not. [2]
Approach #2: Add 'request_ids' property to all schema definitions in glance
Here we add 'request_ids' property as follows to the various APIs (schema):
"request_ids": {
"type": "array",
"items": {
"type": "string"
}
}
Doing this will make changes in glance client very simple as compared to
approach#1.
This also looks a better design as it will be consistent.
We simply need to modify the request_ids property in various API calls for
example glanceclient.v2.images.get().
Please let us know which approach is better or any suggestions for the same.
[1]
https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L179
[2] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L944
__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
> >Hi Devs,
> >
> >
> >
> >We are adding support for returning ‘x-openstack-request-id’ to the caller
> >as
> >per the design proposed in cross-project specs:
> >
> >http://specs.openstack.org/openstack/openstack-specs/specs/
> >return-request-id.html
> >
> >
> >
> >Problem Description:
> >
> >Cannot add a new property of list type to the warlock.model object.
> >
> >
> >
> >How is a model object created:
> >
> >Let’s take an example of glanceclient.api.v2.images.get() call [1]:
> >
> >
> >
> >Here after getting the response we call model() method. This model() does the
> >job of creating a warlock.model object(essentially a dict) based on the
> >schema
> >given as argument (image schema retrieved from glance in this case). Inside
> >model() the raw() method simply return the image schema as JSON object. The
> >advantage of this warlock.model object over a simple dict is that it
> >validates
> >any changes to object based on the rules specified in the reference schema.
> >The keys of this model object are available as object properties to the
> >caller.
> >
> >
> >
> >Underlying reason:
> >
> >The schema for different sub APIs is returned a bit differently. For images,
> >metadef APIs glance.schema.Schema.raw() is used which returns a schema
> >containing “additionalProperties”: {“type”: “string”}. Whereas for members
> >and
> >tasks APIs glance.schema.Schema.minimal() is used to return schema object
> >which
> >does not contain “additionalProperties”.
> >
> >
> >
> >So we can add extra properties of any type to the model object returned from
> >members or tasks API but for images and metadef APIs we can only add
> >properties
> >which can be of type string. Also for the latter case we depend on the glance
> >configuration to allow additional properties.
> >
> >
> >
> >As per our analysis we have come up with two approaches for resolving this
> >issue:
> >
> >
> >
> >Approach #1: Inject request_ids property in the warlock model object in
> >glance
> >client
> >
> >Here we do the following:
> >
> >1. Inject the ‘request_ids’ as additional property into the model object
> >(returned from model())
> >
> >2. Return the model object which now contains request_ids property
> >
> >
> >
> >Limitations:
> >
> >1. Because the glance schemas for images and metadef only allows additional
> >properties of type string, so even though natural type of request_ids should
> >be
> >list we have to make it as a comma separated ‘string’ of request ids as a
> >compromise.
> >
> >2. Lot of extra code is needed to wrap objects returned from the client API
> >so
> >that the caller can get request ids. For example we need to write wrapper
> >classes for dict, list, str, tuple, generator.
> >
> >3. Not a good design as we are adding a property which should actually be a
> >base property but added as additional property as a compromise.
> >
> >4. There is a dependency on glance whether to allow custom/additional
> >properties or not. [2]
> >
> >
> >
> >Approach #2: Add ‘request_ids’ property to all schema definitions in glance
> >
> >
> >
> >Here we add ‘request_ids’ property as follows to the various APIs (schema):
> >
> >
> >
> >“request_ids”: {
> >
> > "type": "array",
> >
> > "items": {
> >
> >"type": "string"
> >
> > }
> >
> >}
> >
> >
> >
> >Doing this will make changes in glance client very simple as compared to
> >approach#1.
> >
> >This also looks a better design as it will be consistent.
> >
> >We simply need to modify the request_ids property in various API calls for
> >example glanceclient.v2.images.get().
> >
>
> Hey Abhishek,
>
> thanks for working on this.
>
> To be honest, I'm a bit confused on why the request_id needs to be an
> attribute of the image. Isn't it passed as a header? Does it have to
> be an attribute so we can "print" it?
The requirement they're trying to meet is to make the request id
available to the user of the client library [1]. The user typically
doesn't have access to the headers, so the request id needs to be
part of the payload returned from each method. In other clients
that work with simple data types, they've subclassed dict, list,
etc. to add the extra property. This adds the request id to the
return value without making a breaking change to the API of the
client library.
Abhishek, would it be possible to add the request id information
to the schema data in glance client, before giving it to warlock?
I don't know whether warlock asks for the schema or what form that
data takes (dictionary, JSON blob, etc.). If it's a dictionary
visible to the client code it would be straightforward to add data
to it.
Failing that, is it possible to change warlock to allow extra
properties with arbitrary types to be added to objects? Because
validating inputs to the constructor is all well and good, but
breaking the ability to add data to an object
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
On 09/12/15 11:33 +, Kekane, Abhishek wrote:
Hi Devs,
We are adding support for returning ‘x-openstack-request-id’ to the caller as
per the design proposed in cross-project specs:
http://specs.openstack.org/openstack/openstack-specs/specs/
return-request-id.html
Problem Description:
Cannot add a new property of list type to the warlock.model object.
How is a model object created:
Let’s take an example of glanceclient.api.v2.images.get() call [1]:
Here after getting the response we call model() method. This model() does the
job of creating a warlock.model object(essentially a dict) based on the schema
given as argument (image schema retrieved from glance in this case). Inside
model() the raw() method simply return the image schema as JSON object. The
advantage of this warlock.model object over a simple dict is that it validates
any changes to object based on the rules specified in the reference schema.
The keys of this model object are available as object properties to the
caller.
Underlying reason:
The schema for different sub APIs is returned a bit differently. For images,
metadef APIs glance.schema.Schema.raw() is used which returns a schema
containing “additionalProperties”: {“type”: “string”}. Whereas for members and
tasks APIs glance.schema.Schema.minimal() is used to return schema object which
does not contain “additionalProperties”.
So we can add extra properties of any type to the model object returned from
members or tasks API but for images and metadef APIs we can only add properties
which can be of type string. Also for the latter case we depend on the glance
configuration to allow additional properties.
As per our analysis we have come up with two approaches for resolving this
issue:
Approach #1: Inject request_ids property in the warlock model object in glance
client
Here we do the following:
1. Inject the ‘request_ids’ as additional property into the model object
(returned from model())
2. Return the model object which now contains request_ids property
Limitations:
1. Because the glance schemas for images and metadef only allows additional
properties of type string, so even though natural type of request_ids should be
list we have to make it as a comma separated ‘string’ of request ids as a
compromise.
2. Lot of extra code is needed to wrap objects returned from the client API so
that the caller can get request ids. For example we need to write wrapper
classes for dict, list, str, tuple, generator.
3. Not a good design as we are adding a property which should actually be a
base property but added as additional property as a compromise.
4. There is a dependency on glance whether to allow custom/additional
properties or not. [2]
Approach #2: Add ‘request_ids’ property to all schema definitions in glance
Here we add ‘request_ids’ property as follows to the various APIs (schema):
“request_ids”: {
"type": "array",
"items": {
"type": "string"
}
}
Doing this will make changes in glance client very simple as compared to
approach#1.
This also looks a better design as it will be consistent.
We simply need to modify the request_ids property in various API calls for
example glanceclient.v2.images.get().
Hey Abhishek,
thanks for working on this.
To be honest, I'm a bit confused on why the request_id needs to be an
attribute of the image. Isn't it passed as a header? Does it have to
be an attribute so we can "print" it?
As it is presented in your email, I'd probably go with option #2 but
I'm curious to know the answer to my question.
Cheers,
Flavio
Please let us know which approach is better or any suggestions for the same.
[1] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/
v2/images.py#L179
[2] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#
L944
__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
@flaper87
Flavio Percoco
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
On 09/12/15 11:33 +, Kekane, Abhishek wrote:
Hi Devs,
We are adding support for returning ?x-openstack-request-id? to the caller as
per the design proposed in cross-project specs:
http://specs.openstack.org/openstack/openstack-specs/specs/
return-request-id.html
Problem Description:
Cannot add a new property of list type to the warlock.model object.
How is a model object created:
Let?s take an example of glanceclient.api.v2.images.get() call [1]:
Here after getting the response we call model() method. This model() does the
job of creating a warlock.model object(essentially a dict) based on the schema
given as argument (image schema retrieved from glance in this case). Inside
model() the raw() method simply return the image schema as JSON object. The
advantage of this warlock.model object over a simple dict is that it validates
any changes to object based on the rules specified in the reference schema.
The keys of this model object are available as object properties to the
caller.
Underlying reason:
The schema for different sub APIs is returned a bit differently. For images,
metadef APIs glance.schema.Schema.raw() is used which returns a schema
containing ?additionalProperties?: {?type?: ?string?}. Whereas for members and
tasks APIs glance.schema.Schema.minimal() is used to return schema object which
does not contain ?additionalProperties?.
So we can add extra properties of any type to the model object returned from
members or tasks API but for images and metadef APIs we can only add properties
which can be of type string. Also for the latter case we depend on the glance
configuration to allow additional properties.
As per our analysis we have come up with two approaches for resolving this
issue:
Approach #1: Inject request_ids property in the warlock model object in glance
client
Here we do the following:
1. Inject the ?request_ids? as additional property into the model object
(returned from model())
2. Return the model object which now contains request_ids property
Limitations:
1. Because the glance schemas for images and metadef only allows additional
properties of type string, so even though natural type of request_ids should be
list we have to make it as a comma separated ?string? of request ids as a
compromise.
2. Lot of extra code is needed to wrap objects returned from the client API so
that the caller can get request ids. For example we need to write wrapper
classes for dict, list, str, tuple, generator.
3. Not a good design as we are adding a property which should actually be a
base property but added as additional property as a compromise.
4. There is a dependency on glance whether to allow custom/additional
properties or not. [2]
Approach #2: Add ?request_ids? property to all schema definitions in glance
Here we add ?request_ids? property as follows to the various APIs (schema):
?request_ids?: {
"type": "array",
"items": {
"type": "string"
}
}
Doing this will make changes in glance client very simple as compared to
approach#1.
This also looks a better design as it will be consistent.
We simply need to modify the request_ids property in various API calls for
example glanceclient.v2.images.get().
Hey Abhishek,
thanks for working on this.
To be honest, I'm a bit confused on why the request_id needs to be an
attribute of the image. Isn't it passed as a header? Does it have to
be an attribute so we can "print" it?
The requirement they're trying to meet is to make the request id
available to the user of the client library [1]. The user typically
doesn't have access to the headers, so the request id needs to be
part of the payload returned from each method. In other clients
Will this work if the payload is image data?
that work with simple data types, they've subclassed dict, list,
etc. to add the extra property. This adds the request id to the
return value without making a breaking change to the API of the
client library.
Abhishek, would it be possible to add the request id information
to the schema data in glance client, before giving it to warlock?
I don't know whether warlock asks for the schema or what form that
data takes (dictionary, JSON blob, etc.). If it's a dictionary
visible to the client code it would be straightforward to add data
to it.
Failing that, is it possible to change warlock to allow extra
properties with arbitrary types to be added to objects? Because
validating inputs to the constructor is all well and good, but
breaking the ability to add data to an object is a bit un-pythonic.
If we end up having to change the schema definitions in the Glance API,
that also means changing those API calls to add the request id to the
return value, right?
Doug
[1]
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
As it is presented in your email, I'd probably go with option #2 but
I'm curious to know
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com]
Sent: 09 December 2015 19:28
To: openstack-dev
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller
Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
> >Hi Devs,
> >
> >
> >
> >We are adding support for returning ‘x-openstack-request-id’ to the
> >caller as per the design proposed in cross-project specs:
> >
> >http://specs.openstack.org/openstack/openstack-specs/specs/
> >return-request-id.html
> >
> >
> >
> >Problem Description:
> >
> >Cannot add a new property of list type to the warlock.model object.
> >
> >
> >
> >How is a model object created:
> >
> >Let’s take an example of glanceclient.api.v2.images.get() call [1]:
> >
> >
> >
> >Here after getting the response we call model() method. This model()
> >does the job of creating a warlock.model object(essentially a dict)
> >based on the schema given as argument (image schema retrieved from
> >glance in this case). Inside
> >model() the raw() method simply return the image schema as JSON
> >object. The advantage of this warlock.model object over a simple dict
> >is that it validates any changes to object based on the rules specified in
> >the reference schema.
> >The keys of this model object are available as object properties to
> >the caller.
> >
> >
> >
> >Underlying reason:
> >
> >The schema for different sub APIs is returned a bit differently. For
> >images, metadef APIs glance.schema.Schema.raw() is used which returns
> >a schema containing “additionalProperties”: {“type”: “string”}.
> >Whereas for members and tasks APIs glance.schema.Schema.minimal() is
> >used to return schema object which does not contain “additionalProperties”.
> >
> >
> >
> >So we can add extra properties of any type to the model object
> >returned from members or tasks API but for images and metadef APIs we
> >can only add properties which can be of type string. Also for the
> >latter case we depend on the glance configuration to allow additional
> >properties.
> >
> >
> >
> >As per our analysis we have come up with two approaches for resolving
> >this
> >issue:
> >
> >
> >
> >Approach #1: Inject request_ids property in the warlock model object
> >in glance client
> >
> >Here we do the following:
> >
> >1. Inject the ‘request_ids’ as additional property into the model
> >object (returned from model())
> >
> >2. Return the model object which now contains request_ids property
> >
> >
> >
> >Limitations:
> >
> >1. Because the glance schemas for images and metadef only allows
> >additional properties of type string, so even though natural type of
> >request_ids should be list we have to make it as a comma separated
> >‘string’ of request ids as a compromise.
> >
> >2. Lot of extra code is needed to wrap objects returned from the
> >client API so that the caller can get request ids. For example we
> >need to write wrapper classes for dict, list, str, tuple, generator.
> >
> >3. Not a good design as we are adding a property which should
> >actually be a base property but added as additional property as a compromise.
> >
> >4. There is a dependency on glance whether to allow custom/additional
> >properties or not. [2]
> >
> >
> >
> >Approach #2: Add ‘request_ids’ property to all schema definitions in
> >glance
> >
> >
> >
> >Here we add ‘request_ids’ property as follows to the various APIs (schema):
> >
> >
> >
> >“request_ids”: {
> >
> > "type": "array",
> >
> > "items": {
> >
> >"type": "string"
> >
> > }
> >
> >}
> >
> >
> >
> >Doing this will make changes in glance client very simple as compared
> >to approach#1.
> >
> >This also looks a better design as it will be consistent.
> >
> >We simply need to modify the request_ids property in various API
> >calls for example glanceclient.v2.images.get().
> >
>
> Hey Abhishek,
>
> thanks for working on this.
>
> To be honest, I'm a bit confused on why the request_id needs to be an
> attribute of the image. Isn't it passed as a header? Does it have to
> be an attribute so we can "print" i
Re: [openstack-dev] [python-glanceclient] Return request-id to caller
-Original Message-
From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com]
Sent: 09 December 2015 23:54
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to caller
> Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
>> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
>>> Hi Devs,
>>>
>>>
>>>
>>> We are adding support for returning ?x-openstack-request-id? to the caller
>>> as
>>> per the design proposed in cross-project specs:
>>>
>>> http://specs.openstack.org/openstack/openstack-specs/specs/
>>> return-request-id.html
>>>
>>>
>>>
>>> Problem Description:
>>>
>>> Cannot add a new property of list type to the warlock.model object.
>>>
>>>
>>>
>>> How is a model object created:
>>>
>>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
>>>
>>>
>>>
>>> Here after getting the response we call model() method. This model() does
>>> the
>>> job of creating a warlock.model object(essentially a dict) based on the
>>> schema
>>> given as argument (image schema retrieved from glance in this case). Inside
>>> model() the raw() method simply return the image schema as JSON object. The
>>> advantage of this warlock.model object over a simple dict is that it
>>> validates
>>> any changes to object based on the rules specified in the reference schema.
>>> The keys of this model object are available as object properties to the
>>> caller.
>>>
>>>
>>>
>>> Underlying reason:
>>>
>>> The schema for different sub APIs is returned a bit differently. For images,
>>> metadef APIs glance.schema.Schema.raw() is used which returns a schema
>>> containing ?additionalProperties?: {?type?: ?string?}. Whereas for members
>>> and
>>> tasks APIs glance.schema.Schema.minimal() is used to return schema object
>>> which
>>> does not contain ?additionalProperties?.
>>>
>>>
>>>
>>> So we can add extra properties of any type to the model object returned from
>>> members or tasks API but for images and metadef APIs we can only add
>>> properties
>>> which can be of type string. Also for the latter case we depend on the
>>> glance
>>> configuration to allow additional properties.
>>>
>>>
>>>
>>> As per our analysis we have come up with two approaches for resolving this
>>> issue:
>>>
>>>
>>>
>>> Approach #1: Inject request_ids property in the warlock model object in
>>> glance
>>> client
>>>
>>> Here we do the following:
>>>
>>> 1. Inject the ?request_ids? as additional property into the model object
>>> (returned from model())
>>>
>>> 2. Return the model object which now contains request_ids property
>>>
>>>
>>>
>>> Limitations:
>>>
>>> 1. Because the glance schemas for images and metadef only allows additional
>>> properties of type string, so even though natural type of request_ids
>>> should be
>>> list we have to make it as a comma separated ?string? of request ids as a
>>> compromise.
>>>
>>> 2. Lot of extra code is needed to wrap objects returned from the client API
>>> so
>>> that the caller can get request ids. For example we need to write wrapper
>>> classes for dict, list, str, tuple, generator.
>>>
>>> 3. Not a good design as we are adding a property which should actually be a
>>> base property but added as additional property as a compromise.
>>>
>>> 4. There is a dependency on glance whether to allow custom/additional
>>> properties or not. [2]
>>>
>>>
>>>
>>> Approach #2: Add ?request_ids? property to all schema definitions in glance
>>>
>>>
>>>
>>> Here we add ?request_ids? property as follows to the various APIs (schema):
>>>
>>>
>>>
>>> ?request_ids?: {
>>>
>>> "type": "array",
>>>
>>> "items": {
>>>
>>>"type": "string"
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> Doing this will make changes in glance client very simple as compared to
>>> approach#1.
>>&g
