Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of mike.tutkowski@solidfire.com
 designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D08BB146.4B013%nitin.mehta@citrix.com>
References: 
 <CACOnxCirORs1L0dTVnNUJN-EBgKgmj03WXG_WBGVu19Ok-2fUw@mail.gmail.com>
	<D08BB146.4B013%nitin.mehta@citrix.com>
Date: Fri, 14 Nov 2014 15:00:35 -0700
Message-ID: 
 <CACOnxCj2OxbwtA4YW6-vtS=7vxGXrqPwVVJ9f=nwB2C1neg9cQ@mail.gmail.com>
Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to
 UserAccount
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a113ce674328bc00507d8c26f

--001a113ce674328bc00507d8c26f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Do you think this info is sufficient, Rohit?

On Friday, November 14, 2014, Nitin Mehta <Nitin.Mehta@citrix.com> wrote:

> Mike - we already do that in the action events (event table) ? We log the
> user_id as well and so we always would know the user responsible for an
> action
> One thing better we can do there is have a resource_id column in the tabl=
e
> since the resource_id is currently embedded in the description at the
> moment.
> So instead of adding user_id for each resource we should do the change in
> the event table. Since all we want is a log of the actions.
>
> Thanks,
> -Nitin
>
> On 14/11/14 11:19 AM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> <javascript:;>>
> wrote:
>
> >Yeah, I think the idea is not to change ownership of the resource but to
> >be
> >better able to 'assign blame' for action x or y.
> >
> >On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle <Prachi.Damle@citrix.com
> <javascript:;>>
> >wrote:
> >
> >> Rohit,
> >>
> >> Just on note on:
> >> >>>Min, you=E2=80=99re right I don=E2=80=99t propose to change the IAM=
 model just some
