Plugin should not be responsible for existence of checking an API, this was wrong.
Throw exception boldly when checkAccess fails.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Fix method to return listApis per api name basis
- Return api response, api related cmd etc. as part of response
- Caching and processing all cmd, response classes when plugin starts, made class
list, maps static so they are shared by multiple instances in case, takes about
1306ms to do the processsing but only on load time
- Cache for first listApi() and return precached data thereon, takes 2.2ms
for first call, during runtime and 0ms thereon
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Fix StaticRoleBasedAPIAccessChecker to check api access based on roletype
- Remove properties file which is not needed now for api discovery plugin
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
In case of api discovery, it does not make sense to create a separate properties file
If this plugin is enabled in components.xml, a user should be able to discover
all the apis accessible to their role.
listApis based on role type of caller user
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Makes plugins self contained so they decide their properties file format
- PluggableService creates the contract that implementing entity will return a
properties map which is apiname:rolemask (both are strings)
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Remove usage and impl as adapter.
We have duplicate code that generates apiname:cmd class maps which is
unavoidable right now as:
- Plugin should not depend on ApiServer or any other component
- cloud-utils cannot depend on cloud-api for the APICommand annotation
- Use java reflect to create a static method in cloud-utils that does the job
would be unsafe.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
- Introduces api/discovery plugin that helps discover apis on the mgmt server
- It's a pluggable service, therefore has it's own api-discovery_commands.properties
where the discovery api, listApi can be blacklisted (by removing it), or it's
role mask can be changed
- By default its response has all the apis
- Changes in other parts of the code to make it work, viz. components.xml, pom.xml,
and in ApiServer where it is used as an adapter to get apiname, cmd mappings
The ApiDiscoveryService interface is a contract that the implementing class will
provide:
1. A means to get all the apis as a list of response, plugin is free to implement
the response class, as long as it extends on the BaseResponse:
ListResponse<? extends BaseResponse> listApis();
2. Provides a map of apiname as the key and cmd class as the value:
Map<String, Class<?>> getApiNameCmdClassMapping();
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Modify the spec file to package the agent files and the scripts
Some changes to the poms to put the java dependencies in the right place.
Move the agent script to the dedicated os dir in packaging.
Issue seen during system vm template upgrade and restoreVM command
scenarios for vmware. In these cases CS tries to recreate root disk with
same name as the existing one, in case of vmware this results in creation
of vmdk file with same name for both existing and new root volume.
This results in undesired behavior when storage cleanup thread tries to
cleanup old volume. Made the vmdk file name unique by adding the volume
id to it. This will ensure that during volume recreation in the scenarios
mentioned vmdk will get created with a new name and there will be
no undesired side effects of running the storage cleanup thread.
Rohit Yadav
Kelven Yang
Alex Huang
Edison Su
Min Chen
Prasanna Santhanam
Noa Resare
Hugo Trippaers
Murali Reddy
Koushik Das