[Gluster-devel] compound fop design first cut

[Ira Cooper]

Raghavendra Gowdappa <rgowdapp at redhat.com> writes:

> From what I can see, new compound ops will _evolve_ in future based on requirements unseen as of now.

Yes,

That is the one thing you can count on here ;)

The compounding architecture proposed here, scares me to be honest.

The complexity it can create is pretty immense.

I'm going to suggest a simpler scheme to you, there is no API provided,
but I think you'll see the idea, which is the key.  Then APIs and
whatnot can follow.

In the proposal today, if I want to compound op A and B, I have to write
compound_A_and_B basically.

That will create headaches for anyone who comes up with neat ideas :(.
Or needs to do longer and longer compounds.

I propose that we define a "compound op" that contains ops.

Within each op, there are fields that can be "inherited" from the
previous op, via use of a sentinel value.

Sentinel is -1, for all of these examples.

So:

LOOKUP (1, "foo") (Sets the gfid value to be picked up by compounding, 1
is the root directory, as a gfid, by convention.)
OPEN(-1, O_RDWR) (Uses the gfid value, sets the glfd compound value.)
WRITE(-1, "foo", 3) (Uses the glfd compound value.)
CLOSE(-1) (Uses the glfd compound value)

Note, that we can define what fields can take "sentinel" values, so
things like leases, locks etc, can all be handled properly.

The other trick is, if we return an error, we MUST stop the compound,
and return the rest of the return results as ECOMPOUND or some similar
value.  The actual thing that errored should return proper error codes.

Now, the cute thing about this is that a translator can look at a compound
stream, element by element, and decide what to do with it, or if you
need to break the stream and handle the compound semantics yourself or
what.

So this actually fits well with gluster's architecture, of being very
composable :).

I'm interested in your thoughts on where the edges of this proposal may
be, and if it meets your needs.

Thanks,

-Ira