[Engine-devel] Storing command parameters

[Eli Mesika]

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Sahina Bose" <sabose at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, September 8, 2013 10:55:48 AM
> Subject: Re: [Engine-devel] Storing command parameters
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Sahina Bose" <sabose at redhat.com>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Sunday, September 8, 2013 10:44:43 AM
> > Subject: Re: [Engine-devel] Storing command parameters
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sahina Bose" <sabose at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Tuesday, September 3, 2013 4:16:53 PM
> > > Subject: [Engine-devel] Storing command parameters
> > > 
> > > Hi all,
> > > 
> > > As part of the gluster volume asynchronous tasks, we ran into a
> > > requirement wherein when we start a command, we need to remember the
> > > parameters that the command was started with.
> > > 
> > > Is there any infrastructure available to do this, or should we build
> > > something?
> > 
> > Hi Sahina
> > There is such a mechanism , it is called Compensation
> > You can look at backend:compensate to see how it is used to rollback
> > commands
> > in the case of failure.
> > 
> > Yair can elaborate & help on that since he is the owner of this code
> 
> Eli, I think using compensation here is an abuse.

Sure, I just meant to see what is done there as a code sample

> Compensation is used to take snapshots of entities, and snapshots only
> classes THAT ARE (a plural of the "IS A" inheritance rule :) ) business
> entities.
> The closest thing we have today to what Sahina needs, is IMHO async_tasks
> table which have command_id and parameters stored.
> However, storing command parameters at tasks table is somewhat awkward (yes,
> I know we're doing it until this very moment) and we should revisit this,
> and have a real
> table to store commands and associated parameters.

So, since Gluster has there own async tasks , do you recommend to have a separate table for their tasks ???
I think that they can use the current one , maybe we need additional column in async_tasks to distinguish between Gluster & our tasks ...


> 
> Yair
> 
> 
> > 
> > 
> > > 
> > > thanks
> > > sahina
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
>