New Beaker API quirks
by Don Zickus
Hi Dan,
I have been enjoying the ease to code against the new Beaker API. The
GET, POST, PUSH stuff keeps things really simple. But during my testing I
noticed a few quirks that Bill P. suggested I email you about for your
opinion.
- When I POST/PUT to a url, if the url has an extra '/' in the path, like
/recipes/(recipe_id)/tasks/(task_id)//status
the command gets rejected. Not sure if that is an http thing or a server
thing. Not to much of a problem, just forces me to clean up my code
(which is good!). Just thought I would mention it.
- when I PUT a zero length file to the server, it fails with a 400 code.
Now I should be filtering those (and will now). But it did take me an
hour before I realized that of my list of files, the rejected ones were of
zero length. Again could be on purpose, not sure.
- Because the server does not have a mechanism to 'push' and abort the
client (other than power off), the client could still be running and
trying to pushing results back to the server.
a POST of a task_result gave me an 'Internal Server Error 500'. Will
that be the expected response? I can trap for that and abort the client.
PUT of logs is still allowed even though the task aborted on the server
side. Bill thought that should be fixed. Though I am not sure what the
expectations are.
That's it so far.
Thanks,
Don
10 years, 7 months
status of inventory using lshw?
by Bill Peck
Hello,
I know some work was done to convert from using Smolt to Lshw, but I
don't see anything committed in the latest develop branch and I can't
find a branch with lshw in the name. I'm anxious to see this work
completed, if there is a branch being worked on, I can help contribute
if needed. This work is becoming necessary since some architectures can
only install Fedora 18 or newer and smolt is no longer available.
Thanks!
10 years, 8 months
Notify Job owner before triggering test system scraping
by Amit Saha
While trying to find the real reason for BZ: 839601 [1] (and other such bugs where reproducing the bug is
non-trivial), Marian Csontos and myself realized that getting access to the test system before it was EWD-ed
would have been quite useful. Considering that Beaker users are mostly proficient in Linux system-admin style
tasks, it would give them the opportunity to try certain basic things such as network connectivity, checking
/var/log/messages (and others) to understand and perhaps even single out the reason for being EWD-ed- whether it was
a call to extend the watchdog failing, the network went down, or whatever may be the reason.
Marian has filed the RFE [2] to this end. I think this may be good to have. We should also have a maximum allowed
timeout value to prevent abuse, of course and a list of things to try, log files to save, etc, etc.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=839601
[2] https://bugzilla.redhat.com/show_bug.cgi?id=923587
Thoughts/comments?
-Amit.
--
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.
10 years, 8 months
[RFC PATCH 0/5] beaker harness support for autotest
by Don Zickus
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.
Feel free to direct all questions to me and I will do my best to remember what
Jan and myself did.
Don Zickus (5):
cmdparser: add new command bootstrap
harness: new beaker harness
harness: support for beaker's xml
harness: support beaker proxy protocol
harness: beaker utility classes
client/at_utils.py | 74 +++++++++
client/autotest_local.py | 2 +-
client/bkr_proxy.py | 337 ++++++++++++++++++++++++++++++++++++++
client/bkr_xml.py | 144 +++++++++++++++++
client/cmdparser.py | 78 ++++++++--
client/harness_beaker.py | 399 ++++++++++++++++++++++++++++++++++++++++++++++
client/shared/error.py | 4 +
7 files changed, 1027 insertions(+), 11 deletions(-)
create mode 100644 client/at_utils.py
create mode 100644 client/bkr_proxy.py
create mode 100644 client/bkr_xml.py
create mode 100644 client/harness_beaker.py
10 years, 9 months
Limited availability - March 12 -> April 8th
by Nick Coghlan
Just a heads up that my availability is going to be sketchy for the next
few weeks as I head to PyCon US for a couple of weeks and then take some
PTO after Easter.
There shouldn't be anything that needs to be delayed waiting on my input
in that time, but if there is I'll be trying to make sure to clear work
email at least once a day during the conference (which runs until March
21st). Once the conference is over and I'm travelling home or on PTO, my
personal email (ncoghlan@ Google's well known email service) is your
best bet for getting hold of me.
I'll likely also be on IRC during the conference sprints (March 18-21),
but in the US Pacific Daylight Savings Time time zone.
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
10 years, 9 months
System pools design proposal updated
by Nick Coghlan
I have updated the draft design proposal for Beaker 1.1's System Pools
concept:
http://beaker-project.org/dev/proposals/system-pools.html#proposal-system...
There aren't any major changes to the design itself, the updates are
mostly editorial:
- clarify that pools have owning groups, and that it is the owners of
those groups that can change the pool policy
- give some tentative names to the proposed permissions (mostly for use
in the CLI)
- rename the "pool-manage" subcommand to "pool-modify"
- added an example of using autopick
- broke up the UI proposal section with additional heading
- added migration and deferred features sections
I also added a draft design proposal to follow on a release or two after
the initial system pools release:
http://beaker-project.org/dev/proposals/implicit-system-pools.html#propos...
The new proposal covers the automatic creation of implicit system pools
associated with each user group. It's just a rough sketch at the moment,
but I think we're going to see some of our users asking for it after the
explicit system pools feature lands. We may also need some elements from
it anyway, in order to handle the problem of migrating existing
system<->group associations to the pool model.
This is as much as I plan to flesh these out at this point - they're
useful things for us to keep in mind as we work on more near term stuff
for 0.12 and 1.0, but the details are inevitably going to shift based on
the feedback we receive on those earlier releases.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
10 years, 9 months
Fwd: New list for QA development: qa-devel
by Bill Peck
Passing this along in case anyone here is interested in subscribing.
-------- Original Message --------
Subject: New list for QA development: qa-devel
Date: Wed, 06 Mar 2013 18:17:55 -0800
From: Adam Williamson <awilliam(a)redhat.com>
Reply-To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
Organization: Red Hat
To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
It occurred to me that it's just possible someone might find this
interesting but not be subscribed to test@, so I thought I'd mention it
here.
We have recently created the new list 'qa-devel at
lists.fedoraproject.org' for discussion of QA tool development. It will
subsume the autoqa-devel list, but it also covers other tools being
developed by and mostly for the QA team, including the blocker bug
webapp and the blocker bug submission tool. So...if it interests
you...check it out :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10 years, 9 months
Draft release notes page and backfilled release notes for 0.11!
by Nick Coghlan
The draft release notes page for Beaker 0.12 has been updated to reflect
the current status of the release:
http://beaker-project.org/docs-develop/whats-new/index.html
To better assess the readability of the new release notes page, Dan
Callaghan has backfilled a set of release notes for 0.11. When we create
the beaker-0.12 maintenance branch, any changes in the "Unreleased
Changes" section will be edited down into a "What's New in Beaker 0.12?"
document aimed primarily at Beaker users and an "Upgrading to Beaker
0.12" document aimed primarily at administrators of a Beaker instance.
We're definitely interested in feedback on the format of these notes,
since Beaker 0.12 will be the first release to include notes that are
more than just a list of Bugzilla references.
On the developer side, Dan has also created an easier to manage system
where all new release notes are placed in a directory called "next" and
appear in the "Unreleased Changes" section of the release notes page.
This means if a change isn't ready for a given release, we can easily
slide it into the next release without needing to change the destination
directory of the associated release note.
Regards,
Nick.
P.S. We're aware that the draft docs for 0.12 currently still claim to
be for Beaker 0.11. Unfortunately, this is a quirk of our current
release process which isn't particularly easy to change. It annoys us
too, but it's not clear when we'll get it fixed - until it is, the "in
development" docs will claim to be for the previous release (aside from
the big warning at the top of each page).
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
10 years, 9 months
Enhanced User Groups design proposal updated
by Nick Coghlan
The Enhanced User Groups design proposal has been updated to incorporate
feedback received (mostly offlist, alas) on the previous iteration.
The major changes from the previous version are:
* Added a "Description" field to groups. This is primarily so each group
can include instructions on how to request addition to the group (since
Beaker won't initially be offering the ability for users to request
membership of groups)
* Added the ability to add group members that can *only* submit jobs
(without being able to modify that group's jobs). This better supports
an approach where a single automated service submits jobs on behalf of
multiple users and groups.
* Added a missing use case covering modification of a group's details
(the display name and description)
* Changed the name of the "group-manage" subcommand to "group-modify"
* Clarified several limitations of LDAP-based groups
* Documented the planned upgrade strategy (i.e. all existing groups are
considered to allow shared job management, with no owners. The
administrators of the Beaker installation will need to explicitly grant
a member ownership access in order to enable self-management of an
existing group.
Current version of the proposal:
http://beaker-project.org/dev/proposals/enhanced-user-groups.html
All changes from previous version:
http://git.beaker-project.org/cgit/beaker-project.org/commit/?id=98a0014b...
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
10 years, 9 months