----- Original Message ----- > From: "Yair Zaslavsky" <yzasl...@redhat.com> > To: "Eli Mesika" <emes...@redhat.com> > Cc: "Sahina Bose" <sab...@redhat.com>, "engine-devel" <engine-devel@ovirt.org> > Sent: Sunday, September 8, 2013 10:55:48 AM > Subject: Re: [Engine-devel] Storing command parameters > > > > ----- Original Message ----- > > From: "Eli Mesika" <emes...@redhat.com> > > To: "Sahina Bose" <sab...@redhat.com> > > Cc: "Yair Zaslavsky" <yzasl...@redhat.com>, "engine-devel" > > <engine-devel@ovirt.org> > > Sent: Sunday, September 8, 2013 10:44:43 AM > > Subject: Re: [Engine-devel] Storing command parameters > > > > > > > > ----- Original Message ----- > > > From: "Sahina Bose" <sab...@redhat.com> > > > To: "Yair Zaslavsky" <yzasl...@redhat.com>, "engine-devel" > > > <engine-devel@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@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
