Selenium Error and Firefox version
by Amit Saha
If you are using Firefox 22, you may see: "The error message is: Value does not implement interface Event"
error messages.
The solution is to downgrade to 21. sigh.
Remove Firefox: #yum -y remove firefox xulrunner
Get the packages corresponding to 21 for both, and install them.
--
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.
10 years, 1 month
Test framework for lshw
by Amit Saha
As noted in [1], some work needs to be done before we can start writing tests for lshw.
Currently, lshw's functionality can be roughly explained as follows:
- the file src/lshw.cc examines all the command line arguments
- After setting up variables determining the information that is going to be
printed, the function scan_system() is called, which is defined in src/core/main.cc
- This function, depending on what information has been requested for, calls
functions defined in various files - such as cpuinfo.cc for CPU info, mem.cc for memory
information and so on which return the requested info.
- These files read their data from /proc and /sys and then return the data after filling those
in the appropriate data structure. As mentioned in [1], not all reads their data from procfs
and sys. For example, those which fetch disk information do it via ioctl() calls. However, as of
now, we may ignore the disk related functionality of lshw, since we use libparted for that now.
So, we want that instead of reading these data from the live systems, when run as part
of the test suite, lshw should ready them from our test data - a snapshot of relevant files from
procfs and sysfs.
One approach that I can think of is:
- Add an extra option to lshw -s specifying the location of the snapshot
- When this is set, we can set an environment variable to point
to the location of the snapshot. In all the files where the information
is read from the file systems, before opening the file, we check
for this environment variable, and if it exists, we read the files from there instead.
And of course, matching the expected output, etc follows after that.
Would be interested in any feedback.
Thanks,
Amit.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=986157
--
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.
10 years, 1 month
Beaker 0.14.0 available for testing
by Nick Coghlan
Hi folks,
We're trying a slightly different release process for Beaker 0.14 from
what we have done in the past.
Historically, we've waited until Red Hat's internal acceptance testing
was completed before making a new release available on the website,
which can end up delaying the public release, even if our acceptance
testing doesn't find any additional issues.
For this and future releases, we're shifting the order around so that we
update the public testing repos on beaker-project.org *first*, and then
do our acceptance testing based on those RPMs. Our internal acceptance
testing will then drive the move to the stable repos.
Accordingly, each release will have an "available for testing"
announcement when the testing repos are updated, hopefully followed by a
release announcement a week or so later.
In the case of 0.14, we already know there will be a 0.14.1 release due
to a critical regression when attempting to send notification emails
from the scheduling daemon (see
https://bugzilla.redhat.com/show_bug.cgi?id=990408).
===========================
On behalf of the Beaker development team, I'm pleased to announce that
Beaker v0.14.0 is now available for testing from beaker-project.org.
If using the Beaker-provided repo files, the testing repos can be
enabled using the following yum options:
--enablerepo=beaker-client-testing
--enablerepo=beaker-server-testing
Alternatively, create appropriate repo definitions for the following URLs:
http://beaker-project.org/yum/client-testing/
http://beaker-project.org/yum/server-testing/
The documentation for the upcoming release is available at:
http://beaker-project.org/docs-release-0.14/
In this release, we have finalised the "Enhanced User Groups" design
proposal [1], adding the ability for users to nominate "submission
delegates": other users that have the ability to submit jobs on their
behalf. The primary intended use for this feature is with external
automated systems, such as the recently published Jenkins Beaker Builder
Plugin [2].
This release also introduces the "Beaker Architecture Guide", starting
with a page giving a general overview of Beaker's capabilities:
http://beaker-project.org/docs-release-0.14/architecture-guide/capabiliti...
Additional details about the above features and smaller changes for this
release can be found in the release notes here:
http://beaker-project.org/docs-release-0.14/whats-new/release-0.14.html
Thank you to all who contributed to this release.
Regards,
Nick.
[1] http://beaker-project.org/dev/proposals/enhanced-user-groups.html
[2] https://wiki.jenkins-ci.org/display/JENKINS/Beaker+Builder+Plugin
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months
Some thoughts on system access policies
by Nick Coghlan
Putting these thoughts in email form so Dan can either take them into
account when rewriting the system pools proposals, or else suggest areas
which seem like unneeded complexity. For example, with ad hoc groups,
maybe we don't need system pools as a separate notion for tagging
purposes (just create a group instead). They're all only half-formed
notions, so definitely take them with a rather large grain of salt :)
Firstly, I'm thinking that we should ensure the system <-> access policy
relationship is always one-to-one. Anything else will be too confusing.
If we decide to later implement a tagging system for referring to kinds
of systems, that should be a separate thing independent of access policies.
I'm contemplating up to four different "kinds" of access policy:
- system access policy. Just a transition mechanism from the current
system level permissions, these will be created automatically as part of
the data migration from the legacy access model. These would be
represented in the UI as a "Custom access policy".
- user access policy. The default access policy applied to systems owned
by a particular user if no other policy is nominated. Can only be edited
by the user themselves.
- group access policy. An access policy controlled by the owners of a
particular group. System owners may switch the access policy from an
implicitly created system policy or their user policy over to a group
access policy.
- pool access policy. An access policy independent of any particular
group. In a certain sense, system access policies are an example of
this, using a pool containing exactly one system.
As part of this, I'm wondering if we want to borrow the *nix account
management notion of creating an implicit group for each user, where
they're the group owner and only member. Then we can require that access
policies have an "owning group", and for user access policies, this
would be the user's implicit group. Similarly, for custom access
policies, the policy owner would be the system owner's implicit group. I
suspect there are trade-offs either way (modelling user-owned policies +
group-owned policies separately, or introducing an implicit group for
each user), but it's something we should deliberately consider.
In terms of permissions, the list in the current system pools proposal
looks pretty good:
edit system details (edit-system)
loan system to anyone (loan-any)
loan system to self (loan-self)
issue power and provisioning commands (control-system)
implicitly schedule recipes on the system when submitting jobs
(schedule-recipe)
reserve system manually (via web UI or bkr client) (reserve-manual)
However, we may want to consider some additions:
edit access policy (edit-policy)
switch access policy (switch-policy)
explicitly request the system when submitting jobs (schedule-explicit)
edit-policy refers to changing the policy itself. If we don't add it,
updates would be limited to the owning user (for user access policies)
or owners of the owning group (for group access policies)
switch-policy refers to changing the access policy on a system to a
different policy. If we don't add it, updates would be limited to the
system owner.
schedule-explicit gets us back to the notion of having systems in the
general pool that are available to the scheduler, but only when
explicitly requested in the job XML. This extra field would allow you to
have a policy where "schedule-recipe" was empty (so the system would
never be used automatically), but we could add new features to the job
XML to override the normal rules. Since there would need to a lot of
other supporting changes to make this happen, it should be a deferred
feature, but it's something to keep in mind as a future enhancement that
may guide the underlying implementation details.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months
Moving business logic out of Beaker's view layers
by Nick Coghlan
Currently, we have a lot of business logic in our view layers, including
various permissions checks. This is problematic, since it can lead to
permission errors in different UIs, and also means we need to do
systematic testing of permissions errors on each view, which makes the
integration tests slow.
There's a better way to handle this kind of thing: moving the
permissions checks to lower level model code and systematically testing
them there, and using structured exceptions to communicate that
information to the view layer in an abstract way.
As an example of how that can work:
class UserPermissionsError(Exception):
"""User does not have appropriate permissions"""
def __init__(self, user, action):
self.user = user
self.action = action
msg = "%s not permitted for %s"
super(UserPermissionsError).__init__(msg)
class Target(object):
# assorted other code
def can_change_name(self, user):
return user == self.owner # For example
def set_name(self, name, user):
if not self.can_change_name(user):
action = "Changing name of %r" % self
raise UserPermissionsError(user, action)
# Potentially also log the change in an audit table
self.name = name
In the views, the "can_change_name" query API would be used to control
permissions based display of various UI elements, while the actual
modification operations can rely on the data model layer to do the
permission checks, rather than having to duplicate that logic in every view.
Beaker 0.13 and 0.14 have started us partway down this road (Jobs have
several can_* methods now), but I'd like us to start moving towards
checked update methods at the data model layer, too. This also ties in
with the "ActivityMixin" that was added in 0.13, which moves activity
tracking out of the view layer and into the model layer.
I see two critical benefits to this approach:
1. From a security perspective, it makes it less likely that permissions
will differ between views, since all views should be using common
permission checking and activity tracking code when working with a given
part of the model.
2. From a testing perspective, having these operations in the model
layer means we can do our systematic testing at that level, rather than
going through the view layer. Our view testing (which is the really slow
part of the tests) can then be simplified to ensure the presence/absence
of widgets for various permissions (the "can_*" calls), as well as
correct handling of UserPermissionsError (on actual operations). This
frees up the integration tests from needing to check all of the
different reasons *why* someone may not have permission to do something,
and instead lets us treat it as a binary "permissions or not" test case.
Cheers,
Nick.
P.S. to actually handle this in a more comprehensive way, you don't
expose the raw data model layer to the views at all - you force them to
go through an intermediate layer that enforces the permission checks.
That's not really practical for Beaker's current state though - we first
need to move the business logic out of the views and down to the data
model layer before we can even think of separating the "application
model" (which cares about permissions and audit logs) from the "data
storage model" (which doesn't).
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months
Jenkins plugin for Beaker
by Vojtech Juranek
Hi,
for those who might be interested: I implemented Jenkins plugin for Beaker
[1], which is able to schedule job in Beaker from Jenkins. For more details
see wiki page of the plugin [2]. I release the plugin yesterday, by now it
should be already available in Jenkins update center. Any RFE or bug reports
are welcome (via email or here if you don't mind, Jenkins Jira component for
this plugin is not created yet)
Behind the scene it uses beaker4j [3], which is my attempt to implement java
library for easy integration with Beaker (currently only via XML-RPC).
However, this library it not mature yet, so any proposals for improvements are
welcome as well (major redesigns can be expected in the future).
Thanks
Vojta
[1] https://github.com/jenkinsci/beaker-builder-plugin
[2] https://wiki.jenkins-ci.org/display/JENKINS/Beaker+Builder+Plugin
[3] https://github.com/vjuranek/beaker4j
10 years, 2 months
Updated submission delegates design published
by Nick Coghlan
Ray and I have been working out the details of the submission delegates
system for 0.14 on Gerrit. The updated design proposal is now up on the
site:
http://beaker-project.org/dev/proposals/enhanced-user-groups.html#submiss...
Quick summary:
* users can nominate other users (including service accounts) as
"submission delegate"
* if someone is your submission delegate, they can set
"user=<your_user_name>" as an attribute on jobs they submit
* if they do that, then the job owner will be *you* rather than the
submitter
* we will still track the submitter, and they will still have access
specifically to the jobs they submit (to allow for automated
cancellation and other operations as well)
A couple of other items that may not be captured in the design proposal,
but we still plan to do:
* jobs submitted this way will appear on My Jobs for both the submitter
and the designated owner
* if they have an email address defined, the submitter will
automatically be added to the job notification CC list
Cheers,
Nick.
P.S. My Jobs in 0.14 reverts to its pre-0.13 behaviour, and there's a
new My Group Jobs page for jobs submitted on behalf of any groups you
belong to:
http://beaker-project.org/docs-develop/whats-new/next/my-group-jobs.html
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months
Proposed updates to release process for 0.14+
by Nick Coghlan
Since our release tools don't currently handle the creation of release
candidates, here's what I'm proposing as our general release process
(starting with 0.14) that should let us use the X.Y.0 releases as the
equivalent of a release candidate:
1. When we have all the bugs targeted at the milestone at VERIFIED, and
the release notes have been drafted, we create the release branch and
the release RPMs for that release (e.g. 0.14.0). These all get uploaded
to the client-testing and server-testing repos, and we push the updated
docs to the website (including the new docs branch, e.g. docs-release-0.14)
2. We announce here that the new release is available in the testing
repo, referring to the release notes on the release-specific docs branch.
3. If our own acceptance testing (or anyone else's) finds a showstopper
bug, then we create a maintenance release (e.g. 0.14.1) to fix it and
upload that to the testing repos.
4. If everything looks good, then we move the RPMs over to the main
repos, merge the release branch to master and update the site.
5. Finally, we announce the release here, referring to the release notes
on the main part of the site.
6. Perform additional site cleanup, including updating the technical
road map and design proposal status.
This does have one consequence for changes to client components in
particular: since users drawing directly from our repos may see our
client updates before their local Beaker installation is updated, we
should be conservative in the way we make changes to the way the client
talks to the server over XML-RPC.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months
beaker-import issue in RHEL 6
by Venkat_R_K@Dell.com
I tried to do beaker-import and I have attached the screenshot file. Please help me , where it's going wrong.
Regards,
Venkat
-----Original Message-----
From: beaker-devel-bounces(a)lists.fedorahosted.org [mailto:beaker-devel-bounces@lists.fedorahosted.org] On Behalf Of Nick Coghlan
Sent: Friday, July 19, 2013 12:46 PM
To: beaker-devel
Subject: [Beaker-devel] Updated component list (again)
With beaker-system-scan scheduled to be split out as its own subproject, I figured I would take another shot at coming up with a more useful component list.
(FWIW, we may want to look at splitting beaker-wizard out into a subproject, too)
Rather than the current component model, which is based mostly on "where stuff runs", this is based more on functional divisions. I think this is a better split, as adding a new piece of functionality will general involve updating at least the web UI *and* the CLI, and often other components as well (such as the scheduler or lab controller).
There are 16 proposed components, of which 12 related to different functional areas, and the last 4 are for the cross cutting "make everything else work" areas.
With this split, my intent is that we would mark a change based on its primary goal, even if there were some incidental changes in other areas as a result. Submission delegates, for example, is mostly about Job Management & Reporting, even though it also has consequences for User & Group Management and Automated Scheduling. The web UI modernisation project would be marked as Server Infrastructure, etc.
The default component for untriaged bugs would be "General"
* User & Group Management
Interface and model for users & groups
* Distro Management & Reporting
Interface and model for distros (including distro import and
distroRequires)
* System Management & Reporting
Interface and model for systems (including loans and hostRequires)
* System Inventory Scan
Hardware scanner for inventory population
* System Provisioning
Bare metal provisioning of systems (including kickstart file generation and power commands)
* Dynamic Virtualisation
Integration with an IaaS for provisioning
* Job Management & Reporting
Interface and model for jobs (etc)
* Automated Scheduling
Automated job scheduling
* Test Harness
beah and alternative harness support
* Log Management
Upload and handling of task logs (including retention tags)
* Task Library
The RPM based task library
* Task Creation Wizard
beaker-wizard
* Server Infrastructure
Common server components (including dependency updates)
* Client Infrastructure
Common client components (including dependency updates)
* General
Anything that genuinely spans multiple components or doesn't fit anywhere else
* Project Infrastructure
Test infrastructure, beaker-project.org, internal developer guides
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/) _______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
10 years, 2 months
Updated component list (again)
by Nick Coghlan
With beaker-system-scan scheduled to be split out as its own subproject,
I figured I would take another shot at coming up with a more useful
component list.
(FWIW, we may want to look at splitting beaker-wizard out into a
subproject, too)
Rather than the current component model, which is based mostly on "where
stuff runs", this is based more on functional divisions. I think this is
a better split, as adding a new piece of functionality will general
involve updating at least the web UI *and* the CLI, and often other
components as well (such as the scheduler or lab controller).
There are 16 proposed components, of which 12 related to different
functional areas, and the last 4 are for the cross cutting "make
everything else work" areas.
With this split, my intent is that we would mark a change based on its
primary goal, even if there were some incidental changes in other areas
as a result. Submission delegates, for example, is mostly about Job
Management & Reporting, even though it also has consequences for User &
Group Management and Automated Scheduling. The web UI modernisation
project would be marked as Server Infrastructure, etc.
The default component for untriaged bugs would be "General"
* User & Group Management
Interface and model for users & groups
* Distro Management & Reporting
Interface and model for distros (including distro import and
distroRequires)
* System Management & Reporting
Interface and model for systems (including loans and hostRequires)
* System Inventory Scan
Hardware scanner for inventory population
* System Provisioning
Bare metal provisioning of systems (including kickstart file
generation and power commands)
* Dynamic Virtualisation
Integration with an IaaS for provisioning
* Job Management & Reporting
Interface and model for jobs (etc)
* Automated Scheduling
Automated job scheduling
* Test Harness
beah and alternative harness support
* Log Management
Upload and handling of task logs (including retention tags)
* Task Library
The RPM based task library
* Task Creation Wizard
beaker-wizard
* Server Infrastructure
Common server components (including dependency updates)
* Client Infrastructure
Common client components (including dependency updates)
* General
Anything that genuinely spans multiple components or doesn't fit
anywhere else
* Project Infrastructure
Test infrastructure, beaker-project.org, internal developer guides
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/)
10 years, 2 months