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
tables, as well (I know it is a bit de-normalized that way, but we already
have that situation with having both domain_id and account_id in these
tables).

On Sat, Nov 15, 2014 at 3:28 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> Hi,
>
>
> > On 15-Nov-2014, at 2:27 pm, Rajani Karuturi <raj...@apache.org> 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, 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.
>
> I don’t think it’s a pragmatic solution, let me explain — In the past few
> months, apart from ACS development I’ve been heavily involved in working
> and supporting large production grade clouds and my ops experience is that
> there are usually couple of sysadmins (usually working in shifts) and we
> cannot really rely on the assumption that events are only cleared by one
> operator or that there is culture of knowledge sharing of all the actions.
> If one of the sysadmins (during their shift) removes some events, others
> won’t know. The events feature is perhaps good for event-driven consumption
> such as via AMQP/RabbitMQ and automated monitoring systems but perhaps not
> best suited for humans all the time (yet).
>
> The other use case is of a large org who are consumer of a (rented)
> CloudStack cloud among other tenants, the whole team of an org shares the
> account but has various users in it. For them it can be useful to list vms
> and other resources by userid within their account. Since, they may not be
> admin (renting cloud?) the pragmatic solution would be to have such
> metadata somewhere easily slice-able and dice-able using APIs.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@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.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Reply via email to