Amit Saha | 22 Sep 07:44 2014
Picon

Importing CentOS tree extras?

I have been trying to run a few jobs using CentOS 7. I noticed that
the http://mirror.aarnet.edu.au/pub/centos/7/os/x86_64/.treeinfo makes no  mention
of the "extras" repository at http://mirror.aarnet.edu.au/pub/centos/7/extras/x86_64/

Should we do this for CentOS as we do for "Fedora everything"? That is, check if it
exists, and it does, add it as well?

Best,
Amit.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Nick Coghlan | 19 Sep 10:01 2014
Picon

Two possible paths forward for scheduler improvements: Mesos and PyGMO

We're currently contemplating two paths to a "better scheduler".

1. Kill the bespoke scheduler, and replace it with Mesos.

We still don't know just how big the ramifications of that would be, but
if anyone wants to try out Mesos, this is probably the place to start:
https://timothysc.github.io/blog/2014/09/08/mesos-breeze/

(That may involve waiting until Fedora 21 is actually released, but
that's not too far away)

2. Improve the bespoke scheduler with PyGMO

The heart of the current scheduler is the "schedule_queued_recipes"
function. That essentially treats the recipe queue and the idle systems
as a 2-D matrix, and tries to map one to the other. However, it does so
incrementally on a recipe-by-recipe basis, which makes it difficult to
determine a "best fit" option that tries to get entire recipe sets
running immediately, minimises the amount of unused RAM or disk space, etc.

At PyCon New Zealand, I was introduced to a multi-objective optimiser
library published by the European Space Agency: https://esa.github.io/pygmo/

Whereas switching to Mesos would be a big architectural change, adopting
PyGMO to make the current scheduler *better* might be feasible by
switching "schedule_queued_recipes" to an approach where it:

1. Reads the current recipe queue and idle system sets from the database
2. Organises them into a format suitable for handing over to PyGMO
3. Runs PyGMO over the data set with an appropriate cost function to be
(Continue reading)

Matt Jia | 15 Sep 06:56 2014
Picon

Provisioning guest recipes with cloud images

Hi folks,

I am working on bug[1] and have created a task to provision guest recipes with cloud images. 

An example job can be found here[2] and its using RHEL7 image. There is one issue that the hostname
on guest recipe is not resolved properly from dhcp server.It only shows ip address and it may be required
further investigation. Other than that, everything is looking fine.

The source code is located at my personal repo[3]. If you have any questions, please let me know.

Cheers´╝îMatt Jia

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1108455
[2] https://beaker-devel.app.eng.bos.redhat.com/jobs/5912
[3] https://github.com/matt8754/beaker-cloud-init
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 12 Sep 09:40 2014
Picon

Beaker 0.18.1 released

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

This release fixes some issues relating to the custom distro support 
introduced in Beaker 0.18, plus some other general doc improvements. 
Full details are in the release notes [2].

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

--

-- 
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
Dan Callaghan | 4 Sep 08:57 2014
Picon

Beaker 0.18.0 released

On behalf of the Beaker development team, I'm pleased to announce that 
Beaker 0.18.0 is now available from the Beaker web site [1].

As always, the release notes [2] have the full story, but the highlights 
in this release are:

* an improved usage reminder e-mail system
* a new --host-filter option for workflow commands, for pre-defined 
  <hostRequires/> XML snippets
* better support for "custom" distros (that is, Fedora- or 
  RHEL-compatible distros which are named something else)

If you are dealing with custom distros in your Beaker installation, 
please note that there are some changes to the implementation details of 
the kickstart templates which may affect any custom templates or 
snippets you have. The release notes describe some potential issues, if 
you have any other questions we can help.

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

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

--

-- 
Dan Callaghan <dcallagh <at> redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
(Continue reading)

Nick Coghlan | 1 Sep 06:41 2014
Picon

Accessing entire host OS from a container

From the Docker 1.1 release notes
(http://blog.docker.com/2014/07/announcing-docker-1-1/):

* / is now allowed as source of --volumes. This means you can bind-mount
your whole system in a container if you need to.

This seems like a potentially useful feature when it comes to running
test harnesses in a container.

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
Nick Coghlan | 19 Aug 09:18 2014
Picon

Future directions for the Beaker test harness

A few weeks back, Amit put together a proof of concept for running the
test harness in a container, rather than directly on the host
(http://gerrit.beaker-project.org/#/c/3199).

That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
(https://beaker-project.org/dev/proposals/reference-harness.html)

At the same time, I don't think restraint is currently getting the level
of review and testing that it needs to mature into a plausible
replacement for beah as the default harness.

I think Amit's proposed patch provides a possible way forward:

1. Accept the initial approach where restraint is the *only* supported
harness when running inside a container. Specifying both
"contained_harness" and "harness" as ks_meta variables should be an
error at this point (side note: 'harness' should also be documented
along with all the other ks_meta variables, with a link to
https://beaker-project.org/docs/alternative-harnesses/).

2. Recommend publishing both beah *and* restraint in the harness repos
for Beaker installations. This will not only make restraint available
for container based testing, but also make it readily available via
"harness=restraint" for normal testing, without needing to add a custom
repo definition.

3. Once we have container based testing working reliably with restraint,
drop the restriction against using alternative harnesses in containers.

(Continue reading)

Amit Saha | 14 Aug 07:11 2014
Picon

Beaker 0.17.3 released

On behalf of the Beaker developers, I am pleased to announce that 
the Beaker 0.17.3 maintenance release is now available from
beaker-project.org [1].

This release introduces GRUB2 netboot support for PPC64 systems,
fixes a regression and some other bugs [2].

[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-0.17.html#beaker-0-17-3

Best,
Amit.

--

-- 
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
Nick Coghlan | 6 Aug 10:43 2014
Picon

Feature requests for system performance monitoring

I thought we had some open feature requests for being able to monitor
system performance while tasks were running. After seeing the
"Performance Co-Pilot" talk at PyCon AU, I'm wondering whether we might
be able to come up with a task that allows PCP monitoring to be enabled
on the system under test and the logs uploaded for later analysis (we'll
need to be careful with this, since it could easily overwhelm the log
server if used indiscriminately).

However, I can't find the relevant RFEs. That may just be a search
failure on my part, though, so I figured I'd check if anyone else
remembered such a thing.

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
Nick Coghlan | 22 Jul 06:40 2014
Picon

Defining & documenting Beaker's architecture support levels

Something that came up recently is the question of how we clearly
communicate *how well* Beaker supports different architectures. In
particular, just because we support provisioning something doesn't
necessarily mean we support doing hardware inventory scans on it.

I think the first step in adding something like that to the architecture
guide is to just list out all the features that go into our architecture
support. That's a useful thing to have regardless, and it means we can
potentially go through and create a feature matrix for it (or perhaps
summarise it as a numeric ranking).

On the provisioning side, the items I'm aware of are:

- basic provisioning (i.e. can we boot it at all)
- boot menu (i.e. do we provide a boot menu for manual provisioning)

On the inventory side, the items I'm aware of are:

- basic inventory (i.e. memory, number of CPUs, disk info)
- CPU details (i.e. precise details of the CPU capabilities)

So only x86 and x86_64 would currently get full marks - for everything
else, we don't currently provide full CPU details.

I think this also highlights for me that we *really* want at least a
summary in the architecture guide of what info beaker-system-scan
collects. It doesn't need to be completely detailed in terms of how the
information is reported back to Beaker, but having that list of "what
beaker-system-scan reports back to Beaker" will help explain the purpose
the inventory system serves, and (eventually) what some of the
(Continue reading)

Nick Coghlan | 21 Jul 08:29 2014
Picon

Offering lshw based inventory scans for new architectures

As we add new experimental architectures, we're in the situation where
we don't currently have a working inventory scan for those systems,
since newer versions of the operating system that support those
architectures are also missing smolt.

So, here's my question: would it be possible to tweak beaker-system-scan
such that, if smolt is available, we use it in preference to lshw, but
otherwise, we just rely on lshw?

My idea here is that, for existing architectures, we would run the
inventory task on an OS with smolt, to make sure we continue to supply
the same data we always have, until we're sure we have lshw to the point
where it's a suitable replacement.

But for new architectures, supplying whatever lshw can give us today
(along with the rest of the info beaker-system-scan collects) would be
better than nothing, so it makes sense to at least do that, and skip the
parts that depend on smolt.

Does this approach make sense to anyone else? Would it be reasonably
easy to just skip the smolt-based components of the scan when it wasn't
available?

Cheers,
Nick.

--

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
(Continue reading)


Gmane