Return-Path: X-Original-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E569AE50F for ; Mon, 18 Mar 2013 07:14:12 +0000 (UTC) Received: (qmail 10266 invoked by uid 500); 18 Mar 2013 07:14:12 -0000 Delivered-To: apmail-incubator-cloudstack-users-archive@incubator.apache.org Received: (qmail 9966 invoked by uid 500); 18 Mar 2013 07:14:11 -0000 Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-users@incubator.apache.org Delivered-To: mailing list cloudstack-users@incubator.apache.org Received: (qmail 9938 invoked by uid 99); 18 Mar 2013 07:14:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Mar 2013 07:14:10 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.220.182] (HELO mail-vc0-f182.google.com) (209.85.220.182) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Mar 2013 07:14:05 +0000 Received: by mail-vc0-f182.google.com with SMTP id ht11so2714977vcb.41 for ; Mon, 18 Mar 2013 00:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=megahappy.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=VlK0K2as67NqS9fctIGP/WhliG4EmJcrpJBLJ83ycmg=; b=Us2lGGvUyhlE3K0p7qNR14XnUG/EQDb+iXO2a9sddRLdMnrZB54Uj52upEaAtonpcr ufIxGTurw9yEzhIS+F6011YRXMQ8Q+lPHKWqUIjg+Gpabjxkp3Ds6lEVaqCLASAmkHUM E0QMQEIv+1pwmJqzg1WvNdVrATfS2Q5+/B1XI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=VlK0K2as67NqS9fctIGP/WhliG4EmJcrpJBLJ83ycmg=; b=fnUOzDW/zAoDZXA6gHrpd+SwmxEh3ysXFnxB6st0UoRa2q8Qu95hh7mdmWk0GQPNjM NM1pGEcS/JYWj3FE/cMEs+ZUfA6wSUgq1mPUbhWvWyjN0lo6phmG4w9puU/TwzlttaSH rIOY6CYLWCCsio6ad5pePEamVDopSIlh7CqaOpXjHd+v4QZfVEzCHwtQS76NnwoiEoqZ nkxHovLj/nhYAsfLAXZ/7HF7mFa51X9iPP6UpmKmeh8d8KAj7WBF6XAkwSfHU19jGwkh eAFGCn62j4NRUyE8+3DbQ79yWOoXe1adKraeOzXwTfD/82R5EGPnNW950SbVxsKlsryK 9P7g== MIME-Version: 1.0 X-Received: by 10.52.99.42 with SMTP id en10mr15864266vdb.37.1363590823605; Mon, 18 Mar 2013 00:13:43 -0700 (PDT) Received: by 10.58.212.4 with HTTP; Mon, 18 Mar 2013 00:13:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 00:13:43 -0700 Message-ID: Subject: Re: restricting users to a or Zone / Cluster From: Bryan Whitehead To: "cloudstack-users@incubator.apache.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmxPJQ5bOVBLQMXXZSy/mk1Jk0VxL6PJokClmUqTna47iDR2xYxR4liWrHhqhHfxIv8o4/8 X-Virus-Checked: Checked by ClamAV on apache.org After reading the URLs above it sounds like I can use tags to get what I want... If I tag a cluster or a primary storage that is related to a particular cluster - then I could also use the same tag when deploying Instances to make sure only certain Instances go to a certain cluster (or primary storage)? Is that right? On Sun, Mar 17, 2013 at 8:47 AM, Nitin Mehta wrote: > Something close to this is already being worked on. These talk about > dedicating resources to accounts/domain. See if you can find a flag to > "restrict" them as well. > Or you can create an enhancement for the same > > 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+ > -+Public+IP+Addresses+and+VLANs+per+Tenant > > > Dedicating templates should be possible by using launchPermissions api for > templates. > > Thanks, > -Nitin > > On 15/03/13 9:22 PM, "Kirk Jantzer" wrote: > >>Bryan, I like this idea - being able to restrict accounts/users/projects >>to >>certain zones/hypervisors/templates/etc. There's already a lot of >>granularity in CS, why not a little more? :-) >> >> >>On Thu, Mar 14, 2013 at 5:12 PM, Pranav Saxena >>wrote: >> >>> Well , you can always set up a private zone by unchecking the public >>> checkbox in the zone wizard . >>> >>> -----Original Message----- >>> From: Bryan Whitehead [mailto:driver@megahappy.net] >>> Sent: Friday, March 15, 2013 1:55 AM >>> To: cloudstack-users@incubator.apache.org >>> Subject: restricting users to a or Zone / Cluster >>> >>> I'd like to restrict users to a specific cluster in a zone but I don't >>>see >>> that as possible. Am I correct in this statement? >>> >>> Is there a way to restrict users to a specific Zone? >>> >>> Assuming I trust my users and just give them a specific zone to use - >>>when >>> I setup the zone can I just use the same secondary storage as others >>>zones >>> are do I need a new set of secondary storages as well? >>> >>> -Bryan >>> >> >> >> >>-- >>Regards, >> >>Kirk Jantzer >>c: (678) 561-5475 >