Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D3FABD306 for ; Wed, 26 Dec 2012 21:13:17 +0000 (UTC) Received: (qmail 97583 invoked by uid 500); 26 Dec 2012 21:13:17 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 97526 invoked by uid 500); 26 Dec 2012 21:13:17 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 97517 invoked by uid 99); 26 Dec 2012 21:13:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Dec 2012 21:13:17 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hari.kannan@citrix.com designates 66.165.176.63 as permitted sender) Received: from [66.165.176.63] (HELO SMTP02.CITRIX.COM) (66.165.176.63) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Dec 2012 21:13:10 +0000 X-IronPort-AV: E=Sophos;i="4.84,359,1355097600"; d="scan'208";a="1801726" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Dec 2012 21:12:49 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 26 Dec 2012 13:12:49 -0800 From: Hari Kannan To: "cloudstack-dev@incubator.apache.org" Date: Wed, 26 Dec 2012 13:12:48 -0800 Subject: RE: [DISCUSS] Limit Resources to domain/account Thread-Topic: [DISCUSS] Limit Resources to domain/account Thread-Index: Ac3faPh/RtRaRfFyRmW8Vlg97vnhSgD3q6qAAA778sAACnNDgA== Message-ID: <6E004C34C1C59E45A35B4338808BC315013014D30E47@SJCPMAILBOX01.citrite.net> References: <02C38648D4635F4EB02DE11EE81CF1EE012AAD884840@BANPMAILBOX01.citrite.net> <67EF18FDCA335F489B366120481AB6C5F6B38A439D@BANPMAILBOX01.citrite.net> In-Reply-To: <67EF18FDCA335F489B366120481AB6C5F6B38A439D@BANPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org 11 and 12 should mean "amount of primary (secondary) storage space", IMO -----Original Message----- From: Venkata SwamyBabu Budumuru [mailto:venkataswamybabu.budumuru@citrix.c= om]=20 Sent: Wednesday, December 26, 2012 8:16 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS] Limit Resources to domain/account Hi Sanjay, Few queries I have here : (i) what is the difference between (3) and (11) ? (ii) what is the difference between (4), (5) and (12) except no. of ISOs?=20 (iii) how the network bandwidth you mentioned in (13) is different from thr= ottling that we specify at network offering / vm.network.throttling.rate - = used by service offering ? (iv) can you please give some more info on how this is going to help provid= ers / accounts with this additional setting? Is this to control some kind o= f licensing limitations? Thanks, SWAMY -----Original Message----- From: Sanjay Tripathi [mailto:sanjay.tripathi@citrix.com]=20 Sent: Wednesday, December 26, 2012 2:57 PM To: cloudstack-dev@incubator.apache.org Subject: [DISCUSS] Limit Resources to domain/account Hi all, CloudStack today offers the ability to limit the following resources to a d= omain/account: 1. VM - Number of instance a user can create 2. Pubic IP - Number of public= IP addresses a user can own. 3. Volume - Number of disk volumes a user can create. 4. Snapshot - Number of snapshots a user can create. 5. Template - Number of templates that a user can register/create. 6. Projects - Number of projects a user can create. 7. Network - Number of guest networks that a user can create. 8. VPC - Number of VPCs that a user can create These limits are useful to some extent but if admin would like to allow use= r to create custom VMs based on need, for e.g. one large VM or many small V= Ms etc.=20 Admin would like to restrict the resources like CPU, RAM, storage etc. a us= er can consume by setting limits. I would like to propose a new feature based on the above mentioned requirem= ents in which admin would be able to set limits on following resources apar= t from the above mentioned resources types: 9. CPUs 10. RAM 11. Primary (shared) storage (Volumes) 12. Secondary storage (Snapshots, Templates & ISOs) 13. Network bandwidth r= ate (in bps) 14. Number of times a OS template can be deployed I am working on FS and will share it shortly. Please let me know your comments/suggestions. Thanks, Sanjay =09