こんにちは。このプレゼンテーションは始まります。このプレゼンテーションはノバレストのAPI、ノバV2.1のAPIです。一つの新しいキロリーのフューチャーです。このAPIを作りました。このプレゼンテーションについてお伺いします。このプレゼンテーションのアジェンダーです。まずは、私たちにご紹介します。私の名前はケイチオミチです。2012年からオープンスタックコミュニティを参加しました。今、私はノバとテンペストプロジェクトのコアデブローバーです。私はノバAPIのプレゼンテーションについてお伺いします。このプレゼンテーションについてお伺いします。みなさんこんにちは。私の名前はケンシャマンです。私はNECのソフトウェイドウォーバーです。 2012年からコミュニティを参加しました。私はノバV2.1のAPIのプレゼンテーションについてお伺いします。私はテンペストプロジェクトのコアデブローバーです。まず、RESTAPIのプレゼンテーションについてお伺いします。RESTAPIのプレゼンテーションについてお伺いします。4Cardを作るために、新しいリソースを使うことができます。ポストの方法を使うことができます。RESTAPIのプレゼンテーションについてお伺いします。リソースを読むために、リソースを使うことができます。GATのプレゼンテーションについてお伺いします。リソースのディテールを読むために、T scheduleについてお伺いしました。引す道具、ロでもren to memoriesスペシャルを使うことはできます。リソースの目を覲眼し、キホイ。リソースを使うことはできます。RESTAPIのプレゼンテーションについてお伝えします。みんな読む例は、來了発點的時候がどうやらもではないです。是非仕留めになって、ノア、キーストーン、グランスを使って、彼らのインターフェースや使い方を取り出しています。例えば、ノアで、ユーザーが新しいリソースを作りたいと言います。彼らは、リソースのイメージサーバーを使っています。ユーザーのサーバーを使うと、ユーザーのURIを使っています。キーストーンを使う様に、ハンドポイントを開すると、レストエピアイスとして使っています。グランスをこの中にしてイメージを作るように、ボリュームを作っています。オープンスタックプロジェクトのレストエピアイスやユーザーの使い方を取り出し、エピアイスや公式レストエピアイスを使っています。オープンスタックプロジェクトのレストエピアイスにはブラシのレストエピアイスやREST APIと呼ばれることができますパイトンクラインのコマンスはREST APIと呼ばれることができますキーストーン、ノア、オーガランスなどアプリケーションを使ってREST APIを使うことができますオープンスタックプロジェクトにREST APIを応援することができますノアのV2.1のエピアイスノアを使うことができます2つのREST APIはV2とV2.1のベッドですエピアイスがあってV2.1のエピアイスを使うことができますV2.1のエピアイスとV2.1のエピアイスを使うことができますエピアイスとV2.1のエピアイスは但私から打撃があります。今まであったところ私とのasedプロリオアのですね、出現することを指教でする場合は、之前の飲み場から과に��まれて部分の 막もちょっとそんなどこでもバトルですね、 inaugural 通信のところを先ほどもアップ rotate 部下のチェンジブレードキャット単養で自治満達にApisを通すマイクロヴァーゼンを 説明することを説明します今は非常に短い でも非常に難しい サムリーのV2.1を説明しますV2.1はV2のコンパタビューですV2.1のコンパタビューは V2.1のコンパタビューですV2.1のコンパタビューは V2.1のコンパタビューですV2.1のコンパタビューは V2.1のコンパタビューですV2.1のコンパタビューは V2.1のコンパタビューですV2.1のコンパタビューは V2.1のコンパタビューですV2.1のコンパタビューなので V2.1のコンパタビューについて動画の用意をしていますuzなぜすぐにこの動画を購読しているのかディテールsアズマンサンエクスプレイン2.1エピアイス2.2 コンパチビリティパリデーションマイクロバージョンSo, I'd like to explain each feature since this slide.The first feature is V2 Compatibility.So, V2 has been used since 2011.So, we have already used V2 API for years.There is a lot of SDK using OpenStack API.User can use these SDK for implementing their own applications to operate OpenStack.So, there is a bunch of applications which use V2 API in the world.In this situation, if backward incompatibility change happened on V2,many applications will be broken.So, backward incompatibility is very important for us.アズマンサンエクスプレイン2.1スラッシュV2.1スラッシュV2 is a default endpoint of YPI.In Kilo, V2 is working on this default endpoint.So, incompatibility change does not happen on this default endpoint.So, we can use existing application without any changes on Kilo also.We can switch the endpoint to V2.1 like this.V2.1 works like V2 as a default behavior.So, backward incompatibility change does not happen even if switching endpoint toスラッシュV2.1 as a default behavior.So, we can use existing application without any change on V2.1 API also.So, next feature is validation.We faced a lot of problems on V2 input validation.It was easy that internal error happened if clients sent malformed request.Because V2 API did not have enough validation in many cases.As a result, operating cost was very high.For example, I'd like to pick up some bug here.One of the most popular APIs is create a server API.This API contains parameter metadata.This parameter type should be object type.But if clients send a string value instead of object type, internal error happened.So, error message does not contain any reasons.So, as a result, cloud operator needs to investigate the program and fix these errors.User also cannot understand what is wrong and what should do for fixing this problem.So, to solve this problem, V2.1 API implements input validation framework.On this framework, all parameters should be defined with types and format.Based on this parameter definition, V2.1 API denies malformed requests.So, this behavior is similar to white list access control.On V2.1 API, valid input pattern defined and nobody rejects malformed requests which are against these patterns.So, as a merit of this framework, we can avoid internal error in many cases and error response contains a reason with consistent message format.User can know the reason and fix their own problem easily.So, V2.1 validation can reduce operating cost.So, last feature is micro versions.Micro version is API versioning mechanism.And on this mechanism, micro version are generated for each API changes.So, all API changes will appear as new micro version.V2.1 API contains multiple continuous micro versions.And the first micro version is V2.1.So, there is a small confusion here.V2.1 API contains micro version V2.1 API and V2.1.This micro version is default and V2 compatible.When changing the micro version V2.1, V2.2 is generated.So, V2.2 is V2.1 plus some changes.Based on the same manner, V2.3 is V2.2 plus some changes like that.And the application can specify micro version in request header.In this slide, application specify V2.2 here.So, Novatex V2.2 action.So, important thing is that the end point is same between micro version.So, even if specify V2.2, end point is still V2.1.So, we don't need to switch the end point between micro versions.Instead, we need to specify micro version in request header.Current V2.2 contains interface bar like var long status code,inconsistent URIs and so on.But it was very difficult to fix them because of backward incompatibility.Micro version mechanism allows us to fix them.Backward incompatible change should happen with new micro version.And the default micro version is V2.1.So, the existing application does not specify a micro version.So, Novatex V2.compatible action for existing applications.In addition, we will fix them with small changes to avoid a single big impact to user.Micro version mechanism will make Novatex API more consistent and beautiful.In Kilo, three micro version implemented.The first micro version is V2.1.This micro version is default and V2.compatible API.And the input validation has been implemented since this micro version.Based on V2.1, V2.2 is implemented.On this micro version, new parameter is added to KPI response.And some invalid status code of KPI API are fixed.The status code of KPI are changed like this.200, 2201, 202, 204.So, these changes are backward incompatible change.But we have decided these changes because KPI operation is synchronous.So, 201 created and 204 no content more accurate.We have API working group for building consistent API design for all OpenStack projects.And these changes are based on API working group guideline.Last micro version of Kilo is V2.3.New parameter added to show server API for standalone EC2 API service.On Liberty also, we have many group prints which require API changes.So, the number of micro version will continue increasing.The micro version history is described, this file, sorry, too long.So, this file will help for catching micro version history.The main feature of V2.1 mentioned.So, here is how to use V2.1 API.Here, I'd like to show the outline of usage of this diagram.As I said on previous slide, the default endpoint is V2, not V2.1.So, to use V2.1, we need to switch the endpoint from default to V2.1.To use micro version, we need to switch the endpoint as same as previouslybecause micro version is implemented on V2.1 API.In addition, we need to specify a micro version in request header like this.So, as the first, we need to know the cloud support V2.1and the supported micro versions.Nova version list command works for that.If the command output includes ID V2.1and its status is current like that, the cloud support V2.1.And the supported micro version is described on here,minimum version and this version.This version means micro version.So, on this sample, this cloud supports micro version V2.1, V2.2 and V2.3.One note is that this Nova version list command was broken recentlyand the problem is fixed on the latest Nova Python client,which released last week.So, please use it.Please use the latest Python Nova client for it.After knowing the cloud support V2.1 API,we need to switch endpoint to V2.1.If using Nova command, please try addingserver type compute V2.1 to Nova command.On this sample, the back option is added also.So, this debug option is useful for checking V2.1 works on Nova side.On this sample, base URI is switched to V2.1.And here is the response.And this response contains micro version header here.So, on this sample, micro version does not specify.So, on Nova side, the micro version V2.1 default works.So, on Nova command, there is no way to specify a micro versionthat is working progress now.So, I hope this feature will be implemented soon.For application and SDKs, micro version can be specifiedthis header.And here is the micro version.If not specifying a micro version,Nova takes V2-compatible action, as I said.And if specify a special key, rightest,Nova takes Makishima micro version, micro version action,this keyword is useful for development in most cases.And it is better to avoid specify this keywordon production environment.Because sometime micro version containsbackward incompatible changes.And if upgrading cloud environment,the latest micro version also is increased.And sometime micro version containsbackward incompatible changes.So, if application does not care about that,application will be broken.So, my recommendation is specify a certain micro versioninstead of the keyword, rightest,and increasing specified micro versionafter checking micro version history.Now, there is some going development items.Here shows two main items.The first item is switching to default endpointto V2.1.The default endpoint slash V2 will be switchedto V2.1 in liberty like this.So, after liberty,application can still workwithout any changes because V2 compatibility.And V2.1 validation works as a default.Application can specify micro versionwithout switching the endpoint.In long term,we will remove this V2implementation code to reducementence cost in the community.I cannot say when it's happened at this time.Second item is to relax V2 input validation.V2.1 validation works based onthe parameter definition.And if application contains a bugwhich passed and definedparameter in request.In this case, V2 just ignore it anduse the available parameter values.But V2.1 denies such requestand return error response instead.We guess some application containsthis kind of problem in the real worldbecause Tempest also did it.V2.1 validation possibly breakssome applications which containthis kind of problem.That is validation issue around V2.1.Now,there is a proposal to relaxthe validation from John Garbert,nova PTR.And on this proposal,if clientdoes not specify a micro version,nobody does not deny a requesteven if the request containsundefined parameters.If specifying a micro version,nobody denies such request.So,the validation againstundefined parameter does notreplace for existing application.I think this idea is very niceand we are going to implement itin Liberty cycle.So,after Liberty,V2.1API will be more easier to beused on production environment.Here is a summary of this presentation.So,V2.1API isV2 Compatibility,Vidation andMicro versions.With V2.1,with V2 Compatibility,we can use existing applicationwithout any changes.With Vidation,we canavoid internal error in many casesand we can reduce operating cost.With micro version mechanism,new future has beenimplemented on V2.1 only.After Liberty,V2.1APIwill be more easier to be used.We will continue workingfor making V2.1APIbetter in Liberty.At the end of this presentation,I would like to mention aboutChris Yeo.As is so onJonathan Brice Keynote today,the key release isdedicated to memory of Chris.Two months ago,Chrispassed our way from us.He was the leader ofNova API development in communityand he designed andimplemented a lot ofV2.1API codeand mentored tomany new developer including me.The first time I met him wasHong Kong summit.This picture is thatI started working forNova validation developmentat the time.But I was worried abouthow to make the developmentproceed.He gave me important adviceat the summitand we could go overthe concern andthe validation frameworkis integrated intoV2.1 now.He was a very kind guyand he helpedmany people even afterhis thing.My hope was this presentationwas done with him togetherand I could not imaginewe need to use this picture like this.So new future will makeNova API consistentand beautifulas he hoped.So making better APIis one thing we can do forhis speed.We'd like to continuethis thing in Liberty also.I'm glad if many people startusingV2.1API soonto moving forward together.That is all frommy presentation.Thank you for coming today.We have two minutesaround left.So if you have any question.Okay.So you meanhaving the validation on the clientside itself first.Okay.So we do havethe schema present in the Nova trees.So client can use those schemas for their validation.And the part is likewe are going to have one more which is likeJsonHome which provides you the linkto the json schema forprospending APIs.So client can use thatand have the validation on their side itself.So maybe in Liberty,which is onJsonHome.So maybe in Liberty,it will be released.Another question.We have any data ofhaving the performance with validation.We don't have right now actuallybut that's a good idea we can have.But we don't think there will be moredifference between the performancebecause the validation in V2has to happen in the python code many timesexcept the extra attribute being validatedin the json schema and all.And we have movedthe python code validation into the json schema validation.So which I think should be the faster.But we can have the search data of performance.I was askingof course.Okay.So till now actually we have not donesuch a validation.But we can tryand have those for the uses.That will be good.Yeah.V2.1.Yes.Yeah.So both jobs time is almost same.So don't think any huge difference.Yeah.We can have last one.I just had a question about theKeyla release.So you've got V2.1,V2.2 and V2.3.I'm trying to understand the V2.2because 2.3 presumably containsthe changes in 2.2.I'm just wondering if we have libertyor we're going to have like 4,5.So basically what all we introduce in V2.2and 2.3.You mean what all we introducethe changes between V2.1and V2.2.How many microversions per 1.2?Yeah.It depends on how many changeswe introduce.So if you ask there could bepublished,could be consumed by somebody.So next thing is an instrument.So each one you get its ownmicro words.And we'll be back withnot really what I said.So yeah.Sorry.I mean if you request2.2and we change somethingin 2.3different.We will honor the 2.2 behaviorthat didn't work.It exposes a minimum supported one.Right now it's 2.0or 1.2.Not necessarily.But I'm saying until that happenswe'll honorall those people.Okay.I think we have done ittime.Thank you everyone.