Shang Gao | 30 Jun 04:23 2015
Picon

provision 2 machines in beaker on the same subnet

Hi all,

I was trying to provision 2 machines in beaker for kvm migration, they need to be on the same subnet, can we set
up it in follow section of Job XML? Thanks!

<recipeSet priority="Normal">
  <recipe ... >
  ...
    <hostRequires>
      <and>
        <arch op="=" value="x86_64"/>
        <key_value key="MEMORY" op="&gt;" value="2048"/>
        <key_value key="DISK" op="&gt;" value="30000"/>
      </and>
      <system_type value="Machine"/>
    </hostRequires>
  </recipe>
  <recipe  ... >
    <hostRequires>
      <and>
        <arch op="=" value="x86_64"/>
        <key_value key="MEMORY" op="&gt;" value="2048"/>
        <key_value key="DISK" op="&gt;" value="30000"/>
      </and>
      <system_type value="Machine"/>
    </hostRequires>
  </recipe>
</recipeSet>

Best Regards,
(Continue reading)

Nick Coghlan | 25 Jun 07:05 2015
Picon

Using Beaker to test a mass rebuild of Fedora Python packages against Python 3.5

With Python 3.5 in beta upstream, I'd like to create a Beaker recipe that:

1. Rebuilds the Fedora Python RPMs using the upstream Python 3.5 beta
tarball rather than the stable 3.4 release
2. Queries the Fedora repos to get the list of all packages with a build
or runtime requirement on Python 3
3. Uses
https://beaker-project.org/docs-develop/user-guide/beaker-provided-tasks.html#distribution-rebuild
to rebuild all the packages from 2 against the Python 3.5 beta RPM from 1

This idea pushes the limits of my current rpm/yum/dnf foo though, so I
figured I'd ask for advice here before I started hacking away at the
problem :)

Cheers,
Nick.

--

-- 
Nick Coghlan
Red Hat PnT Operations
DevOps Enablement, Brisbane

Software Development Workflow Designer & Process Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Jan Pokorný | 8 Jun 19:22 2015
Picon

[rhts][PATCH] s/sepcify/specify/

Signed-off-by: Jan Pokorný <jpokorny <at> redhat.com>
---
 bin/rhts-abort             |  2 +-
 bin/rhts-recipe-sync-block |  6 +++---
 bin/rhts-recipe-sync-set   |  8 ++++----
 bin/rhts-submit-log        |  4 ++--
 bin/rhts-sync-block        |  8 ++++----
 bin/rhts-sync-set          | 10 +++++-----
 6 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/bin/rhts-abort b/bin/rhts-abort
index 8c3f44b..cea6efa 100755
--- a/bin/rhts-abort
+++ b/bin/rhts-abort
 <at>  <at>  -107,7 +107,7  <at>  <at>  def main():
             recipeid = val

     if not type:
-        print "You must sepcify a type with the -t flag"
+        print "You must specify a type with the -t flag"
         sys.exit(1)

     if not result_server:
diff --git a/bin/rhts-recipe-sync-block b/bin/rhts-recipe-sync-block
index 175b625..2d882a4 100755
--- a/bin/rhts-recipe-sync-block
+++ b/bin/rhts-recipe-sync-block
 <at>  <at>  -49,10 +49,10  <at>  <at>  def sync_block(states,machines,any_machine,timeout):
     result_server = "http://%s/cgi-bin/rhts/scheduler_xmlrpc.cgi" % result_server

(Continue reading)

Amit Saha | 2 Jun 07:05 2015
Picon

Performance testing of the DB queries

Most recently this bug [1] made me think if there is a way to catch these sort
of problems during testing rather then in production. I think what we lack really
is the amount of data that our application has to query in production is magnitudes
bigger than during our integration tests or even our development environment.

May be we should look to do that as part of our test suite?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1226076

--

-- 
Amit Saha <http://echorand.me> 
PnT DevOps - Developer
Red Hat, Inc.

_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Prabhakar_Pujeri | 1 Jun 13:11 2015
Picon

[query] does beaker support Ubuntu/Debian/openSuse

Hi All,

Just wanted to know whether beaker supports Ubuntu/Debian/openSuse  if not what are the changes required to achieve it.

 

Thanks

Prabhakar

 

_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 4 May 06:56 2015
Picon

Simplify inventorying systems in Beaker

Hi all,

As part of implementing https://bugzilla.redhat.com/show_bug.cgi?id=846185 and 
https://bugzilla.redhat.com/show_bug.cgi?id=1121462, I was thinking that the best
user experience would be if we ask nothing of the user. They need to just click
on a system's "Update Inventory" button or run the "bkr update-inventory <fqdn>" command
to update the inventory data for the system.

So, the key step is to figure out which distro to use. RHEL6/CentOS6 would cover most
of the hardware, but there may be exceptions for older/newer hardware archs. So, here is
what I am thinking:

1. Start with RHEL6/CentOS6, and check if the system is compatible with it. If yes, go to step 4, 
else go to step 2.

2. Is the system compatible with RHEL7/CentOS7? If yes, go to step 4, else go to step 3.

3. Is the system compatible with RHEL5/CentOS5? If yes, go to step 4, else error out.

4. Submit a job with the chosen distro and /distribution/install and /distribution/inventory tasks.
(The job will use the <hostRequires force = .. /> element so that all non-removed systems can be inventoried
as long as the job owner has the sufficient rights on the system)

One immediate drawback of this is using hard coded distro names above. 

Another idea I can think of is have a system level ksmeta variable defined such as "inventory_distro=MyOSMajor"
and use that. But that is asking of system owners/beaker admins to have to do that explicitly. 
It would also vastly simplify the implementation.

Thoughts?

