On 02/25/2014 08:17 AM, Ken'ichi Ohmichi wrote: > 2014-02-25 19:48 GMT+09:00 Thierry Carrez <thie...@openstack.org>: >> Sean Dague wrote: >>> So, that begs a new approach. Because I think at this point even if we >>> did put out Nova v3, there can never be a v4. It's too much, too big, >>> and doesn't fit in the incremental nature of the project. So whatever >>> gets decided about v3, the thing that's important to me is a sane way to >>> be able to add backwards compatible changes (which we actually don't >>> have today, and I don't think any other service in OpenStack does >>> either), as well a mechanism for deprecating parts of the API. With some >>> future decision about whether removing them makes sense. >> >> I agree with Sean. Whatever solution we pick, we need to make sure it's >> solid enough that it can handle further evolutions of the Nova API >> without repeating this dilemma tomorrow. V2 or V3, we would stick to it >> for the foreseeable future. >> >> Between the cleanup of the API, the drop of XML support, and including a >> sane mechanism for supporting further changes without major bumps of the >> API, we may have enough to technically justify v3 at this point. However >> from a user standpoint, given the surface of the API, it can't be >> deprecated fast -- so this ideal solution only works in a world with >> infinite maintenance resources. >> >> Keeping V2 forever is more like a trade-off, taking into account the >> available maintenance resources and the reality of Nova's API huge >> surface. It's less satisfying technically, especially if you're deeply >> aware of the API incoherent bits, and the prospect of living with some >> of this incoherence forever is not really appealing. > > What is the maintenance cost for keeping both APIs? > I think Chris and his team have already paid most part of it, the > works for porting > the existing v2 APIs to v3 APIs is almost done. > So I'd like to clarify the maintenance cost we are discussing. > > If the cost means that we should implement both API methods when creating a > new API, how about implementing internal proxy from v2 to v3 API? > When creating a new API, it is enough to implement API method for v3 API. and > when receiving a v2 request, Nova translates it to v3 API. > The request styles(url, body) of v2 and v3 are different and this idea makes > new > v2 APIs v3 style. but now v2 API has already a lot of inconsistencies. > so it does not seem so big problem. > > > From the viewpoint of OpenStack interoperability also, I believe we > need a new API. > Many v2 API parameters are not validated. If implementing strict > validation for v2 API, > incompatibility issues happen. That is why we are implementing input > validation for > v3 API. If staying v2 API forever, we should have this kind of problem > forever. > v2 API is fragile now. So the interoperability should depend on v2 > API, that seems > sandbox.. (I know that it is a little overstatement, but we have found > a lot of this kind > of problem already..)
So I think this remains a good question about what keeping v2 forever means. Because it does mean keeping the fact that we don't validate input at the surface and depend on database specific errors to trickle back up correctly. So if MySQL changes how it handles certain things, you'll get different errors on the surface. I'm gong to non-sequitor for a minute, because I think it's important to step back some times. What I want out of Nova API at the end of the day: 1. a way to discover what the API is because this massively simplifies writing clients, SDKs, tests, and documentation. All those pipelines are terribly manual, and have errors in them because of it. Like has been said before you actually need to read the Nova source code to figure out how to use parts of the API. I think this is a great example of that - https://blog.heroku.com/archives/2014/1/8/json_schema_for_heroku_platform_api?utm_source=newsletter&utm_medium=email&utm_campaign=januarynewsletter&mkt_tok=3RkMMJWWfF9wsRonuKzNZKXonjHpfsX57OQtX6SxlMI%2F0ER3fOvrPUfGjI4AScJrI%2BSLDwEYGJlv6SgFQrjAMapmyLgLUhE%3D 2. stop being optional If we ever want interoperability between Nova implementations we need to stop allowing the API to be optional. That means getting rid of extensions. Content is either part of the Nova API, or it isn't in the tree. Without this we'll never get an ecosystem around the API because anything more complicated than basic server lifecycle is not guarunteed to exist in an OpenStack implementation. Extensions thus far have largely just been used as a cheat to get around API compatibility changes based on the theory that users could list extensions to figure out what the API would look like. It's a bad theory, and not even nova command line does this. So users will get errors on nova cli with clouds because features aren't enabled, and the user has no idea why their commands don't work. Because it's right there in the nova help. 3. a solid validation surface We really need to be far more defensive on our API validation surface. Right now bad data makes it far too far down the code stack. That's just a recipe for security issues. = Current tensions = Cloud providers want v2 "for a long time" (which, honestly, was news). I'm not sure I completely know what that means. Are we talking about the bug for bug surface that is today? Are we talking about not wanting to change endpoints? If we are talking about exactly the v2 API as is, then I think we have an answer, which is push forward with v3, because they don't actually want us to fix issues in v2, as that might break existing users. Even subtle things might do that. At which point we treat the whole thing like grandma's china, and just don't touch it, at all. If we are talking about not wanting some of the more aggressive changes, like getting tenant_id out of urls, or making all our semantics consistent, then we are in a different position. Chris makes a good point that the v2 API is 50% again as much code as v3, with much less predictability. It's sometimes had to see exactly the code separation internally, which I think we probably should do some internal refactoring to make that more clear. Because backwards compatibilty is hard... a lot harder than you think. It's not just about the defined behavior, but about all the quirks. And this is where v2 is kind of terrible, because the quirks are crazy. Validation is not handled at the surface for many of the calls, so every time there is a change in nova.db it actually has the possibility of impacting the API. Things like this - https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L951 need to be in our code because of where the validation surface is (or more specifically isn't). Which also means the v2 API is probably terrible on the fuzzing side of the fence. Which is something we aren't testing upstream, because we haven't gotten there yet. So that's a big question: can we change the validation surface on v2? And I'm getting mixed reactions there. If the answer is *no*, because by nature it would not be backwards compatible, then I think we just have to say v3 it is, and we handle the weight of the 2 implementations. = Some way to make incremental progress = No matter the results or verdicts on v3, we need to figure out some way to make incremental progress. Microversioning, accept types, ... something. And it needs to not just be a surface, but also some internals mechanism so we can sanely handle this internally. Because the Nova API (including extensions) is huge. I challenge anyone to put the whole thing in their head at the moment and understand the implications between the pieces. You can't even use big chunks of it if you use cells, which we know of many large implementations out there. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
