Changes:
- 'ExcplicitDedication' type of group can be created/deleted by Root admin only
- Users can no longer create this type of affinity group
- RootAdmin can create this type of affinitygroup at domain level. Such a domain level group is available for all accounts in that domain for listing and for use during deployVM.
- The domain level affinitygroup should be visible to the users in that domain, domain admins and Root admin.
Conflicts:
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java
This issue is happing because of the steps the code follow to cleanup the account.
The cleanupAccount was deleting the entries from the resource_limit and
resource_count table and performing further cleaning afterwards. Ideally, deletion
of entries from resourceLimit and resourceCount should be the last step in
cleanupAccount process.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
include the UUID of the user/domain that was disabled.
- added enity type and enity UUID details to UserContext
- publish the entity type and UUID details for the action events
generated for accout/user/domain
This feature allows a user to deploy VMs only in the resources dedicated to his account or domain.
1. Resources(Zones, Pods, Clusters or hosts) can be dedicated to an account or domain.
Implemented 12 new APIs to dedicate/list/release resources:
- dedicateZone, listDedicatedZones, releaseDedicatedZone for a Zone.
- dedicatePod, listDedicatedPods, releaseDedicatedPod for a Pod.
- dedicateCluster, listDedicatedClusters, releaseDedicatedCluster for a Cluster
- dedicateHost, listDedicatedHosts, releaseDedicatedHost for a Host.
2. Once a resource(eg. pod) is dedicated to an account, other resources(eg. clusters/hosts) inside that cannot be further dedicated.
3. Once a resource is dedicated to a domain, other resources inside that can be further dedicated to its sub-domain or account.
4. If any resource (eg.cluster) is dedicated to a account/domain, then resources(eg. Pod) above that cannot be dedicated to different accounts/domain (not belonging to the same domain)
5. To use Explicit dedication, user needs to create an Affinity Group of type 'ExplicitDedication'
6. A VM can be deployed with the above affinity group parameter as an input.
7. A new ExplicitDedicationProcessor has been added which will process the affinity group of type 'Explicit Dedication' for a deployment of a VM that demands dedicated resources.
This processor implements the AffinityGroupProcessor adapter. This processor will update the avoid list.
8. A VM requesting dedication will be deployed on dedicatd resources if available with the user account.
9. A VM requesting dedication can also be deployed on the dedicated resources available with the parent domains iff no dedicated resources are available with the current user's account or
domain.
10. A VM (without dedication) can be deployed on shared host but not on dedicated hosts.
11. To modify the dedication, the resource has to be released first.
12. Existing Private zone functionality has been redirected to Explicit dedication of zones.
13. Updated the db upgrade schema script. A new table "dedicated_resources" has been added.
14. Added the right permissions in commands.properties
15. Unit tests: For the new APIs and Service, added unit tests under : plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/DedicatedApiUnitTest.java
16. Marvin Test: To dedicate host, create affinity group, deploy-vm, check if vm is deployed on the dedicated host.
associated with account
Unlike public ip which gets dis-associated (released) with the account
on network/VPC delete, portable IP should continue to be associated with
the account even when the network/VPC with which it is currently
associated in deleted. This fix ensures portable IP are associated to
account even after network/vpc is deleted.
Description:
Making SHA256SALT the default encoding algorithm to encode
passwords when creating/updating users.
Introducing a new configurable list to allow admins to
separately configure the order of preference for encoding
and authentication schemes.
Since passwords are now sent by clients as clear text,
fixing the Plain text authenticator to check against the
password passed in rather than its md5 digest.
Removed region_id from user/account and domain tables.
Removed forwarding of api calls to owner region.
Removed api_key and secret_key from region table.
Included related DB upgrade changes.
following changes
- introduced notion of event bus with publish, subscribe, unsubscribe
semantics
- a plug-in can implement the EventBus abstraction to provide event
bug to CloudStack
- A rabbitMQ based plug-in that can interact with AMQP servers to
provide message broker based event-bug
- stream lines, action events, usage events, alerts publishing in to
convineance classed which are also used to publish corresponding
event on to event bus
- introduced notion of state change event. On a state change, in the
state machine corrsponding to the resource, a state change event is
published on the event bug
- associated a state machined with Snapshot and Network objects
- Virtual Machine, Volume, Snaphost, Network object state changes wil
result in a state change event
Reverting commit as we don't want the daos to move to cloud-api.
We'll eventually breakout cloud-server and create cloud-api-server for the standalone
api server.
This reverts commit 7597a38f7a.
This is part 1 of list API refactoring. Commands covered:
listVmsCmd, listRoutersCmd Response covered:
UserVmResponse, DomainRouterResponse. DB views created:
user_vm_view, domain_router_view.
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.
1) Always fail to authenticate system user.
2) DB - always create system user with RANDOM not null password
3) Don't allow modifying (setting api/secretKeys, etc) system user via API
Conflicts:
server/src/com/cloud/user/AccountManagerImpl.java
setup/db/db/schema-305to306.sql
Alex Huang
Prachi Damle
Prasanna Santhanam
Sanjay Tripathi
Murali Reddy
Alena Prokharchyk
Saksham Srivastava
Nitin Mehta
Likitha Shetty
Vijayendra Bhamidipati
Murali Reddy
Jessica Wang
Kelven Yang
Kishan Kavala
Edison Su
Rohit Yadav
joesan
Min Chen
Deepak Garg
Hugo Trippaers
Rohit Yadav
Sheng Yang
bfederle