You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Rajani Karuturi (JIRA)" <ji...@apache.org> on 2015/03/16 04:44:05 UTC
[jira] [Updated] (CLOUDSTACK-7845) Strict Implicit Dedication
should allow for deploying owned Virtual Routers on dedicated host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajani Karuturi updated CLOUDSTACK-7845:
----------------------------------------
Fix Version/s: (was: 4.5.0)
4.5.1
> Strict Implicit Dedication should allow for deploying owned Virtual Routers on dedicated host
> ---------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-7845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7845
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the default.)
> Components: SystemVM, Virtual Router
> Affects Versions: 4.4.0
> Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS
> Reporter: Logan B
> Fix For: 4.5.1
>
>
> Currently the best method of isolation for domains or accounts is Strict Implicit Dedication. The reasoning is as follows:
> Goal: Dedicated a resource (host, cluster, or pod) to an account or domain.
> Problems:
> - Explicit Dedication: Account or domain's VMs are all deployed on it's dedicated resources. However, System VMs (Virtual Routers) belonging to OTHER accounts can also be deployed on those same resources (host, cluster, or pod). This is not desirable.
> - Preferred Implicit Dedication: Account or domain's VMs are deployed on it's dedicated resources. However, if those resources are near full utilization there is a chance that the account or domain's VMs will be deployed on resources that are not dedicated. This is less likely, but also undesirable.
> We are currently using both explicit and implicit dedication. The explicit dedication ensures that the first VM deployed is provisioned on the dedicated resources, while the implicit dedication ensures that other accounts can't deploy resources on the same dedicated resources (intentionally or not).
> Proposed changes:
> Currently Virtual Router's are considered to be owned by the "system" account, even though they are each tied to a specific user account. This probably doesn't need to change, but it makes a solution to the above issue easier since Virtual Router's are already tagged/associated with user accounts.
> I would suggest changing the Strict Implicit Dedication planner, and the Virtual Router deployment planner as follows:
> - Strict Implicit Dedication: When selecting a host for strict implicit dedication Virtual Router's belonging to the account that "owns" the resource should be ignored. Virtual Router's or other System VMs belonging to OTHER accounts should still be considered, and cause the deployment to fail.
> - Virtual Router deployment: Virtual Router's belonging to an account should prefer deployment on explicitly or implicitly dedicated resources belonging to that same account. In addition, deployment should not fail if the Strict Implicitly dedicated resource owner and the Virtual Router "owner" match.
> The end goal here is to provide absolute isolation for accounts or domains with dedicated resources. If someone pays for a 'private cloud' with dedicated hardware then all of their deployed services should end up on that hardware, and no other account/domain should be able to utilize the dedicated resources of another. This ensures that an outage or issue on a public resource doesn't affect the dedicated/private infrastructure, and "public" users can't consume private resources being paid for by someone else.
> Currently the only way this is possible is by dedicating an entire zone to an account, but that is far from ideal, and makes management of the overall deployment/networking/etc. much more of a hassle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)