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>
The authenticators now have an encode function that cloudstack will use to encode the user supplied password before storing it in the database. This makes it easier to add other authenticators with other hashing algorithms. The requires a two step approach to creating the admin account at first start as the authenticators are only present in the management-server component locator.
The SHA256 salted authenticator make use of this new system and adds a hashing algorithm based on SHA256 with a salt. This type of hash is far less susceptible to rainbow table attacks.
To make use of these new features the users password will be sent over the wire just as he typed it and it will be transformed into a hash on the server and compared with the stored password. This means that the hash will not go over the wire anymore.
The default authenticator in components.xml is still set to md5 for backwards compatibility. For new installations the sha256 could be enabled.
2) Added services api support for plugging/unplugging the nics to VpcElement
Conflicts:
api/src/com/cloud/network/NetworkService.java
core/src/com/cloud/vm/VMInstanceVO.java
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
At this point, the mgmt server comes up, loading the
Nexus related modules without dying.
Description:
1) Added a new properties file for Cisco N1kv VSM commands:
cisconexusvsm_commands.properties.in
2) Added the CiscoNexusVSMElement to the components.xml file.
3) Modified CiscoNexusVSMElement to implement NetworkElement.
The NetworkElement interface functions are not
relevant to the N1KV VSM, so we override them
with noops.
4) Added an addDao() of CiscoNexusVSMDeviceDaoImpl in populateDaos(),
else we'd run into a failure to look up the VSM's dao when the
mgmt server is starting up:
com.cloud.utils.exception.CloudRuntimeException: Unable to find DAO com.cloud.network.dao.CiscoNexusVSMDeviceDao
5) Also added the CiscoNexusVSMElementService in populateServices(),
and modified CiscoNexusVSMElement to implement Manager as well.
6) populateServices() was running into an exception that indicated
that it was unable to find a commands.properties file for the
cisco n1kv vsm service. Fixed it by changing getProperties() in
CiscoNexusVSMElement to return the correct string
"cisconexusvsm_commands.properties", and putting in an @Override
for getProperties() in CiscoNexusVSMElement. Also fixed up all
the other functions in CiscoNexusVSMElement that needed to have
@Override. Also updated build/developers.xml with this file
location. And did other small cleanup.
7) More clean up in CiscoNexusVSMDeviceManagerImpl.
Conflicts:
server/src/com/cloud/configuration/DefaultComponentLibrary.java
When elb capability is enabled on the network offering, we:
1) on each createLB command:
* associate ip address to the LB rule owner
* create LB rule
2) on each deleteLb command:
* delete the rule
* disassociate ip address
The rule belongs to the owner, so proper usage events are generated
2) Added elasticIp and elasticLb network capabilities. Provided support to create network offering with these capabilities.
3) Added one more default network offering having elasticip and elasticlb
4) Public network support to Basic zone. You can associate/disassociate IP addresses now
1. remove Garbagecollection primary storage allocator. other storage allocators fails may because there is primary storage with the same tag, it is not caused by no primary storage capacity.
2. delete template will try to delete templates in secondary storage in the API.
status 11497: resolved fixed
GarbageCollecting
Conflicts:
server/src/com/cloud/template/HyervisorTemplateAdapter.java
Rohit Yadav
Hugo Trippaers
Edison Su
Rajesh Battala
Alena Prokharchyk
Chip Childers
Salvatore Orlando
Sheng Yang
Murali reddy
Vijayendra Bhamidipati
kishan
frank
anthony
Kelven Yang
Abhinandan Prateek