cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Animesh Chaturvedi (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-7845) Strict Implicit Dedication should allow for deploying owned Virtual Routers on dedicated host
Date Tue, 02 Dec 2014 19:37:15 GMT

     [ 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)

Mime
View raw message