Best,
Amit.

--

-- 
Amit Saha <http://echorand.me> 
PnT DevOps - Developer
Red Hat, Inc.

_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 24 Apr 05:10 2015
Picon

Changing status ordering in Beaker 21

In the next Beaker major release (21.0) we are planning to make a change 
to the way Beaker computes the overall status for jobs, recipe sets, and 
recipes.

Currently if some tasks in a recipe are Completed but others are Aborted 
or Cancelled, the overall recipe status will be Completed. This is 
surprising and (arguably) less useful because it obscures the fact that 
the whole recipe did not really complete.

Similarly, if some recipes in a recipe set or job are Completed but 
others are Aborted or Cancelled, the overall status will be Completed 
right now.

In Beaker 21 we will change the status calculation so that if any task 
is Aborted or Cancelled, the entire recipe is Aborted or Cancelled, and 
thus the recipe set and job is Aborted or Cancelled too.

If you see any issues with this change in behaviour please bring it up 
here and we can discuss.

--

-- 
Dan Callaghan <dcallagh <at> redhat.com>
Software Engineer, Products & Technologies Operations
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 21 Apr 03:22 2015
Picon

Beaker 20.0 released

On behalf of the Beaker development team, I'm pleased to announce that 
Beaker 20.0 is now available from the Beaker web site [1]. Thanks to 
everyone who contributed patches and bug reports for this release.

In Beaker 20 we have implemented the "system pools" feature. On top of 
that, it is now also possible to set a system to use the access policy 
defined on a pool. The aim is to make it easy to apply the same access 
policy across a large number of systems.

The other significant feature in Beaker 20 is support for configuring 
the network boot loader on a per-recipe basis. This lets Beaker 
automatically select a supported boot loader depending on the distro 
being provisioned, and for users to select a different boot loader in 
their recipes.

There are also plenty of other minor enhancements and fixes. As usual, 
the release notes [2] have all the details.

The detailed list of all changes made since Beaker 19.3 is also 
available [3].

[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-20.html
[3] https://git.beaker-project.org/cgit/beaker/log/?qt=range&q=beaker-19.3..beaker-20.0&showmsg=1

--

-- 
Dan Callaghan <dcallagh <at> redhat.com>
Software Engineer, Products & Technologies Operations
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 27 Mar 05:43 2015
Picon

bkr client docker image

Just something which may  be useful:
https://github.com/amitsaha/docker_files/tree/master/dev_workflow/beaker-client

Everytime you run the image, it will always try to install the latest beaker client
from the nightlies repository.

Example:

$ docker run -ti amitsaha/bkr job-list --hub=https://beaker.server.com --username asaha

....

--> Running transaction check
---> Package beaker-client.noarch 0:19.4-0.git.109.fc3396d.fc19 will be updated
---> Package beaker-client.noarch 0:19.4-0.git.112.ed6b232.fc19 will be an update
--> Processing Dependency: beaker-common = 19.4-0.git.112.ed6b232.fc19 for package: beaker-client-19.4-0.git.112.ed6b232.fc19.noarch
--> Running transaction check
---> Package beaker-common.noarch 0:19.4-0.git.109.fc3396d.fc19 will be updated
---> Package beaker-common.noarch 0:19.4-0.git.112.ed6b232.fc19 will be an update
--> Finished Dependency Resolution

Dependencies Resolved
..
..
Updated:
  beaker-client.noarch 0:19.4-0.git.112.ed6b232.fc19
Enter your password:

  ["J:7637", "J:7636"

..

Best,
Amit.

--

-- 
Amit Saha <http://echorand.me> 
PnT DevOps - Developer
Red Hat, Inc.

_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Alexander Todorov | 19 Mar 13:23 2015
Picon

Which restraint repo to use ?

Hi guys,
I've found two repos for restraint:

https://bpeck.fedorapeople.org/restraint/el7/

https://amitksaha.fedorapeople.org/restraint/centos7/

It looks like the 1st one is more up-to-date. Which one is recommended for use?

Thanks,
Alex
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Jaroslav Kortus | 27 Feb 22:00 2015
Picon

Integration Tests results

Hi there,

I've just executed full integration tests run with the following result (patched develop 
branch):
Ran 1345 tests in 6731.735s

FAILED (SKIP=3, errors=70, failures=55)

real	112m14.756s
user	101m11.856s
sys	7m42.248s

Quite some errors then. Much more than I expected :). Looking at the results I have mixed 
feelings.

Some selenium tests were failing (almost all in my case). When I ran the same test alone 
it passed with no problems.

To get more data I ran the suite with "-sv" switch. Looking at the output there are some 
things that I'm not sure are errors or not.

For instance:
bkr.server.mail: ERROR: Exception thrown when trying to send mail
[...]
error: [Errno 111] Connection refused
bkr.server.tests.data_setup: DEBUG: Marked R:706 as complete with result Pass

or:
FAIL: test_all_tables_use_innodb (bkr.inttest.server.test_model.SchemaSanityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/root/beaker-private/IntegrationTests/src/bkr/inttest/server/test_model.py", line 
55, in test_all_tables_use_innodb
     table), 'InnoDB')
AssertionError: u'MyISAM' != 'InnoDB'

I've not created any new tables there (only added columns to existing tables). So how can 
this happen?

So the main question here is, are all the tests expected to pass on the develop branch? Or 
what are the usual results I can compare my patches to? Are there any other requirements 
besides the deps of integration tests RPM and 
https://beaker-project.org/dev/guide/writing-a-patch.html#testing-your-patch?

Thank you,
Jaroslav.

PS: are the results saved somewhere or is stdout the only option? "--debug-log" looks more 
like the framework debugging than the actual tests' debug output...
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel

Gmane