Based on the discussion, we have 2 separate features: 1. Private pod, cluster, host 2. VMs on hardware dedicated to a specific account Functional specs for these 2 features are posted on Apache CloudStack wiki:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+VMs+on+hardware+dedicated+to+a+specific+account https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dedicated+Resources+-+Private+pod%2C+cluster%2C+host+Functional+Spec This is the first draft, and modifications will be done along the way. Thanks Deepti > -----Original Message----- > From: Hari Kannan [mailto:hari.kan...@citrix.com] > Sent: Thursday, December 27, 2012 10:30 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts > to a domain > > Hi Nitin, > > Please see inline > > Hari > > -----Original Message----- > From: Nitin Mehta [mailto:nitin.me...@citrix.com] > Sent: Wednesday, December 26, 2012 9:01 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts > to a domain > > > On 27-Dec-2012, at 4:47 AM, Hari Kannan wrote: > > > Hi Alex, > > > > There is no requirement for the end user administer the hardware - > > > > Regarding the OAMP, I believe the resources are still owner, > > administered, maintained and provisioned by the root admin - they are > > simply "reserved" for the said domain/sub-domain > > > > But, what would the admin view of all the resources be. Lets say he has > dedicated Pod P1 to domain D1 and Cluster C1 to domain D2 and Host h1 to > domain D3 then in this case how will his dashboard look like ? > > Hari: Perhaps, the issue is we have a single persona called admin that seems > to be a catch-all. This admin role is actually composed of multiple roles - I > see > the OAMP task as a provider side role - and hence no different than today > from that perspective - i.e. the domain admin (which is the "consumer" side > role) need not have access to the provider side resources - this might be a > need for Hosting environments, but for a cloud service provider as well as > private clouds, I don't know if this is a requirement. I do agree that it > would > be a nice to have feature though.. > > > Regarding CRUD/Mice's question - I don't believe that is the intention - For > context, Mice wrote " but if further sub-domain is assigned a different pod > then it cannot access its parent domain's pod. 2. Sub-domain and its child > domains will have the sole access to that new pod. when child domain > already has some VMs on parent domain's dedicated pod, is it allowed to > assign a pod to the child domain? or the existing VMs will be migrated to the > new pod?" > > > > However, I think of this feature more along the lines of what Saurav wrote > " Lets say that the resources on the pod dedicated to the child-domain are > exhausted and resources on parent pod are available. In this case will > provisioning of vms for the child-domain happen on parent's pod. So > essentially provisioning has a affinity for local pods if available. And if > resources are not available on the local pod but available on the parent pod > then use that. Would it be good to configure this affinity" > > > > I am afraid affinity is not the right thing to configure. The child domain > has the > expectation and is paying for dedicating resources just to itself. If these > resources exhaust we should definitely fail deploying his vm. Instead if we > deploy it in its parent dedicated resources and still charge him premium that > is not correct. We should set the expectations right. > > Hari: I'm open to either choice - dedication can be interpreted differently - > If I > have some resources dedicated, no one else can touch it, it doesn't mean I > don't get anything more - my preference is to use a global to indicate if I > can > draw from parent pool or not, with the default choice of "yes" > > Also what will be the change in usage ? How will we be metering the end > user here with dedicated resources? > > I also think we need to have a flag in the service offering asking the end > user > if he/she wants to deploy vm on dedicated or shared resources. > > > > Hari > > > > -----Original Message----- > > From: Alex Huang [mailto:alex.hu...@citrix.com] > > Sent: Friday, December 21, 2012 9:48 AM > > To: cloudstack-dev@incubator.apache.org > > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > > Hosts to a domain > > > > Planners are also plugins. It just means your dedicated piece needs to > implement a different planner. > > > > We may need some cloud-engine work. Prachi and I talked about the idea > to let the service offering contain the planner cloud-engine should use to > deploy a vm. You can explore that idea. > > > > But this part is just action acl. This is the easy part. The more > > difficult part is > the read part. How do you limit what they can access. That part you need to > talk with Prachi about on her design. > > > > Is there any requirement to let the end user administer the hardware since > the hardware is dedicated to them? > > > > My problem right now is the list of requirements sent in your email is not > enough. We need to send out a list with regard to the following. > > > > - OAMP. This means (Operations, Administrations, Maintenance, > Provisioning) of hardware/physical entities/capacities. Who is ultimately > responsible for the OAMP aspects of the dedicated resources? Is it the > domain admin/system amdin/ or some new role? Depending on this, your > interaction with the new ACL work can range from low to high. This needs to > be clearly outlined in the requirements. > > - CRUD operations. This means (Create, Read, Update, Delete) on virtual > entities and physical entities. How does dedication affect those operations? > For example, questions asked by Mice in another email. Here, you need to > gather up the list of virtual entities we have and specify what it means for > that entities in terms of CRUD. > > > > This is not a small feature. Tread carefully. > > > > --Alex > > > >> -----Original Message----- > >> From: Prachi Damle [mailto:prachi.da...@citrix.com] > >> Sent: Friday, December 21, 2012 2:59 AM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > >> Hosts to a domain > >> > >> Comments inline. > >> > >> -Prachi > >> -----Original Message----- > >> From: Devdeep Singh [mailto:devdeep.si...@citrix.com] > >> Sent: Friday, December 21, 2012 4:16 PM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > >> Hosts to a domain > >> > >> Some queries inline > >> > >>> -----Original Message----- > >>> From: Prachi Damle [mailto:prachi.da...@citrix.com] > >>> Sent: Friday, December 21, 2012 3:04 PM > >>> To: cloudstack-dev@incubator.apache.org > >>> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > >>> Hosts to a domain > >>> > >>> Planners and allocators work on a DeploymentPlan provided as input. > >>> The caller can specify particular zone, pod, cluster, host, pool > >>> etc., to be used for deployment. > >>> So for enforcing the use of a dedicated pod, caller can set the > >>> podId in the plan and planners will search under the specific pod only. > >> > >>>> If a deploy vm request is from a user belonging to a domain which > >>>> has a > >> dedicated resource, then setting the podid/clusterid etc. will work. > >> However, if I understand correctly there is a requirement that no > >> user from outside the domain, should be able >>to use the dedicated > >> resource. They cannot be restricted by how the planner is implemented > >> right now. Should the avoid list be used? But it doesn't seem like the > >> right > use of the field. > >> > >> > >> Yes avoid set lets you set the zone,pods,clusters,hosts to be avoided > >> by the planner. It can be used for this purpose. > >> > >> > >>> > >>> There may be some changes necessary (like accepting a list of > >>> pods/clusters instead of single Ids) but this design of planners > >>> should let you enforce the use of dedicated resources without major > >> changes to planners. > >> > >>>> Doesn't this mean that we are changing the core cloudstack code to > >> achieve dedicated resources features? > >> > >> > >> This change is not necessary; it is an optimization. > >> > >> Also, another way is to add a custom planner say > >> DedicatedResourcePlanner that will search for only dedicated resources > for the given account. > >> > >> > >>> -----Original Message----- > >>> From: Devdeep Singh [mailto:devdeep.si...@citrix.com] > >>> Sent: Friday, December 21, 2012 2:58 PM > >>> To: cloudstack-dev@incubator.apache.org > >>> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > >>> Hosts to a domain > >>> > >>> Hi Alex, > >>> > >>> I assume some apis will be added for letting an admin dedicate a > >>> pod/cluster etc to a domain. This can be contained in a plugin. > >>> However, for enforcing that a dedicated resource is picked up for > >>> servicing deploy vm requests from a user; wouldn't planners and > >>> allocators have to be updated to take care of this? > >>> > >>> Regards, > >>> Devdeep > >>> > >>>> -----Original Message----- > >>>> From: Alex Huang [mailto:alex.hu...@citrix.com] > >>>> Sent: Thursday, December 20, 2012 7:21 PM > >>>> To: cloudstack-dev@incubator.apache.org > >>>> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, > >>>> Clusters, Hosts to a domain > >>>> > >>>> Deepti, > >>>> > >>>> As Chiradeep pointed out, you should get in contact with Prachi. > >>>> You should plan on this after the ACL change or you can help out on > >>>> the ACL > >>> change. > >>>> > >>>> For this feature, you really need to think about the stats > >>>> collection side of this because you'll need to provide a lot of > >>>> warnings about being near capacity so people can plan accordingly. > >>>> It cannot be a case of the dedicated resource explodes and then > >>>> they go and work on expanding it. So you should also talk with > >>>> Murali about how to do alerts in > >>> his new notification system. > >>>> > >>>> And then in your spec, you need to plan out how to do this in a > >>>> plugin architecture and not modify the core code. > >>>> > >>>> --Alex > >>>> > >>>>> -----Original Message----- > >>>>> From: Deepti Dohare [mailto:deepti.doh...@citrix.com] > >>>>> Sent: Thursday, December 20, 2012 4:32 AM > >>>>> To: cloudstack-dev@incubator.apache.org > >>>>> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, > >>>>> Clusters, Hosts to a domain > >>>>> > >>>>> Hi Mice, > >>>>> > >>>>> Once a new pod is dedicated to the child-domain, deployment of > >>>>> the new VMs will happen only in the new pod. > >>>>> The existing VMs will keep running on parent-domain's pod. > >>>>> > >>>>> Do you have any other suggestion on this. > >>>>> > >>>>> - Deepti > >>>>>> -----Original Message----- > >>>>>> From: Mice Xia [mailto:weiran.x...@gmail.com] > >>>>>> Sent: Thursday, December 20, 2012 4:52 PM > >>>>>> To: cloudstack-dev@incubator.apache.org > >>>>>> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, > >>>>>> Clusters, Hosts to a domain > >>>>>> > >>>>>> but if further sub-domain is assigned a different pod then it > >>>>>> cannot access > >>>>> its > >>>>>> parent domain's pod. 2. Sub-domain and its child domains will > >>>>>> have the sole access to that new pod. > >>>>>> > >>>>>> when child domain already has some VMs on parent domain's > >>>>>> dedicated pod, is it allowed to assign a pod to the child domain? > >>>>>> or the existing VMs > >>>>> will > >>>>>> be migrated to the new pod? > >>>>>> > >>>>>> mice
