[Pulp-list] Fwd: CDS: gofer authentication
jason.dobies at redhat.com
Fri Mar 18 19:28:37 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
>> 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. At very
least, the Secret read/write/delete can be tested without needing a
>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Pulp-list