cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <raj...@apache.org>
Subject Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Date Sat, 15 Nov 2014 08:57:57 GMT
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, there is no auto purging or archival of events. Its the operator
who decides to delete the events. He can decide what he wants to
retain/delete.
If the resource id is added to events table, even for the sysadmin it would
be a simple join to get the required information.

~Rajani

On Sat, Nov 15, 2014 at 12:41 PM, Rohit Yadav <rohit.yadav@shapeblue.com>
wrote:

> Good discussion everyone.
>
> Nitin, I thought of using that as well but there are some issues using
> events;
>
> - events can be deleted
> - if some sysadmin is working with the db/tables, he would appreciate if
> all the information are with the resource (for VMs, the vm_instance table)
>
> Prachi, thanks I think I’ll go with just adding the column and make
> additions in the API/UI. I understand the ownership of the VM/resource will
> still be with the account, the purpose is mostly to support API query such
> as listing VMs of a userid etc.
>
> > On 15-Nov-2014, at 2:52 am, 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
> table
> > 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>
> > 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
> >
> >> wrote:
> >>
> >>> Rohit,
> >>>
> >>> Just on note on:
> >>>>>> 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.
> >>>
> >>> 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 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,
> >>> Prachi
> >>>
> >>> -----Original Message-----
> >>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> >>> Sent: Friday, November 14, 2014 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 which can be useful for sysadmins to list resource
> >>> by
> >>> userid etc.
> >>>
> >>> I can understand the hesitation and the side effects such a refactoring
> >>> can produce, so I think the best would be to add user_id (uuid) columns
> >>> and
> >>> change only the API/query layer.
> >>>
> >>> Mike: I don’t propose to use user name but uuids so they are unique. My
> >>> concern was adding user_id column to say vm_instance table denormalizes
> >>> 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
> find
> >>> account_id and domain_id. I guess, the easiest way would be to just add
> >>> an
> >>> additional user_id column.
> >>>
> >>> Cheers.
> >>>
> >>>> On 15-Nov-2014, at 12:14 am, Min Chen <min.chen@citrix.com> wrote:
> >>>>
> >>>> 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 smaller, maybe some Response classes, which should not
> >>>> 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>
> 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>
wrote:
> >>>>>>
> >>>>>> 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 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>
> >>> 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¹s 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 user?
> >>>>>>> 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
Account
> >>>>>>> (interface) usage with UserAccount (interface) usage, fix
the DAO
> >>>>>>> and resource layer, and add columns in the schema. This
gets us all
> >>>>>>> the information we need to determine domainId, AccountId
and Id
> >>>>>>> (the user ID). Should we do it for all entities or just
keep status
> >>>>>>> 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
> >>>>>>> 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 ­ 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,
> >>>>>>> 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 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 Ltd is
> >>>>>>> a company 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
> >>>>> 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 ­ 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,
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
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 Ltd is a company
> >>>>> 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
> >>> 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 ­ 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, 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 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 Ltd
> >>> is
> >>> a company registered by The Republic of South Africa and is traded
> under
> >>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
> >>>
> >>
> >>
> >>
> >> --
> >> *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=play>*™*
> >
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> 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 – 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, 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 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 Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message