On Mon, Feb 1, 2010 at 7:04 PM, Lucas Meneghel Rodrigues l...@redhat.com
wrote:
Replace all functions that evaluate md5 and sha1 hexdigests
with the function utils.hash().
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
client/tests/kvm/kvm_utils.py | 16 +++-
Instead of wrapping all the calls in try-except blocks, maybe it would
make more sense to add a couple of utility functions to the common_lib
utils.py that do it for you? I'm just picturing something like:
def md5(bytes):
try:
import hashlib
return
Assuming you do this, it also might make more sense to call them
md5_digest and sha1_digest, or something a little less ambiguous than
just md5 and sha1; clashing with the stdlib module name is probably a
bad idea.
-- John
On Fri, Jan 29, 2010 at 7:25 AM, John Admanski jadman...@google.com wrote
This looks good to me.
-- John
On Tue, Dec 1, 2009 at 2:37 PM, Lucas Meneghel Rodrigues l...@redhat.com
wrote:
When the client was made configurable through
global_config.ini, the scenario developer
checking out client directory only wasn't
considered, and an exception will be thrown
due
Almost there. Just a couple of minor things.
On Tue, Nov 17, 2009 at 5:04 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
In order to make it possible the autotest client to use the
global_config.ini configuration files:
* Modified global_config.py to support verifying if the
Looks good.
On Wed, Nov 18, 2009 at 8:09 AM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
In order to make it possible the autotest client to use the
global_config.ini configuration files:
* Modified global_config.py to support verifying if the
configuration file is under autotest's
On Tue, Nov 17, 2009 at 9:40 AM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
In order to make it possible the autotest client to use the
global_config.ini configuration files:
* Modified global_config.py to support verifying if the
configuration file is under autotest's root directory,
I don't think this is sufficient. It works in the simple cases, but
what about when you're using packaging to install the clients and not
rsync? I guess that still technically works...assuming that you
rebuild the client package whenever you need to change the .ini.
While not strictly wrong, this
Maybe instead we should just drop libdir entirely. I don't see
anything that uses it. And if I was going to use that name, I can
think of more interesting things to do with it than to point it at the
common lib.
-- John
On Wed, Nov 11, 2009 at 3:30 AM, Lucas Meneghel Rodrigues
l...@redhat.com
I'm going to mail out a patch later this afternoon that just strips
out job.libdir entirely.
-- John
On Wed, Nov 11, 2009 at 7:35 AM, John Admanski jadman...@google.com wrote:
Maybe instead we should just drop libdir entirely. I don't see
anything that uses it. And if I was going to use
On Wed, Nov 11, 2009 at 9:16 AM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
On Wed, 2009-11-11 at 07:32 -0800, John Admanski wrote:
I don't think this is sufficient. It works in the simple cases, but
what about when you're using packaging to install the clients and not
rsync? I guess
On Wed, Nov 11, 2009 at 9:35 AM, Martin Bligh mbl...@google.com wrote:
I thought about it a bit more:
Maybe a better approach would be to have the global_config module find
the ini file in job.autodir (so on a client it would show up in the
client/ dir, and on the server in the true top-level
Okay. I mailed out a patch to do this. If this is causing problems you
can do a quick review and commit it.
-- John
On Wed, Nov 11, 2009 at 7:54 AM, John Admanski jadman...@google.com wrote:
I'm going to mail out a patch later this afternoon that just strips
out job.libdir entirely.
-- John
Will this code actually work on a standalone client job? I'm not sure
we've ever used global_config stuff outside of the server (despite the
fact that the code lives in the common_lib).
-- John
On Thu, Nov 5, 2009 at 12:23 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
Right now autotest
Here's what I had in mind.
-- John
On Mon, Oct 5, 2009 at 11:20 AM, John Admanski jadman...@google.com wrote:
After some investigation and irc chat, it has become clear that this
misbehaving chunk of code in _autotest_logging_handle_error is in fact an
error; the patch that was applied
I do have one major concern; other than that, it looks pretty good to
me. I think Michael's suggestions are generally reasonable (although
I'm fine with the code as it is as well). But if you do use his
suggested get_results_dir_list please use pid in pid_dir_dict and
not
Sorry, I haven't had time to take a look yet. Been busy. :(
I'll try and get in a review some time today.
-- John
On Sun, Sep 13, 2009 at 9:40 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
Hi John, do you think the code looks good enough for inclusion?
On Tue, Sep 8, 2009 at 10:53 AM,
17 matches
Mail list logo
