- Added implementation for add/list asa1kv APIs
- Added agent command for associating asa1kv appliance with logical edge firewall in VNMC
- Added handler for the above agent command in VNMC resource class
- Updated VNMC element class to support the above
a. Added handlers for CreateLogicalEdgeFirewall and ConfigureNexusVSMForASA commands
b. Logic for add/list vnmc device API
c. Partial implementation for network element implement()
a. Logical edge firewall creation in VNMC
b. Asa1kv vservice node creation and updating asa1kv inside port profile with guest network vlan id in n1kv VSM
Impl. and use UserContext to get User.
CloudStack's @Inject is horrible, it may sometimes fail to inject account service
during startup. Do a lazy injection using ComponentLocator when needed.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
Although I still think the templates aren't well maintained, I just
added 12.04 since this is an LTS and people probably want it in the
list of templates.
This system should be more generic I think though.
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>