[PATCH] dynamic providers

Jeff Darcy jdarcy at redhat.com
Fri Dec 17 20:50:21 UTC 2010


On 12/17/2010 02:51 PM, Jim Meyering wrote:
> I've included below a 7-cset series that allows providers to
> be added and removed dynamically.  This shows you what the interface
> will look like.
> 
> To illustrate, here's part of the t/basic test:
> 
> [snip]

The interface looks mostly reasonable.  Is there any particular
rationale for having special entrypoints to deal with primary-ness
instead of just having primary=yes|no or role=primary|secondary as
attributes specified alongside host/port/etc.?  I'm not advocating for a
particular treatment; "had to pick one" is fine, but I'm curious whether
there's some other nuance involved that I'm not aware of.

> There are caveats: to be done properly, this will
> require reference-counting each provider and actually freeing one
> only when we're sure no other thread is using it.
> Likewise, the provider hash table will need protection
> against corruption via concurrent modification.

Does that imply that the code as-is (which I'll look at in a moment)
lacks these protections?  If so, does that mean it would be vulnerable
to such conflicts?

> At first, I hoped to remove json support altogether,

I assume you mean the JSON config file, not JSON as an output-format
alternative to XML.

> but if we do that, the only way to specify the providers
> required for initial operation would be via the command line
> use of curl.  Obviously, we know we don't want to expose provider
> credentials that way.  Of course, if there's a safe json-free way to
> send provider-defining information to iwhd, then I'd love to
> hear it and will gladly remove json support altogether.

Some piece of code somewhere has to parse the config file and feed it
into the guts of iwhd.  Whether that's a part of iwhd's internal startup
code or some other script we also write which feeds the providers in
through the HTTP interface doesn't seem like the biggest issue here.  We
can secure that channel as much as we want so that the credentials etc.
are no more at risk in flight than they already are in on disk, and I
think it's worthwhile to avoid the very real maintainability concern of
duplicating functionality between initial-config and dynamic-config
code.  The other issue seems to be whether we're comfortable using JSON
as config-file format.  If we're not, the configuration is currently
simple enough (simpler than the replication-policy syntax which we
already parse) that we have plenty of alternatives.  I wouldn't object.
 The use of JSON was merely a convenience, and if the dependencies
involved make it less convenient then jettisoning it seems like the
right thing to do.


More information about the iwhd-devel mailing list