On 03/12/2013 11:07 AM, Don Zickus wrote:
On Tue, Mar 12, 2013 at 12:59:14AM -0300, Lucas Meneghel Rodrigues wrote:
On Fri, Mar 8, 2013 at 3:16 PM, Don Zickus <[email protected]> wrote:
Hi Folks,
Recently a bunch of autotest and beaker folks have been discussing how to get
an autotest client working under beaker (namely Nick, Dan, Bill from beaker and
Lucas, Cleber, Ademar from autotest).
A long time ago Jan Stancek whipped up some code to do that based on some
discussions we both had. I later modified a bunch of his code and came up with
these patches.
I lasted touched these patches back in August 2012. I never finished polishing
them off or completed my testing due to other Red Hat obligations.
I am presenting these patches as a starting point for discussions as to how Jan
and myself solved various problems. They are very much 'beta' patches (there
has been a lot of testing so they were stable at one point).
Unfortunately, I don't remember how all the pieces worked so instead of
breaking the files into digestable chunks, I am just submitting whole files as
new (well the first patch is a 'patch').
I rebased them on to the latest autotest/HEAD as of today. Though I didn't
test them.
Please be kind. I am cross-posting to various mailing lists to let anyone
interested participate.
The end goal is to have autotest client work with the beaker server smoothly.
This would allow various autotest projects to leverage the
provisioning/inventorying mechanisms provided by beaker for various labs.
These patches look like a great start. There are some coding style
inadequacies, that will need to be addressed, mainly:
Thanks. I have to modify them to the new beaker API, but my most
important piece is the bootstrapping hack.
If that is a no-go, then I have to come up with another solution first.
Sure. Having some harnesses to have a bootstrap stage is fine. If
anything, bootstrap methods could be implemented in the other harnesses
as no-ops, just for the sake of uniformity.
So we may proceeed with this idea. In fact, I like the fact it is simple
and doesn't require a daemon running.
1) Fix usage of CamelCase. The only exception are class names.
My python-foo is so limited, I don't know what CamelCase is. :-(
CamelCase is naming classes and methods with a mixture of
uppercase/lowercase characters. In autotest, it is fine for class names,
but not for methods, attributes and other general variable names. For
those, all_lowercase_with_underscores is recommended.
2) Docstring format
Example:
def foo(param1, param2):
"""
Summary line.
Long description of method foo.
@param param1: A thing called param1 that is used for a bunch of stuff
that has methods bar() and baz() which raise SpamError if
something goes awry.
@return a list of integers describing changes in a source tree
...
"""
3) Use of old style classes
Also something simple. Instead of doing
class Foo:
pass
Do instead
class Foo(object):
pass
Shouldn't affect the outcome (although I've seen cases where it brings a
quirk or two) and makes usage of super() safer.
More things I don't know what they are. :-(
There are other small issues, mostly related to PEP8 here and there.
That all said, I'm going patch by patch checking the general goals,
and running some static checking to shake up small bugs.
And PEP8 is also another new thing for me. :-(
PEP8 is a sort of base reference for python coding style.
http://www.python.org/dev/peps/pep-0008/
The autotest code style inherits from it, and the differences are
outlined in the coding style document:
https://github.com/autotest/autotest/blob/master/CODING_STYLE
I offer to pick up your patches, fix all those inadequacies and small
bugs, then have a branch ready from where you can pull and resume work
from there. Does that sound good to you?
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
