[Pulp-list] Fwd: CDS: gofer authentication
jortel at redhat.com
Fri Mar 18 19:49:42 UTC 2011
On 03/18/2011 02:28 PM, Jay Dobies wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>>> Well, not sure how to unit test this anyway. The plugin needs to run
>>> with gofer so it's not really a unit test. Seems like it needs to be
>>> tested in system tests? Does it make sense to require the CDS plugin be
>>> configured in gofer and require qpidd/goferd running for unit tests to
>>> pass? Let's discuss.
> Can we call into the gofer_cds_plugin.py module without going through
> gofer? It might be a bit tricky with how the config is loaded, but
> otherwise the code isn't too tightly coupled with gofer at all.
Some of the "plugin-ness" will be a problem. Ex:
>>> plugin = Plugin.find(__name__)
>>> config = plugin.cfg()
The find() will return None if the module is not instantiated with the gofer plugin context.
Has permissions issues not running as root.
If it makes possible (and makes sense) to call methods on CdsGoferReceiver within the unit
test environment, I'd suggest splitting the CdsGoferReceiver into it's own module and
importing it in to the gofer_cds_plugin plugin.py. Then, run some unit test on that.
> least, the Secret read/write/delete can be tested without needing a
> running gofer.
>>> Well, since the modules are only loaded once, implementing as functions
>>> and module variables presents the same headaches for testing.
> Agreed, module level variables would need to be reset between
> invocations. Ideally we can skip them entirely and just pass in what a
> method needs when it runs.
>>> I view
>>> the "secret" as an persistent object with read/write/delete operations.
> Makes sense. I liked the model you used in RepoFile using the same approach.
>>> Making it a singleton was really an after thought for performance.
>>> Making it an object was a matter of philosophy (nope, not going to open
>>> up this debate here).
>>> Is there a benefit beyond those well-known about
>>> OO programming? No. If there needs to be, then 95% of our classes in
>>> pulp should not have been classes. That said, I'd be glad to rewrite as
>>> functions and module variables (it would take about 10 min).
> Wasn't trying to bring up an OO relevancy discussion. To be clear, I
> didn't mean to imply it was wrong, was just asking if there was a
> benefit (if you hadn't used an object, chances are I'd have asked about
> why you didn't; boils down to curiosity more than anything).
> My only concern is that it's testable. Otherwise it's just a stylistic
>>>  Actually, the more I think about it, making it a singleton and
>>> caching the secret really wasn't warranted. Plus, it would be nice to
>>> be able to reset the secret without bouncing gofer.
> With the rate at which the secret will be needed, I agree, the caching
> won't get us much. And that's a good point about needing to bounce gofer.
> - --
> Jay Dobies
> RHCE# 805008743336126
> Freenode: jdob
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
> Pulp-list mailing list
> Pulp-list at redhat.com
More information about the Pulp-list