I agree with David's suggestion of making it 2 way - service (compute) offering as well as letting the user to select
Hari -----Original Message----- From: David Nalley [mailto:da...@gnsa.us] Sent: Wednesday, January 2, 2013 8:54 AM To: cloudstack-dev@incubator.apache.org Cc: Kelven Yang Subject: Re: [PROPOSAL] Configurable setting to use linked clones or not on VMware On Wed, Jan 2, 2013 at 11:44 AM, Chip Childers <chip.child...@sungard.com> wrote: > On Wed, Jan 2, 2013 at 11:37 AM, David Nalley <da...@gnsa.us> wrote: >> On Wed, Jan 2, 2013 at 11:10 AM, Chip Childers >> <chip.child...@sungard.com> wrote: >>> On Wed, Dec 19, 2012 at 2:31 PM, Hari Kannan <hari.kan...@citrix.com> wrote: >>>> Hello All, >>>> >>>> >>>> >>>> I wish to propose a better VM sync in CloudStack - I have added >>>> some details >>>> here<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configu >>>> rable+setting+to+use+linked+clones+or+not+on+VMware> along with a >>>> JIRA ticket 670 >>>> >>>> Please review and comment >>>> >>>> Hari Kannan >>> >>> +1 to the concept. >>> >>> Same question as other emails: what release are you thinking for this? >>> Is someone taking this work on? >>> >>> I pulled out your question on the design page, and have some thoughts: >>> >>>> Should this be at a template level or account level or VM level?? >>> >>> Isn't this something that's more infrastructure centric? i.e.: >>> linked clone functionality is provided by the hypervisor, and really >>> is an operator decision (not a user decision). Should the >>> configuration reflect that, instead of leaking the infra >>> implementation details to the end user? >>> >> >> I don't know that this is truly infra-specific - why not make it part >> of the service offering; like local storage. Admin has to configure >> it, but user gets the option of choosing it. >> >> --David >> > > That's reasonable... the concern I have is that I'm not interested in > the end user selecting this without the operator agreeing to offering > it. Service offerings are certainly a way to accomplish that goal, > while also allowing users to decide when to use it. > > -chip My concern is that I don't want it to be boolean for an entire swath of infra - there are use cases for both. --David
