Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of deepti.dohare@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Deepti Dohare <deepti.dohare@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 8 Jan 2013 01:03:05 +0530
Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts
 to a domain
Thread-Topic: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Hosts
 to a domain
Thread-Index: Ac3j7y2mNtXOVdm/TmuecmvnWSdn0QAYlengAi6ZJLA=
Message-ID: 
 <F903CD64D5FE5B47878921870531C1800108A986775B@BANPMAILBOX01.citrite.net>
References: 
 <F903CD64D5FE5B47878921870531C1800108A90AC41A@BANPMAILBOX01.citrite.net>
 <CALT7reqwiE_eLGWGhoc5qo+-3ATvUY7WHLDfw3GnHwCLjHL9xQ@mail.gmail.com>
 <F903CD64D5FE5B47878921870531C1800108A90AC4D7@BANPMAILBOX01.citrite.net>
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385E046@SJCPMAILBOX01.citrite.net>
 <2529883E7B666F4E8F21F85AADA43CA7010C8EB1BF82@BANPMAILBOX01.citrite.net>
 <7A92FF96DF135843B4B608FB576BFC3E012DA2CF1FB2@SJCPMAILBOX01.citrite.net>
 <2529883E7B666F4E8F21F85AADA43CA7010C8EB1BFBB@BANPMAILBOX01.citrite.net>
 <7A92FF96DF135843B4B608FB576BFC3E012DA2CF1FB3@SJCPMAILBOX01.citrite.net>
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385E268@SJCPMAILBOX01.citrite.net>
 <6E004C34C1C59E45A35B4338808BC315013014D30E62@SJCPMAILBOX01.citrite.net>
 <71B440E4-2B16-4FB8-926D-FCDFF95D47F9@citrix.com>
 <6E004C34C1C59E45A35B4338808BC315013014D30EBD@SJCPMAILBOX01.citrite.net>
In-Reply-To: 
 <6E004C34C1C59E45A35B4338808BC315013014D30EBD@SJCPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Based on the discussion, we have 2 separate features:=20

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+hardwa=
re+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.kannan@citrix.com]
> Sent: Thursday, December 27, 2012 10:30 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Host=
s
> to a domain
>=20
> Hi Nitin,
>=20
> Please see inline
>=20
> Hari
>=20
> -----Original Message-----
> From: Nitin Mehta [mailto:Nitin.Mehta@citrix.com]
> Sent: Wednesday, December 26, 2012 9:01 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Host=
s
> to a domain
>=20
>=20
> On 27-Dec-2012, at 4:47 AM, Hari Kannan wrote:
>=20
> > 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
> >
>=20
> 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 ?
>=20
> Hari: Perhaps, the issue is we have a single persona called admin that se=
ems
> 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" si=
de
> 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 a=
s
> private clouds, I don't know if this is a requirement. I do agree that it=
 would
> be a nice to have feature though..
>=20
> > 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 p=
od
> then it cannot access its parent domain's pod. 2. Sub-domain and its chil=
d
> 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 wr=
ote
> " Lets say that  the resources on the pod dedicated to the child-domain a=
re
> 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"
> >
>=20
> I am afraid affinity is not the right thing to configure. The child domai=
n has the
> expectation and is paying for dedicating resources just to itself. If the=
se
> 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.
>=20
> Hari: I'm open to either choice - dedication can be interpreted different=
ly - 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"
>=20
> Also what will be the change in usage ? How will we be metering the end
> user here  with dedicated resources?
>=20
> I also think we need to have a flag in the service offering asking the en=
d user
> if he/she wants to deploy vm on dedicated or shared resources.
>=20
>=20
> > Hari
> >
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@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 t=
o
> deploy a vm.  You can explore that idea.
> >
> > But this part is just action acl.  This is the easy part. The more diff=
icult part is
> the read part.  How do you limit what they can access.  That part you nee=
d to
> talk with Prachi about on her design.
> >
> > Is there any requirement to let the end user administer the hardware si=
nce
> 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 ultimatel=
y
> 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 virtua=
l
> entities and physical entities.  How does dedication affect those operati=
ons?
> 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.Damle@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.singh@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.Damle@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 onl=
y.
> >>
> >>>> 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.singh@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.Huang@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.dohare@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.xia1@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