[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7845:
-------------------------------------------

BULK EDIT> As you know 4.5 is getting ready for release and these New feature 
and Improvement tickets are still open, please update the status. If the 
changes are not committed yet then these tickets need to be moved out of 4.5

> 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.0
>
>
> 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)

Reply via email to