t;>
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
UserAccount
Hi Chiradeep,
On 26-Nov-2014, at 4:32 am, Chiradeep Vittal
mailto:chiradeep.vit...@citrix.com>> wrote:
Instead of adding yet another parameter, could we look into adding a generic
filter as i
Hi Chiradeep,
> On 26-Nov-2014, at 4:32 am, Chiradeep Vittal
> wrote:
>
> Instead of adding yet another parameter, could we look into adding a generic
> filter as in:
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html
But there already are so many
<mailto:dev@cloudstack.apache.org>"
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, November 25, 2014 at 1:27 AM
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Major business logic refactor
s,
> Prachi
>
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Friday, November 21, 2014 11:13 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
> UserAccount
>
> H
Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: Friday, November 21, 2014 11:13 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
UserAccount
Hi Min, Prachi,
Thanks for your comments. I see your point, the use case is to list VMs for a
user_id
en [mailto:min.c...@citrix.com]
> Sent: Friday, November 21, 2014 8:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
> UserAccount
>
> If I understood correctly, (account, domainId) passed into deployVMCmd is
&g
014 8:16 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
UserAccount
If I understood correctly, (account, domainId) passed into deployVMCmd is used
for impersonation-like behavior, that is, caller is deploying a VM on behalf of
an ac
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Sunday, November 16, 2014 6:06 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Major business logic refactoring: Move from
>>Account to UserAccount
>>
t; Sent: Sunday, November 16, 2014 6:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
> UserAccount
>
> Only one table will be affected.
>
>> On 16-Nov-2014, at 3:14 am, Amogh Vasekar wrote:
>>
>>
Sunday, November 16, 2014 6:06 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
UserAccount
Only one table will be affected.
> On 16-Nov-2014, at 3:14 am, Amogh Vasekar wrote:
>
> Question - What happens to the already existing
Only one table will be affected.
> On 16-Nov-2014, at 3:14 am, Amogh Vasekar wrote:
>
> Question - What happens to the already existing VMs with entries in the
> DB? Do we keep it NULL?
NULL will be and not useful. I think it should be okay to have a db migration
path that sets user_id to the f
I would say, 'yes.'
On Saturday, November 15, 2014, Amogh Vasekar
wrote:
> Question - What happens to the already existing VMs with entries in the
> DB? Do we keep it NULL?
>
> Amogh
>
> On 11/15/14 8:41 AM, "Mike Tutkowski" > wrote:
>
> >Any idea on how many tables would be impacted by a decis
Question - What happens to the already existing VMs with entries in the
DB? Do we keep it NULL?
Amogh
On 11/15/14 8:41 AM, "Mike Tutkowski" wrote:
>Any idea on how many tables would be impacted by a decision for us to add
>the user ID directly into the tables (as opposed to relying on events)?
Any idea on how many tables would be impacted by a decision for us to add
the user ID directly into the tables (as opposed to relying on events)?
Since we already have a domain_id and an account_id in certain tables, it
might be better from a consistency standpoint to just add user_id to those
tab
Hi,
> On 15-Nov-2014, at 2:27 pm, Rajani Karuturi wrote:
>
> I agree with Nitin. It will be cleaner to use the events table. Since
> cloudstack is concerned only about account, it makes sense to have only
> that information which is the owner field(and remove account_id,
> domain_id).
> I think,
her users
> >>> in
> >>> that account will still be able to access that resource, as per CS IAM.
> >>> The userid will just provide an insight on which user in the account
> >>> created the resource.
> >>>
> >>> Thanks,
> >&
t; The ownership will still stay with the account - and so all other users
>>> in
>>> that account will still be able to access that resource, as per CS IAM.
>>> The userid will just provide an insight on which user in the account
>>> created the resource.
>>
as per CS IAM.
> >> The userid will just provide an insight on which user in the account
> >> created the resource.
> >>
> >> Thanks,
> >> Prachi
> >>
> >> -Original Message-
> >> From: Rohit Yadav [mailto:rohit.ya...@shapeblue
per CS IAM.
>> The userid will just provide an insight on which user in the account
>> created the resource.
>>
>> Thanks,
>> Prachi
>>
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Frid
M.
> The userid will just provide an insight on which user in the account
> created the resource.
>
> Thanks,
> Prachi
>
> -Original Message-
> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
> Sent: Friday, November 14, 2014 11:04 AM
> To: dev@cloudstack.apache.o
014 11:04 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
UserAccount
Min, you’re right I don’t propose to change the IAM model just some additional
data that notes who *actually* owns the resource (VM, volume, etc.) in an
account w
Also, yeah, it's a bit odd having domain_id, account_id, and user_id since
having user_id would allow you to retrieve the other information, but that
might be the easiest way to implement this (and we were already
semi-denormalized having both domain_id and account_id in these tables).
On Fri, Nov
Yeah, I assume you would use the column ID of the user table (as opposed to
the UUID of the given user), right?
On Fri, Nov 14, 2014 at 12:04 PM, Rohit Yadav
wrote:
> Min, you’re right I don’t propose to change the IAM model just some
> additional data that notes who *actually* owns the resource
Min, you’re right I don’t propose to change the IAM model just some additional
data that notes who *actually* owns the resource (VM, volume, etc.) in an
account which can be useful for sysadmins to list resource by userid etc.
I can understand the hesitation and the side effects such a refactori
Yes, we support going both directions, account <-> user.
Thanks
-min
On 11/14/14 10:59 AM, "Mike Tutkowski"
wrote:
>I didn't have access to the VM with my CS DB on it for a while, but I do
>now and checked the DB structure. I see the user table has a reference to
>the account table, so that's w
As for Min's question, I think Rohit is talking about keeping the
"account-ownership model" the same in CloudStack, but just providing
greater insight into what user specifically created or did whatever to a
given resource.
On Fri, Nov 14, 2014 at 11:59 AM, Mike Tutkowski <
mike.tutkow...@solidfir
I didn't have access to the VM with my CS DB on it for a while, but I do
now and checked the DB structure. I see the user table has a reference to
the account table, so that's what I was expecting and hoped to see.
On Fri, Nov 14, 2014 at 11:48 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wr
I haven't looked at the DB tables for this, but presumably there is a user
table like we have an account table and you can figure out what account a
given user is in? That would be OK then. I just wasn't sure if we only
allowed you to go from account to user, but not user to account in the DB.
On
Rohit, If I understood you correctly, the user_id column is only used for
listing resources to indicate which user is the real owner/creator of the
resource, but you don't want to change CloudStack account-level permission
model to user-level permission model, right? If so, the change will be
small
Can a username like "mike" be re-used in multiple accounts?
For example:
Acct1\mike
Acct2\mike
If so, the name "mike" would be insufficient to determine ownership of the
resource in some situations (unless it was fully qualified with its
account).
On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav
Hi Min,
Good to know. What do you propose we do moving forward. Do a refactoring run to
fix it or leave it as it is and perhaps add user_id columns to few resources
that are more useful for sysadmins such as vm_instance table.
> On 14-Nov-2014, at 11:49 pm, Min Chen wrote:
>
> Rohit,
>
> I thi
Rohit,
I think that the historic reason for this is that CloudStack is only
doing IAM access permission check on account level, user is only login
authentication purpose. That is why we will see that all our CloudStack
resource owner field is an account, since that is the only information
Agreed. Using userid could make isolation of resources more strictly. Which
is more suitable for public cloud,but more work have to be done I think.
On Nov 14, 2014 4:54 PM, "Rohit Yadav" wrote:
> Hi,
>
> All CloudStack DB entities (VM, storage, network etc.) have an owner field
> which is mostly
Hi,
All CloudStack DB entities (VM, storage, network etc.) have an owner field
which is mostly the account. An account can have multiple users so just by
looking at the resource (say VM) it’s not possible to make out which user in
the account (owner or account_id field in the db row of the enti
34 matches
Mail list logo
