Driver.insert() and Pools
Lex Linden
we're considering a few possible solutions. We'd love to hear feedback
on whether any of our ideas make sense and seem like good solutions.
The problem:
If I do A.insert(B), Driver.insert() will check to see if B has any
parents, and if it does, it refuses to insert B into A's contents. The
problem is, it's not always true that B having a parent already is an
error. Membership in Pools is denoted using insert(), so if you add a
host to a pool before adding it to a rack, adding it to the rack will fail.
I noticed this early on in learning Clusto, and I think it's a known
issue, though it's previously been perceived to be an edge case. Now
it's a full-on showstopper for us because of how we're using Pools. We
use a subclass of UniquePool to denote a host's state. We want to set a
host's state to "up" in the constructor for our server driver, so that
means adding it to the "up" pool. Because of insert()'s overzealous
check, this means that we can't insert the host into a chassis, because
our chassis driver gets its insert() from Driver.
Potential solutions:
1. Change Driver.insert(B) to only care about parents of B that aren't
Pools. This has the pretty distinct disadvantage of requiring Driver to
know about Pool, which seems to me to violate some fundamental notions
of OO.
2. Simply remove the check in Driver.insert(). We could decide that
it's the responsibility of subclases of Driver to enforce whether you
can insert an entity into it when it's already in another entity. An
example of this is BasicRack: it completely overrides insert() and does
its own checking to enforce that a server can't be in more than one rack
at a time. Notably, BasicRack does NOT care if a server is in some
other kind of entity's contents; it only checks for racks.
This one seems sensible to me, but it's risky because folks might depend
on the existing strict check in Driver.insert().
3. (my current favorite) Add a function to Driver, is_jealous_parent().
This function will tell you whether a given Driver prefers to be the
only parent of entities inserted into it. Change Driver.insert() to
enforce that you can't insert an entity into a jealous parent if the
entity is already in another jealous parent. Then override
is_jealous_parent() in Pool to return False.
This does essentially the same thing as #1, except it doesn't require
Driver to know about Pool. It also allows for the possibility that
things other than Pools might want to use the _contains relationship in
a non-exclusive way, but it retains the current behavior that unmodified
Drivers will enforce an exclusive parent relationship (not counting
Pools). It's a more OO-friendly concept, since it involves asking a
Driver subclass what its preference is, rather than hardcoding in rules
about specific classes.
What do you folks think about these ideas? Do you have any better ideas?
Jorge Gallegos
~kad
Jorge A Gallegos <k...@blegh.net>
http://kad.blegh.net