cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Date Sat, 15 Nov 2014 22:54:46 GMT
I would say, 'yes.'

On Saturday, November 15, 2014, Amogh Vasekar <amogh.vasekar@citrix.com>
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" <mike.tutkowski@solidfire.com
> <javascript:;>> 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)?
> >
> >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.yadav@shapeblue.com
> <javascript:;>>
> >wrote:
> >
> >> Hi,
> >>
> >>
> >> > On 15-Nov-2014, at 2:27 pm, Rajani Karuturi <rajani@apache.org
> <javascript:;>> 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.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 ­ 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 <javascript:;>
> >o: 303.746.7302
> >Advancing the way the world uses the cloud
> ><http://solidfire.com/solution/overview/?video=play>* *
>
>

-- 
*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>*™*

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