Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.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>
CC: Alex Huang <Alex.Huang@citrix.com>
Date: Tue, 8 Jan 2013 09:49:37 +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/TmuecmvnWSdn0QAYlengAi6ZJLAADJ/McAAGKibw
Message-ID: 
 <F903CD64D5FE5B47878921870531C1800108A9867797@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>
 <F903CD64D5FE5B47878921870531C1800108A986775B@BANPMAILBOX01.citrite.net>
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385ECE9@SJCPMAILBOX01.citrite.net>
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385ECE9@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

Thanks Alex for pointing out. I will update the FS keeping your points in m=
ind.


> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Tuesday, January 08, 2013 7:09 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Dedicated Resources: Dedicate Pods, Clusters, Host=
s
> to a domain
>
> Deepti,
>
> Your wiki has references to defunct wiki/bug tracking.  Please correct th=
at 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 u=
nits
> such as zone, pod, and cluster.  It should be in steps reflected in the A=
PI.  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 thing=
s.
>         - service offering should carry a planner name to use.
>         - deploy vm code should use the planner that's specified in the s=
ervice
> offering.
>
> --Alex
>
>
> > -----Original Message-----
> > From: Deepti Dohare [mailto:deepti.dohare@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.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,
> > > Hosts to a domain
> > >
> > > Hi Nitin,
> > >
> > > Please see inline
> > >
> > > Hari
> > >
> > > -----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,
> > 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 li=
ke ?
> > >
> > > 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 thoug=
h..
> > >
> > > > 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 t=
hat.
> 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.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 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.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 inpu=
t.
> > > >>> 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 wor=
k.
> > > >> 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 accordingl=
y.
> > > >>>> 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 doma=
in?
> > > >>>>>> or the existing VMs
> > > >>>>> will
> > > >>>>>> be migrated to the new pod?
> > > >>>>>>
> > > >>>>>> mice