You can introduce your own dedicate apis to dedicate pods clusters and host instead of jam them into update apis.
--Alex > -----Original Message----- > From: Deepti Dohare > Sent: Monday, January 14, 2013 9:48 PM > To: Alex Huang > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts > to a domain > > Hi Alex, > As you said, dedication apis should be added as a part of plugin, but here my > concern is , when we are dedicating a pod/cluster/host, I can use existing > apis (eg. updatePod or updateCluster) . How will I do that in plugins? > Please clarify. > > -Deepti > > > -----Original Message----- > > From: Alex Huang > > Sent: Tuesday, January 08, 2013 10:11 AM > > To: Deepti Dohare > > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts > > to a domain > > > > If anything I said doesn't make sense, don't hesitate to ask. > > > > --Alex > > > > > -----Original Message----- > > > From: Deepti Dohare > > > Sent: Monday, January 07, 2013 8:20 PM > > > To: cloudstack-dev@incubator.apache.org > > > Cc: Alex Huang > > > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > > > Hosts to a domain > > > > > > Thanks Alex for pointing out. I will update the FS keeping your points in > > mind. > > > > > > > > > > -----Original Message----- > > > > From: Alex Huang [mailto:alex.hu...@citrix.com] > > > > Sent: Tuesday, January 08, 2013 7:09 AM > > > > To: cloudstack-dev@incubator.apache.org > > > > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, > > > > Hosts to a domain > > > > > > > > Deepti, > > > > > > > > Your wiki has references to defunct wiki/bug tracking. Please > > > > correct that > > > by > > > > moving those into the apache wiki/jira. > > > > > > > > I don't think the two FSes has enough details for review yet but > > > > based on APIs posted, I can see the way it is heading so I want to > > > > make some requirements on the direction. Dedication is not an > > > > integral part of cloudstack. This requirement means the following > things. > > > > > > > > - You should not add dedication as an integral part of the > > > > organization units such as zone, pod, and cluster. It should be in > > > > steps > > reflected in the API. > > > For > > > > example, from an API standpoint, it should be > > > > - admin adds a pod > > > > - admin dedicates the pod to a domain > > > > - admin enables pod. > > > > - UI can makes these three calls on behalf of the admin if you want > > > > to introduce a easy step. > > > > - You should add a plugin that adds dedication apis and implements a > > > > deployment planner interface. > > > > - In cloudstack's core code itself, you should modify the following > > > > things. > > > > - service offering should carry a planner name to use. > > > > - deploy vm code should use the planner that's specified in > > > > the service offering. > > > > > > > > --Alex > > > > > > > > > > > > > -----Original Message----- > > > > > From: Deepti Dohare [mailto:deepti.doh...@citrix.com] > > > > > Sent: Monday, January 07, 2013 11:33 AM > > > > > To: cloudstack-dev@incubator.apache.org > > > > > Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, > > > > > Clusters, Hosts to a domain > > > > > > > > > > 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+Reso > > > > > urces+-+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
