[Pulp-list] Fwd: CDS: gofer authentication

[Jay Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/18/2011 03:49 PM, Jeff Ortel wrote:
> 
> 
> On 03/18/2011 02:28 PM, Jay Dobies wrote:
>>>>> 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.
> 
>> Also:
> 
>>>>> log.addHandler(logging.FileHandler('/var/log/pulp-cds/gofer.log'))

That's just sloppy on my part, it should have been a config value.

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

That's a pretty good approach. The gofer plugin is simply an adapter
between the gofer call and the logic module, so that way the logic stuff
isn't so coupled to the gofer framework.

The grinder calls in there would need to be mocked out too. Still, I
think it's a worthwhile investment (eventually, not saying we have time
for all that now with the RHUI 2.0 deadlines) given that we really don't
want to not delete a repo from the CDS when the user thinks it's
undeployed. That'd be bad  :)

>> At very
> least, the Secret read/write/delete can be tested without needing a
> running gofer.
> 
>> Agreed.
> 
> 
>>>>> 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.
> 
> Gotcha.
> 
>>>>> 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
> thing.
> 
>>>>> [1] 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.
> 
> 
> 
> 
>>
_______________________________________________
Pulp-list mailing list
Pulp-list at redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list

> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


- -- 
Jay Dobies
RHCE# 805008743336126
Freenode: jdob
http://pulpproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNg7njAAoJEOMmcTqOSQHC908H/iJC2SQbk9xpF8BiFMZIsY0u
JYbrWnQ2uJ52SXzS7L5iuA4CB1IFg/MSgA9lWnkDBFbGAAF4ntS83lYvuevw8/TD
HbDN16ugYkOkDJAu9pn1Yh+QTeSd0vFSnLnqcJy4qECz9GrxSaypqEwjRsWyo9lw
5d1aiGac7V0qZ3DkFty+7acfnn94IYlRqz3hNlj1bEcPXqUmmx2UfOW9mHbK6Ll4
20+0RMs4BD8s1Ld8eQ0Xuq7m71+TFPCXbzA58Z9Zlvjwab76bb6sz/SdQBiiIEoK
LDfgFfTqtj0N3u43uqNe610Cnkk5t5nNLoM8ch4p6hJUJli98MqT7WUkQUDzrCI=
=vrvc
-----END PGP SIGNATURE-----