[openstack-dev] [Nova] Review request for bp cancel-swap-volume and idempotency-client-token
Hi everyone. We registered two individual blue print. One is simple, swap-volume feature should be provide cancelling functionality. Another is a bit complicated, OpenStack API should be support API idempotency. - Cancelling a swap volume https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume - Idempotency for OpenStack API https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token Please check and review these. Best Regards, /** Takahiro Shida Cheif Consultant NTTDATA INTELLILINK Phone: +81 3 5843 6880 Mail: sh...@intellilink.co.jp */ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Review request
Hi all! I have a patch up for allowing Nova to talk to Glance via either the V1 or V2 API. This is currently blocked by the feature freeze, but if some folks could look at it so I can have it ready to roll when the freeze ends I'd really appreciate it! https://review.openstack.org/#/c/46507/ Thanks, Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] review request
Hi all, I'd appreciate if any of the nova-core reviewers could take a look at https://review.openstack.org/#/c/39226/, as this add keypair notification events. which is more like a small feature than a bug, I am callling review just in case after feature freeze it can't be accepted. -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] review request for bp improve-block-device-handling
Hi folks, I'd greatly appreciate if we could get the remaining two patches reviewed and hopefully merged for the upcoming freeze this Wednesday. Both patches have been up for a long time and have seen a number of revisions and several +2 already. The patches in question are: https://review.openstack.org/#/c/40229/ https://review.openstack.org/#/c/42474/ If you feel there are some major issues with them - of course - please do bring them up, but in case the issues are smaller, I'd be more than happy to raise individual bugs and take car of them as soon as humanly possible, so that the patches will land for H-3. Many thanks in advance, Kind regards, Nikola ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] review request for second core to look at https://review.openstack.org/#/c/41522/
This has a +2 on it: https://review.openstack.org/#/c/41522/ And it's holding up a patch that has two +2s: https://review.openstack.org/#/c/41543/ Which is part of a blueprint topic branch, so blocking the blueprint also. So I'd appreciate if I could get a second core reviewer to look at 41522 to move things along. Thanks, MATT RIEDEMANN Advisory Software Engineer Cloud Solutions and OpenStack Development Phone: 1-507-253-7622 | Mobile: 1-507-990-1889 E-mail: mrie...@us.ibm.com 3605 Hwy 52 N Rochester, MN 55901-1407 United States <>___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
Hi Russell, Doug, Thanks for your comments, I'm really glad to talk about this with you. > -Original Message- > From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] > Sent: Saturday, August 03, 2013 6:14 AM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Nova] Review request: Blurprint of API > validation > > > > > On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant wrote: > > > On 07/09/2013 07:45 AM, Ken'ichi Ohmichi wrote: > > > > Hi, > > > > The blueprint "nova-api-validation-fw" has not been approved yet. > > I hope the core patch of this blueprint is merged to Havana-2, > > because of completing comprehensive API validation of Nova v3 API > > for Havana release. What should we do for it? > > > I apologize for taking so long to address this. > > Here is my current take on this based on reviewing discussions, code, > and talking to others about it. > > From a high level, API input validation is obviously a good thing. > Having a common framework to do it is better. What complicates this > submission is the effort to standardize on Pecan/WSME for APIs > throughout OpenStack. > > We've discussed WSME and jsonschema on the mailing list. There are > perhaps some things that can be expressed using jsonschema, but not WSME > today. So, there are some notes on > https://etherpad.openstack.org/NovaApiValidationFramework showing how > the two could be used together at some point. However, I don't think > it's really desirable long term. It seems a bit awkward, and some > information gets duplicated. > > We had previously established that using WSME was the long term goal > here. Going forward with jsonschema with the current nova APIs is a > benefit in the short term, but I do not think it's necessarily in > support of the long term goal if there isn't consensus that combining > WSME+jsonschema is a good idea. > > This sort of thing affects a lot of code, so the direction is important. >I do not think we should proceed with this. It seems like the best > thing to do that helps the long term goal is to work on migrating our > API to WSME. In particular, I think we could do this for the v3 API, > since it's not going to be locked down until Icehouse. At the same > time, we should contribute back to WSME to add the features we feel are > missing to allow the types of validation we would like to do. > > If there is significant disagreement with this decision, I'm happy to > continue talking about it. However, I really want to see consensus on > this and how it fits in with the long term goals before moving forward. > > > > When we discussed this earlier, there was concern about moving to a > completely new toolset for the new API in Havana because of other > changes going on at the same time (something to do with extensions, IIRC). > I agreed it made sense to stick with our current tools to avoid adding > risk to the schedule. If that schedule has slipped into the next release, > or if you feel there is time after all, then I would also prefer to go > ahead with the general consensus reached at the Havana summit and use WSME. > > Given a little time, I think we can come up with something better than the > method of combining WSME and jsonschema proposed in the etherpad linked > above, which effectively requires us to declare the types of the parameters > twice in different formats. As Russell said, if we need to add to WSME to > make it easier to use, we should do that. That's a good point. The sample code on the etherpad[1] requires to define API schema twice for single API, and that would be workload against implementing API schema when Pecan/WSME has been used. So how about adding jsonschema support to WSME? If doing that, we will be able to use good validation based on jsonschema only by defining a single API schema. > I am working on getting WSME onto stackforge, to make contributions easier > (it's on bitbucket now, but using hg and pull requests is pretty different > from our normal review process and may add friction for some people). That would be good info, if the above idea gets consensus. I will start investigating how to implement jsonschema support for WSME after this discussion, and try contributing the above stackforge WSME. > We ran into a few tricky spots because of the wide variety of test configu- > rations in play, and that caused some delays. I think those issues are > worked
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
On Sat, Aug 3, 2013 at 9:16 AM, Doug Hellmann mailto:doug.hellm...@dreamhost.com";>> wrote: On Fri, Aug 2, 2013 at 5:19 PM, Russell Bryant wrote: On 08/02/2013 05:13 PM, Doug Hellmann wrote: > When we discussed this earlier, there was concern about moving to a > completely new toolset for the new API in Havana because of other > changes going on at the same time (something to do with extensions, > IIRC). I agreed it made sense to stick with our current tools to avoid > adding risk to the schedule. If that schedule has slipped into the next > release, or if you feel there is time after all, then I would also > prefer to go ahead with the general consensus reached at the Havana > summit and use WSME. The Nova v3 API schedule has slipped. A huge amount of progress has been made, but it's going to be marked experimental in Havana. We're going to wrap it up for Icehouse. So, there's another release cycle available to work on the v3 API infrastructure. Sounds good. I think the critical bit will be if we can move to wsme with minimal to no changes to the code for the extensions. Or at least a way that it can be done in-place easily without breaking everything. Eg some transition phase where wsme can support the wsgi api temporarily. Otherwise we're in for either a giant patch which will be hard to merge or a similar rather painful process to what we've had to do for the extension framework changes in Havana. Chris___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
On Fri, Aug 2, 2013 at 5:19 PM, Russell Bryant wrote: > On 08/02/2013 05:13 PM, Doug Hellmann wrote: > > When we discussed this earlier, there was concern about moving to a > > completely new toolset for the new API in Havana because of other > > changes going on at the same time (something to do with extensions, > > IIRC). I agreed it made sense to stick with our current tools to avoid > > adding risk to the schedule. If that schedule has slipped into the next > > release, or if you feel there is time after all, then I would also > > prefer to go ahead with the general consensus reached at the Havana > > summit and use WSME. > > The Nova v3 API schedule has slipped. A huge amount of progress has > been made, but it's going to be marked experimental in Havana. We're > going to wrap it up for Icehouse. So, there's another release cycle > available to work on the v3 API infrastructure. > Sounds good. Doug > > -- > Russell Bryant > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
On 08/02/2013 05:13 PM, Doug Hellmann wrote: > When we discussed this earlier, there was concern about moving to a > completely new toolset for the new API in Havana because of other > changes going on at the same time (something to do with extensions, > IIRC). I agreed it made sense to stick with our current tools to avoid > adding risk to the schedule. If that schedule has slipped into the next > release, or if you feel there is time after all, then I would also > prefer to go ahead with the general consensus reached at the Havana > summit and use WSME. The Nova v3 API schedule has slipped. A huge amount of progress has been made, but it's going to be marked experimental in Havana. We're going to wrap it up for Icehouse. So, there's another release cycle available to work on the v3 API infrastructure. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant wrote: > On 07/09/2013 07:45 AM, Ken'ichi Ohmichi wrote: > > > > Hi, > > > > The blueprint "nova-api-validation-fw" has not been approved yet. > > I hope the core patch of this blueprint is merged to Havana-2, > > because of completing comprehensive API validation of Nova v3 API > > for Havana release. What should we do for it? > > I apologize for taking so long to address this. > > Here is my current take on this based on reviewing discussions, code, > and talking to others about it. > > From a high level, API input validation is obviously a good thing. > Having a common framework to do it is better. What complicates this > submission is the effort to standardize on Pecan/WSME for APIs > throughout OpenStack. > > We've discussed WSME and jsonschema on the mailing list. There are > perhaps some things that can be expressed using jsonschema, but not WSME > today. So, there are some notes on > https://etherpad.openstack.org/NovaApiValidationFramework showing how > the two could be used together at some point. However, I don't think > it's really desirable long term. It seems a bit awkward, and some > information gets duplicated. > > We had previously established that using WSME was the long term goal > here. Going forward with jsonschema with the current nova APIs is a > benefit in the short term, but I do not think it's necessarily in > support of the long term goal if there isn't consensus that combining > WSME+jsonschema is a good idea. > > This sort of thing affects a lot of code, so the direction is important. > I do not think we should proceed with this. It seems like the best > thing to do that helps the long term goal is to work on migrating our > API to WSME. In particular, I think we could do this for the v3 API, > since it's not going to be locked down until Icehouse. At the same > time, we should contribute back to WSME to add the features we feel are > missing to allow the types of validation we would like to do. > > If there is significant disagreement with this decision, I'm happy to > continue talking about it. However, I really want to see consensus on > this and how it fits in with the long term goals before moving forward. > When we discussed this earlier, there was concern about moving to a completely new toolset for the new API in Havana because of other changes going on at the same time (something to do with extensions, IIRC). I agreed it made sense to stick with our current tools to avoid adding risk to the schedule. If that schedule has slipped into the next release, or if you feel there is time after all, then I would also prefer to go ahead with the general consensus reached at the Havana summit and use WSME. Given a little time, I think we can come up with something better than the method of combining WSME and jsonschema proposed in the etherpad linked above, which effectively requires us to declare the types of the parameters twice in different formats. As Russell said, if we need to add to WSME to make it easier to use, we should do that. I am working on getting WSME onto stackforge, to make contributions easier (it's on bitbucket now, but using hg and pull requests is pretty different from our normal review process and may add friction for some people). We ran into a few tricky spots because of the wide variety of test configurations in play, and that caused some delays. I think those issues are worked out (especially with the Python 3.3 build systems available now), so I will be picking that work up in a week or two (I'm traveling next week). Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
On 07/09/2013 07:45 AM, Ken'ichi Ohmichi wrote: > > Hi, > > The blueprint "nova-api-validation-fw" has not been approved yet. > I hope the core patch of this blueprint is merged to Havana-2, > because of completing comprehensive API validation of Nova v3 API > for Havana release. What should we do for it? I apologize for taking so long to address this. Here is my current take on this based on reviewing discussions, code, and talking to others about it. >From a high level, API input validation is obviously a good thing. Having a common framework to do it is better. What complicates this submission is the effort to standardize on Pecan/WSME for APIs throughout OpenStack. We've discussed WSME and jsonschema on the mailing list. There are perhaps some things that can be expressed using jsonschema, but not WSME today. So, there are some notes on https://etherpad.openstack.org/NovaApiValidationFramework showing how the two could be used together at some point. However, I don't think it's really desirable long term. It seems a bit awkward, and some information gets duplicated. We had previously established that using WSME was the long term goal here. Going forward with jsonschema with the current nova APIs is a benefit in the short term, but I do not think it's necessarily in support of the long term goal if there isn't consensus that combining WSME+jsonschema is a good idea. This sort of thing affects a lot of code, so the direction is important. I do not think we should proceed with this. It seems like the best thing to do that helps the long term goal is to work on migrating our API to WSME. In particular, I think we could do this for the v3 API, since it's not going to be locked down until Icehouse. At the same time, we should contribute back to WSME to add the features we feel are missing to allow the types of validation we would like to do. If there is significant disagreement with this decision, I'm happy to continue talking about it. However, I really want to see consensus on this and how it fits in with the long term goals before moving forward. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
Hi Russell,
I have assigned you as the approver of bp "nova-api-validation-fw",
please approve it or give some comments.
https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw
The implementation of core part is almost complete.
now waiting for blueprint approval.
https://review.openstack.org/#/c/25358/
Thanks,
Ken'ichi Ohmichi
---
On Tue, 16 Jul 2013 13:37:15 +0900
"Ken'ichi Ohmichi" wrote:
>
> Hi Russell,
>
> I assigned you as the approver of bp "nova-api-validation-fw",
> so could you take a look at this bp?
>
> You have changed the priority from Medium to Low these days.
> Could you show your concerns about this bp if you have.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> On Tue, 9 Jul 2013 20:45:57 +0900
> "Ken'ichi Ohmichi" wrote:
> >
> > Hi,
> >
> > The blueprint "nova-api-validation-fw" has not been approved yet.
> > I hope the core patch of this blueprint is merged to Havana-2,
> > because of completing comprehensive API validation of Nova v3 API
> > for Havana release. What should we do for it?
> >
> >
> > The summary of "nova-api-validation-fw":
> > * The patch review is in good progress.
> > * "nova-api-validation-fw" is API input validation framework.
> > * Simplify the code in the extensions of Nova v3 API.
> > * Define API schema with JSON Schema.
> > * Define common data formats to standardize whole of Nova v3 API.
> > * Possible to choose APIs which are applied with this framework.
> > * Possible to migrate other web framework.
> >
> >
> > The details of "nova-api-validation-fw" are the following:
> >
> > * The patch review is in good progress.
> > 7 reviewers have marked +1 now.
> > We are waiting for the approval of this blueprint before merging the
> > patch. (https://review.openstack.org/#/c/25358/)
> >
> > * "nova-api-validation-fw" is API input validation framework.
> > This framework validates API parameters in a request body before the
> > execution of API method. If the parameter is invalid, nova-api returns
> > a BadRequest response including its reason.
> >
> > * Simplify the code in the extensions of Nova v3 API.
> > There are a lot of validation code in each API method.
> > After applying this framework, we will be able to separate them from
> > API methods by defining API schema. That makes the code more readable.
> > Also through trying to define API schema of each API, we will find the
> > lacks of validation code and complement them for better v3 API.
> > Necessary API schemas are for API which contains a request body. They
> > are 37 APIs on Nova v3 API now, and they will increase later because
> > the tasks, which port v2 API to v3 API, is in progress.
> >
> > * Define API schema with JSON Schema.
> > JSON Schema contains many features for validation, the details are
> > written on http://json-schema.org/.
> > Here is the schema of v3 keypairs API as a sample:
> > == Request body sample of keypairs API ===
> > {
> > "keypair": {
> > "name": "keypair-dab428fe-6186-4a14-b3de-92131f76cd39",
> > "public_key": "ssh-rsa B3NzaC1yc2EA[..]== Generated by Nova"
> > }
> > == API schema of keypairs API
> > {
> > 'type': 'object',
> > 'properties': {
> > 'keypair': {
> > 'type': 'object',
> > 'properties': {
> > 'name': {'type': 'string', 'minLength': 1, 'maxLength':
> > 255},
> > 'public_key': {'type': 'string'},
> > },
> > 'required': ['name'],
> > },
> > },
> > 'required': ['keypair'],
> > }
> >
> > * Define common data formats to standardize whole of Nova v3 API.
> > We can define common data formats with FormatChecker of JSON Schema
> > library.
> >
> > e.g. Data format of 'boolean':
> > @jsonschema.FormatChecker.cls_checks('boolean')
> > def validate_boolean_format(instance):
> > return instance.upper() == 'TRUE' or instance.upper() == 'FALSE'
> >
> > The formats can be used in API schema:
> > 'onSharedStorage': {
> > 'type': 'string', 'format': 'boolean',
> > },
> >
> > By re-using these common formats in many API schemas, that will be
> > able to standardize whole of Nova v3 API.
> >
> > * Possible to choose APIs which are applied with this framework.
> > We can apply this framework to Nova v3 API only, the existing API (v2) can
> > be out of scope of this framework.
> >
> > * Possible to migrate other web framework.
> > The API validation of this framework is executed with the decorator of API
> > method, that means this framework does not depend on web framework.
> > Also when migrating other web framework(e.g. Pecan/WSME) in the future, we
> > will be able to use this framework.
> >
> >
> > Thanks
> > Ken'ichi Ohmichi
> >
> > ---
> > On Fri, 5 Jul 2013 16:27:39 +0900
> > "Ken'ichi Ohmichi" wrote:
> > >
> > > Hi,
> >
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
Hi Russell,
I assigned you as the approver of bp "nova-api-validation-fw",
so could you take a look at this bp?
You have changed the priority from Medium to Low these days.
Could you show your concerns about this bp if you have.
Thanks
Ken'ichi Ohmichi
---
On Tue, 9 Jul 2013 20:45:57 +0900
"Ken'ichi Ohmichi" wrote:
>
> Hi,
>
> The blueprint "nova-api-validation-fw" has not been approved yet.
> I hope the core patch of this blueprint is merged to Havana-2,
> because of completing comprehensive API validation of Nova v3 API
> for Havana release. What should we do for it?
>
>
> The summary of "nova-api-validation-fw":
> * The patch review is in good progress.
> * "nova-api-validation-fw" is API input validation framework.
> * Simplify the code in the extensions of Nova v3 API.
> * Define API schema with JSON Schema.
> * Define common data formats to standardize whole of Nova v3 API.
> * Possible to choose APIs which are applied with this framework.
> * Possible to migrate other web framework.
>
>
> The details of "nova-api-validation-fw" are the following:
>
> * The patch review is in good progress.
> 7 reviewers have marked +1 now.
> We are waiting for the approval of this blueprint before merging the
> patch. (https://review.openstack.org/#/c/25358/)
>
> * "nova-api-validation-fw" is API input validation framework.
> This framework validates API parameters in a request body before the
> execution of API method. If the parameter is invalid, nova-api returns
> a BadRequest response including its reason.
>
> * Simplify the code in the extensions of Nova v3 API.
> There are a lot of validation code in each API method.
> After applying this framework, we will be able to separate them from
> API methods by defining API schema. That makes the code more readable.
> Also through trying to define API schema of each API, we will find the
> lacks of validation code and complement them for better v3 API.
> Necessary API schemas are for API which contains a request body. They
> are 37 APIs on Nova v3 API now, and they will increase later because
> the tasks, which port v2 API to v3 API, is in progress.
>
> * Define API schema with JSON Schema.
> JSON Schema contains many features for validation, the details are
> written on http://json-schema.org/.
> Here is the schema of v3 keypairs API as a sample:
> == Request body sample of keypairs API ===
> {
> "keypair": {
> "name": "keypair-dab428fe-6186-4a14-b3de-92131f76cd39",
> "public_key": "ssh-rsa B3NzaC1yc2EA[..]== Generated by Nova"
> }
> == API schema of keypairs API
> {
> 'type': 'object',
> 'properties': {
> 'keypair': {
> 'type': 'object',
> 'properties': {
> 'name': {'type': 'string', 'minLength': 1, 'maxLength':
> 255},
> 'public_key': {'type': 'string'},
> },
> 'required': ['name'],
> },
> },
> 'required': ['keypair'],
> }
>
> * Define common data formats to standardize whole of Nova v3 API.
> We can define common data formats with FormatChecker of JSON Schema
> library.
>
> e.g. Data format of 'boolean':
> @jsonschema.FormatChecker.cls_checks('boolean')
> def validate_boolean_format(instance):
> return instance.upper() == 'TRUE' or instance.upper() == 'FALSE'
>
> The formats can be used in API schema:
> 'onSharedStorage': {
> 'type': 'string', 'format': 'boolean',
> },
>
> By re-using these common formats in many API schemas, that will be
> able to standardize whole of Nova v3 API.
>
> * Possible to choose APIs which are applied with this framework.
> We can apply this framework to Nova v3 API only, the existing API (v2) can
> be out of scope of this framework.
>
> * Possible to migrate other web framework.
> The API validation of this framework is executed with the decorator of API
> method, that means this framework does not depend on web framework.
> Also when migrating other web framework(e.g. Pecan/WSME) in the future, we
> will be able to use this framework.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> On Fri, 5 Jul 2013 16:27:39 +0900
> "Ken'ichi Ohmichi" wrote:
> >
> > Hi,
> >
> > I have submitted a blueprint[1] and a patch[2] for Nova API validation.
> > I request someone to review the blueprint and hopefully approve it.
> >
> > This blueprint was approved once, but the Definition has been changed to
> > Discussion because we discussed what is better validation mechanism "WSME
> > original validation or JSON Schema". IIUC, we have found the advantages
> > of JSON Schema through the discussion. [3]
> >
> > Also we have found the way to overlap JSON Schema with WSME, so we will
> > be able to use JSON Schema also when the web framework of Nova is changed
> > to WSME. [4]
> >
> > My latest patch has been implemented wit
Re: [openstack-dev] [Nova] Review request: Blurprint of API validation
Hi,
The blueprint "nova-api-validation-fw" has not been approved yet.
I hope the core patch of this blueprint is merged to Havana-2,
because of completing comprehensive API validation of Nova v3 API
for Havana release. What should we do for it?
The summary of "nova-api-validation-fw":
* The patch review is in good progress.
* "nova-api-validation-fw" is API input validation framework.
* Simplify the code in the extensions of Nova v3 API.
* Define API schema with JSON Schema.
* Define common data formats to standardize whole of Nova v3 API.
* Possible to choose APIs which are applied with this framework.
* Possible to migrate other web framework.
The details of "nova-api-validation-fw" are the following:
* The patch review is in good progress.
7 reviewers have marked +1 now.
We are waiting for the approval of this blueprint before merging the
patch. (https://review.openstack.org/#/c/25358/)
* "nova-api-validation-fw" is API input validation framework.
This framework validates API parameters in a request body before the
execution of API method. If the parameter is invalid, nova-api returns
a BadRequest response including its reason.
* Simplify the code in the extensions of Nova v3 API.
There are a lot of validation code in each API method.
After applying this framework, we will be able to separate them from
API methods by defining API schema. That makes the code more readable.
Also through trying to define API schema of each API, we will find the
lacks of validation code and complement them for better v3 API.
Necessary API schemas are for API which contains a request body. They
are 37 APIs on Nova v3 API now, and they will increase later because
the tasks, which port v2 API to v3 API, is in progress.
* Define API schema with JSON Schema.
JSON Schema contains many features for validation, the details are
written on http://json-schema.org/.
Here is the schema of v3 keypairs API as a sample:
== Request body sample of keypairs API ===
{
"keypair": {
"name": "keypair-dab428fe-6186-4a14-b3de-92131f76cd39",
"public_key": "ssh-rsa B3NzaC1yc2EA[..]== Generated by Nova"
}
== API schema of keypairs API
{
'type': 'object',
'properties': {
'keypair': {
'type': 'object',
'properties': {
'name': {'type': 'string', 'minLength': 1, 'maxLength': 255},
'public_key': {'type': 'string'},
},
'required': ['name'],
},
},
'required': ['keypair'],
}
* Define common data formats to standardize whole of Nova v3 API.
We can define common data formats with FormatChecker of JSON Schema
library.
e.g. Data format of 'boolean':
@jsonschema.FormatChecker.cls_checks('boolean')
def validate_boolean_format(instance):
return instance.upper() == 'TRUE' or instance.upper() == 'FALSE'
The formats can be used in API schema:
'onSharedStorage': {
'type': 'string', 'format': 'boolean',
},
By re-using these common formats in many API schemas, that will be
able to standardize whole of Nova v3 API.
* Possible to choose APIs which are applied with this framework.
We can apply this framework to Nova v3 API only, the existing API (v2) can
be out of scope of this framework.
* Possible to migrate other web framework.
The API validation of this framework is executed with the decorator of API
method, that means this framework does not depend on web framework.
Also when migrating other web framework(e.g. Pecan/WSME) in the future, we
will be able to use this framework.
Thanks
Ken'ichi Ohmichi
---
On Fri, 5 Jul 2013 16:27:39 +0900
"Ken'ichi Ohmichi" wrote:
>
> Hi,
>
> I have submitted a blueprint[1] and a patch[2] for Nova API validation.
> I request someone to review the blueprint and hopefully approve it.
>
> This blueprint was approved once, but the Definition has been changed to
> Discussion because we discussed what is better validation mechanism "WSME
> original validation or JSON Schema". IIUC, we have found the advantages
> of JSON Schema through the discussion. [3]
>
> Also we have found the way to overlap JSON Schema with WSME, so we will
> be able to use JSON Schema also when the web framework of Nova is changed
> to WSME. [4]
>
> My latest patch has been implemented with JSON Schema[2], and I think API
> validation with JSON Schema is useful for Nova v3 API, because the API has
> complex API parameters and JSON Schema can check complex parameters
> naturally.
>
>
> Any comments are welcome :-)
>
> [1]:
> https://blueprints.launchpad.net/openstack/?searchtext=nova-api-validation-fw
> [2]: https://review.openstack.org/#/c/25358/
> [3]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html
> - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009926.html
> - http://lists.openstack.org/
[openstack-dev] [Nova] Review request: Blurprint of API validation
Hi, I have submitted a blueprint[1] and a patch[2] for Nova API validation. I request someone to review the blueprint and hopefully approve it. This blueprint was approved once, but the Definition has been changed to Discussion because we discussed what is better validation mechanism "WSME original validation or JSON Schema". IIUC, we have found the advantages of JSON Schema through the discussion. [3] Also we have found the way to overlap JSON Schema with WSME, so we will be able to use JSON Schema also when the web framework of Nova is changed to WSME. [4] My latest patch has been implemented with JSON Schema[2], and I think API validation with JSON Schema is useful for Nova v3 API, because the API has complex API parameters and JSON Schema can check complex parameters naturally. Any comments are welcome :-) [1]: https://blueprints.launchpad.net/openstack/?searchtext=nova-api-validation-fw [2]: https://review.openstack.org/#/c/25358/ [3]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009926.html - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009937.html - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009970.html - http://lists.openstack.org/pipermail/openstack-dev/2013-June/010057.html [4]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010814.html Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
