Page History

...

The solution is not the final perfect solution, for sure, feedback and suggestion is always welcome to make it a much better and adaptive product.

Current problem:

1. Security and access check is lying around in different layers. For example, in apiSevlet we check the web access username/password credentials, apiServer checks the command existence, and several other checks, then the DB access check mainly is done at the service layer. So it is hard for developers and system admin to follow all the access and validations, to make sure all the checks are done correctly. To do it, developers need to be familiar with the various parts of the CS code.

...

5. Over the wire(OTW) entity is not well defined. For example, to listVMsCmd, it involves multiple DB access, with the large amount of data showing NICs, Vols, Secondary storage etc, the command can take quite a while.
6. Admin and user have basically the same end-point access.

The goal of the API refactoring is aiming to tackle these problems:

1. We would pull security checks, DB access checks, any related checks up from service layer/orchestration engine to the API layer as much as possible. This makes the necessary checking done more centralized and easy to follow. Conceptually the cloud orchestration engine layer handles the orchestration, the security check and the access check should have done before reaching this layer. This has performance benefits, since checks are done earlier instead of reaching deep in the code path; this also has the benefits of a clear architecture. The API layer does the necessary access check and role based authentication, makes it easier and dynamic for future policy change. New policy can be added easily and dynamically as a plugin to the system.

...

6. Separate the admin and user APIs. This is for developers to understand the code, which should be accessible by users, which should only be handled by Admin. Hence developers will have better grasp of the role and pay attention to the new code added. It also helps the document generated.

Notes:

1. For end users, the new APIs after refactoring looks pretty much the same. One big change is the ID, we will always use UUID in the over the wire APIs. The UUID can be created by Cloudstack, or can be provided by users (we call it Xid – external ID). Every UUID should be unique in the cloudstack system.

...