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)
----------------------------------------------------------------------
(Continue reading)

Nick Coghlan | 27 Feb 03:02 2015
Picon

Fedora COPR now supports package signing

We've previously discussed the idea of allowing Beaker to depend on EPEL
when running on RHEL/CentOS, thus allowing the use of Fedora's COPR
system for package builds.

The COPR team recently switched COPR over to signing packages by
default, so it may be worth revisiting that idea at some point in the
coming weeks/months.

Cheers,
Nick.

--

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Andrej Manduch | 26 Feb 21:20 2015
Picon

[PATCH] bkr-client-autocompletion: grep -> /usr/bin/grep

From: Andrej Manduch <amanduch <at> gmail.com>

When you have strange things in your ~/.basrc (like grep --color=always)
then beaker autocompletion can produce wrong output.
example:
burlak <at> borg /e/bash_completion.d $ bkr
-h
^[[m^[[Kpolicy-revoke^[[01;31m^[[K
--help
^[[m^[[Kremove-account^[[01;31m^[[K
^[[m^[[Kdistros-edit-version^[[01;31m^[[K
^[[m^[[Ksystem-delete^[[01;31m^[[K
^[[m^[[Kdistros-list^[[01;31m^[[K
^[[m^[[Ksystem-details^[[01;31m^[[K
^[[m^[[Kdistros-tag^[[01;31m^[[K

This patch will ensure that bkr autocompletion will
always use original `grep`.

Signed-off-by: Andrej Manduch <amanduch <at> gmail.com>
---
 Client/bash-completion/bkr | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Client/bash-completion/bkr b/Client/bash-completion/bkr
index 76d6b9e..f64e1c0 100644
--- a/Client/bash-completion/bkr
+++ b/Client/bash-completion/bkr
 <at>  <at>  -7,9 +7,10  <at>  <at> 
 # Function expands options from main option (like workflow-tcms)
(Continue reading)

Andrej Manduch | 26 Feb 21:38 2015
Picon

[PATCH] bkr-client-autocompletion: grep -> /usr/bin/grep

When you have strange things in your ~/.basrc (like grep --color=always)
then beaker autocompletion can produce wrong output.
example:
burlak <at> borg /e/bash_completion.d $ bkr
-h
^[[m^[[Kpolicy-revoke^[[01;31m^[[K
--help
^[[m^[[Kremove-account^[[01;31m^[[K
^[[m^[[Kdistros-edit-version^[[01;31m^[[K
^[[m^[[Ksystem-delete^[[01;31m^[[K
^[[m^[[Kdistros-list^[[01;31m^[[K
^[[m^[[Ksystem-details^[[01;31m^[[K
^[[m^[[Kdistros-tag^[[01;31m^[[K

This patch will ensure that bkr autocompletion will
always use original `grep`.

Signed-off-by: Andrej Manduch <amanduch <at> gmail.com>
---
 Client/bash-completion/bkr | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Client/bash-completion/bkr b/Client/bash-completion/bkr
index 76d6b9e..f64e1c0 100644
--- a/Client/bash-completion/bkr
+++ b/Client/bash-completion/bkr
 <at>  <at>  -7,9 +7,10  <at>  <at> 
 # Function expands options from main option (like workflow-tcms)
 _bkr_complete()
 {
(Continue reading)

Nick Coghlan | 19 Feb 03:46 2015
Picon

Receiving HTML rather than JSON despite Accept header

Hi folks,

I'm trying to use the HTTP APIs documented in
https://beaker-project.org/docs-release-19/server-api/http.html as follows:

    curl --negotiate -H 'Accept: application/json' https://<Beaker server domain>

I have a valid Kerberos ticket, but the main page just returns the HTML list of systems, while the
subcollections for available, free and my systems return a login page redirect.

So it appears either something is broken or the API documentation has omitted a required setup step.

Cheers,
Nick.

--

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Jaroslav Kortus | 13 Feb 23:36 2015
Picon

Building beaker from sources

Hi there,

I've recently come to a need of building beaker from git.

Unfortunately there's couple of obstacles I'd like your advice on.

First: no tito anymore. Last time I was doing the rebuilds from upstream devel branch it 
was using tito which was quite handy for generating srpms which I then had rebuilt. Is 
there anything helpful in the same way today?

I found it quite difficult compared to my previous experience. Even the deps listed in the 
spec file are hard to download (wget downloads it as a different name from what's expected 
in the spec file).

Second: beaker-transfer does not start "green" any more without archive server config 
options present. So the question is: do I need that daemon for anything really?

I've ran the jobs in my current combo setup (LC+server on one machine) and it seemed to me 
to transfer the logs just as before with the daemon (beaker-transfer) down.

Third: I would like to have some step-by-step howto on building the packages from sources. 
I could not find it on the website. Something similar to kickstarts for custom-deployment 
of beaker. With all necessary repos linked as well as commands that you use to build the 
final packages.

Thanks for any pointers that could resolve my issues :).

Cheers,
Jaroslav.
_______________________________________________
(Continue reading)

Amit Saha | 6 Feb 03:12 2015
Picon

Design proposal: Predefined Access Policies for Systems

Hi all,

We just published the design proposal for implementing "Predefined access policies
for systems" [1]. 

If you have any questions/comments/suggestions, please do let us know.

[1] https://beaker-project.org/dev/proposals/predefined-access-policies.html

Best,
Amit.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 20 Jan 05:01 2015
Picon

LCA 2015 talk: Beaker's Hardware Inventory system

The video is up on YouTube: http://t.co/WorOwbv37w

Slides: https://amitksaha.fedorapeople.org/lca2015/slides.html

--

-- 
Amit Saha 
SED, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 20 Jan 04:30 2015
Picon

Beaker 19.2 released

The Beaker 19.2 maintenance release is now available from
beaker-project.org [1].

Beaker now supports the Petitboot boot loader used on some newer IBM 
Power systems. This release also includes an assortment of minor fixes. 
Full details are in the release notes [2].

[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-19.html#beaker-19-2

--

-- 
Dan Callaghan <dcallagh <at> redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 13 Jan 03:43 2015
Picon

Direct dependenices for restraint

Hi all,

I am working on a developer's guide for restraint and from what I can see the following
will install all the necessary packages on F21 for 'make check' to pass:

sudo yum -y install gcc make glibc-devel glib2-devel libsoup-devel \                                                                                                                     
      libarchive-devel pkgconfig libxml2-devel git-daemon thttpd tar

Are the following direct dependencies of restraint or are they just pulled in 
by the direct dependencies/or are they not used any more?

libffi : seems like systemd is pulling this in?
sqlite: same as above?
openssl
libselinux
bzip2
intltool

(Ref: http://restraint.readthedocs.org/en/latest/install.html#building-from-source)

Thanks,
Amit.

--

-- 
Amit Saha 
SED, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
(Continue reading)

Dan Callaghan | 12 Jan 08:24 2015
Picon

Pre-defined access policies vs. system pools?

In Beaker 20 we are planning to implement "pre-defined access policies", 
the last remaining piece of the original access policies design 
proposal:

https://beaker-project.org/dev/proposals/access-policies-for-systems.html#predefined-access-policies

I remember when we were writing that proposal and the system pools one, 
we went back and forth quite a lot before settling on that approach. We 
came to realise that separating the pre-defined access policies entirely 
from system groups/pools made things simpler.

However I am still worried that creating a new namespace for system 
access policies is not a good idea. It means essentially turning access 
policies into a first-class object in Beaker, which means we will 
eventually have to provide a way to list and search and describe and 
delete them. Plus it adds yet another potential for namespace conflicts: 
what happens when someone creates a pre-defined access policy named "lab 
systems"?

I am wondering if we should instead implement the bare minimum of system 
pools, and then use that as the basis for pre-defined access policies?

The choice of access policy for a system will then be either "custom 
access policy" (what we have now) or "inherit access policy from: 
<pool>".

Existing system groups would be converted into pools by a database 
migration. It would create a same-named pool for every system group, 
with the pool's owning group set to the same-named group. We would 
implement the UI for creating pools and adding/removing systems, but the 
(Continue reading)


Gmane