cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amogh Vasekar <>
Subject Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Date Sat, 15 Nov 2014 21:44:41 GMT
Question - What happens to the already existing VMs with entries in the
DB? Do we keep it NULL?


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)?
>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
>On Sat, Nov 15, 2014 at 3:28 AM, Rohit Yadav <>
>> 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
>> > 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
>> > 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
>> months, apart from ACS development Iıve been heavily involved in working
>> and supporting large production grade clouds and my ops experience is
>> 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
>> If one of the sysadmins (during their shift) removes some events, others
>> wonıt know. The events feature is perhaps good for event-driven
>> such as via AMQP/RabbitMQ and automated monitoring systems but perhaps
>> 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
>> account but has various users in it. For them it can be useful to list
>> and other resources by userid within their account. Since, they may not
>> 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 |
>> Blog: | Twitter: @_bhaisaab
>> Find out more about ShapeBlue and our range of CloudStack related
>> IaaS Cloud Design & Build<
>> CSForge ­ rapid IaaS deployment framework<>
>> CloudStack Consulting<>
>> CloudStack Software Engineering<
>> CloudStack Infrastructure Support<
>> CloudStack Bootcamp Training Courses<
>> This email and any attachments to it may be confidential and are
>> solely for the use of the individual to whom it is addressed. Any views
>> 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
>> 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
>> if you believe you have received this email in error. Shape Blue Ltd is
>> company incorporated in England & Wales. ShapeBlue Services India LLP
>>is a
>> company incorporated in India and is operated under license from Shape
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd
>> 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.*
>o: 303.746.7302
>Advancing the way the world uses the cloud

View raw message