> >> additional data that notes who *actually* owns the resource (VM, volum=
e,
> >> etc.) in an account which can be useful for sysadmins to list resource
> >>by
> >> userid etc.
> >>
> >> Adding 'user_id' column but not changing IAM model should be a small
> >> change and not causing any IAM side effects.
> >>
> >> But, it still won't really mean that that 'userid' 'owns' the resource=
.
> >> The ownership will still stay with the account - and so all other user=
s
> >>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,
> >> Prachi
> >>
> >> -----Original Message-----
> >> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com <javascript:;>]
> >> Sent: Friday, November 14, 2014 11:04 AM
> >> To: dev@cloudstack.apache.org <javascript:;>
> >> Subject: Re: [DISCUSS] Major business logic refactoring: Move from
> >>Account
> >> to UserAccount
> >>
> >> Min, you=E2=80=99re right I don=E2=80=99t propose to change the IAM mo=
del just some
> >> additional data that notes who *actually* owns the resource (VM, volum=
e,
> >> 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 refactorin=
g
> >> can produce, so I think the best would be to add user_id (uuid) column=
s
> >>and
> >> change only the API/query layer.
> >>
> >> Mike: I don=E2=80=99t propose to use user name but uuids so they are u=
nique. My
> >> concern was adding user_id column to say vm_instance table denormalize=
s
> >> data as that table already has domain_id and account_id in it and as
> >>Rajani
> >> suggested earlier those two are not needed as using user_id one can fi=
nd
> >> account_id and domain_id. I guess, the easiest way would be to just ad=
d
> >>an
> >> additional user_id column.
> >>
> >> Cheers.
> >>
> >> > On 15-Nov-2014, at 12:14 am, Min Chen <min.chen@citrix.com
> <javascript:;>> wrote:
> >> >
> >> > Rohit, If I understood you correctly, the user_id column is only use=
d
> >> > for listing resources to indicate which user is the real owner/creat=
or
> >> > of the resource, but you don't want to change CloudStack account-lev=
el
> >> > permission model to user-level permission model, right? If so, the
> >> > change will be smaller, maybe some Response classes, which should no=
t
> >> > involve too many business layer change. I will hesitate to really
> >> > change CloudStack IAM model though.
> >> >
> >> > Thanks
> >> > -min
> >> >
> >> > On 11/14/14 10:35 AM, "Rohit Yadav" <rohit.yadav@shapeblue.com
> <javascript:;>> wrote:
> >> >
> >> >> 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 <min.chen@citrix.com
> <javascript:;>> wrote:
> >> >>>
> >> >>> Rohit,
> >> >>>
> >> >>> I think that the historic reason for this is that CloudStack is on=
ly
> >> >>> 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 used for controlling whether you have some
> >> permissions to the resource.
> >> >>> Thanks
> >> >>> -min
> >> >>>
> >> >>> On 11/14/14 12:53 AM, "Rohit Yadav" <rohit.yadav@shapeblue.com
> <javascript:;>>
> >>wrote:
> >> >>>
> >> >>>> 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=C2=
=B9s not
> >> >>>> possible to make out which user in the account (owner or account_=
id
> >> >>>> field in the db row of the
> >> >>>> entity) created it. CloudStack users may want to know this
> >> >>>> information for at least entities such as VMs and Volumes.
> >> >>>>
> >> >>>> Historically, why is the account owner of an entity and not a use=
r?
> >> >>>> If user were the owner, we could easily get the account Id using
> >> >>>> the user Id.
> >> >>>>
> >> >>>> One solution to fix this problem is to refactor and replace Accou=
nt
> >> >>>> (interface) usage with UserAccount (interface) usage, fix the DAO
> >> >>>> and resource layer, and add columns in the schema. This gets us a=
ll
> >> >>>> the information we need to determine domainId, AccountId and Id
> >> >>>> (the user ID). Should we do it for all entities or just keep stat=
us
> >> >>>> quo (use account as owners), or just fix it on-demand basis for
> >> >>>> specific entities such as for user VMs [1].
> >> >>>>
> >> >>>> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908
> >> >>>>
> >> >>>> Regards,
> >> >>>> Rohit Yadav
> >> >>>> Software Architect, ShapeBlue
> >> >>>> M. +91 88 262 30892 | rohit.yadav@shapeblue.com <javascript:;>
> >> >>>> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Find out more about ShapeBlue and our range of CloudStack related
> >> >>>> services
> >> >>>>
> >> >>>> IaaS Cloud Design &
> >> >>>> Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> >> >>>> CSForge =C2=AD rapid IaaS deployment
> >> >>>> framework<http://shapeblue.com/csforge/>
> >> >>>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy=
/
> >
> >> >>>> CloudStack Software
> >> >>>> Engineering<http://shapeblue.com/cloudstack-software-engineering/=
>
> >> >>>> CloudStack Infrastructure
> >> >>>> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> >> >>>> CloudStack Bootcamp Training
> >> >>>> Courses<http://shapeblue.com/cloudstack-training/>
> >> >>>>
> >> >>>> This email and any attachments to it may be confidential and are
> >> >>>> intended solely for the use of the individual to whom it is
> >> >>>> addressed. Any views or opinions expressed are solely those of th=
e
> >> >>>> author and do not necessarily represent those of Shape Blue Ltd o=
r
> >> >>>> related companies. If you are not the intended recipient of this
> >> >>>> email, you must neither take any action based upon its contents,
> >> >>>> nor copy or show it to anyone.
> >> >>>> Please
> >> >>>> contact the sender if you believe you have received this email in
> >> >>>> error.
> >> >>>> Shape Blue Ltd is a company incorporated in England & Wales.
> >> >>>> ShapeBlue Services India LLP is a company incorporated in India a=
nd
> >> >>>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
> >> >>>> Consultoria Ltda is a company incorporated in Brasil and is
> >> >>>> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd =
is
> >> >>>> a company registered by The Republic of South Africa and is trade=
d
> >> >>>> under license from Shape Blue Ltd. ShapeBlue is a registered
> >> >>>> trademark.
> >> >>>
> >> >>
> >> >> Regards,
> >> >> Rohit Yadav
> >> >> Software Architect, ShapeBlue
> >> >> M. +91 88 262 30892 | rohit.yadav@shapeblue.com <javascript:;>
> >> >> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >> >>
> >> >>
> >> >>
> >> >> Find out more about ShapeBlue and our range of CloudStack related
> >> >> services
> >> >>
> >> >> IaaS Cloud Design &
> >> >> Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> >> >> CSForge =C2=AD rapid IaaS deployment
> >> >> framework<http://shapeblue.com/csforge/>
> >> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> >> >> CloudStack Software
> >> >> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> >> >> CloudStack Infrastructure
> >> >> Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> >> >> CloudStack Bootcamp Training
> >> >> Courses<http://shapeblue.com/cloudstack-training/>
> >> >>
> >> >> This email and any attachments to it may be confidential and are
> >> >> intended solely for the use of the individual to whom it is
> >> >> addressed. Any views or opinions expressed are solely those of the
> >> >> author and do not necessarily represent those of Shape Blue Ltd or
> >> >> related companies. If you are not the intended recipient of this
> >> >> email, you must neither take any action based upon its contents, no=
r
> >> >> copy or show it to anyone. Please contact the sender if you believe
> >>you
> >> have received this email in error.
> >> >> Shape Blue Ltd is a company incorporated in England & Wales.
> >> >> ShapeBlue Services India LLP is a company incorporated in India and
> >> >> is operated under license from Shape Blue Ltd. Shape Blue Brasil
> >> >> Consultoria Ltda is a company incorporated in Brasil and is operate=
d
> >> >> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a compan=
y
> >> >> registered by The Republic of South Africa and is traded under
> >> >> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
> >> >
> >>
> >> Regards,
> >> Rohit Yadav
> >> Software Architect, ShapeBlue
> >> M. +91 88 262 30892 | rohit.yadav@shapeblue.com <javascript:;>
> >> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >>
> >>
> >>
> >> Find out more about ShapeBlue and our range of CloudStack related
> >>services
> >>
> >> IaaS Cloud Design & Build<
> >> http://shapeblue.com/iaas-cloud-design-and-build//>
> >> CSForge =C2=AD rapid IaaS deployment framework<http://shapeblue.com/cs=
forge/
> >
> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> >> CloudStack Software Engineering<
> >> http://shapeblue.com/cloudstack-software-engineering/>
> >> CloudStack Infrastructure Support<
> >> http://shapeblue.com/cloudstack-infrastructure-support/>
> >> CloudStack Bootcamp Training Courses<
> >> http://shapeblue.com/cloudstack-training/>
> >>
> >> This email and any attachments to it may be confidential and are
> >>intended
> >> solely for the use of the individual to whom it is addressed. Any view=
s
> >>or
> >> opinions expressed are solely those of the author and do not necessari=
ly
> >> represent those of Shape Blue Ltd or related companies. If you are not
> >>the
> >> intended recipient of this email, you must neither take any action bas=
ed
> >> upon its contents, nor copy or show it to anyone. Please contact the
> >>sender
> >> if you believe you have received this email in error. Shape Blue Ltd i=
s
> >>a
> >> company incorporated in England & Wales. ShapeBlue Services India LLP
> >>is a
> >> company incorporated in India and is operated under license from Shape
> >>Blue
> >> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
> >>Brasil
> >> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Lt=
d
> >>is
> >> a company registered by The Republic of South Africa and is traded und=
er
> >> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
> >>
> >
> >
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkowski@solidfire.com <javascript:;>
> >o: 303.746.7302
> >Advancing the way the world uses the cloud
> ><http://solidfire.com/solution/overview/?video=3Dplay>*=E2=84=A2*
>
>

--=20
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=3Dplay>*=E2=84=A2*

--001a113ce674328bc00507d8c26f--