[PATCH] dynamic providers

Jim Meyering jim at meyering.net
Fri Dec 17 21:24:49 UTC 2010


Jeff Darcy wrote:
> 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.

Not a good reason, but I was reluctant to modify the expected
output in each provider-listing test.
Another non-reason: adding a primary=yes|no attribute
would mean that we'd have to either accept existing files
where the first provider gets an implicit primary=yes
or break backwards compatibility.

>> 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?

Yes.  with "as is" meaning "now that we add and remove providers"

>> 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.

Exactly.
Using it for output is fine.
My goal is to remove duplication on the (now) two separate provider
input validation paths.

>> 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.

I'm not worried about channel security (while it's mere http now,
that's slated to change) but rather about the commands that
people would be encouraged to use to set/change credentials:

    curl -d provider=primary -d username=v -d password=q \
      http://localhost:9091/_providers

I'd rather not expose credentials on the command line.
However, there's probably a way to make curl or some
other tool read key/value pairs from a file.
I'll look into that if no one beats me to it.

> 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