[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges
#436: SSH access to systems in Beaker lab
--------------------------------------+---------------------
Reporter: atodorov | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
Currently systems in Beaker lab can be accessed only through bastion.fp.o
which is not as convenient as direct SSH into the system.
There's also the question whether or not to open the systems directly to
the Internet.
This needs to be discussed with infra. Filing here so it doesn't get lost.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/436>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 7 months
Building Images for Taskotron Disposable Clients
by Tim Flink
As we get closer to putting disposable clients into production, we need
a way to have updated images for those clients. I don't think this is
news to anyone since the topic has come up several times before but now
there's a bit more urgency :)
In my mind, we have the following requirements:
- Produces qcow2 images that work with testcloud
- can be run in an automated way
- allows adding/changing/customizing packages contained in image
- allows arbitrary repos to be specified
and the following "nice to have" things:
- can build branched and rawhide images
- builds images from scratch using only things provided by releng
- written in python
- builds more than qcow2 for some future-proofing
- can run well in a VM
Is there anything that I missed?
As far as I know, we're looking at two options right now:
taskotron-vmbuilder and imagefactory. I've put together a list of
the pros and cons that I know of for both tools. Thoughts on which
direction to take would be appreciated.
Tim
taskotron-vmbuilder [1] is a PoC system kparal built around
virt-builder [2]. Images are specified in a yaml file and instead of
building those images from scratch "It takes cleanly prepared, digitally
signed OS templates and customizes them".
[1] https://bitbucket.org/fedoraqa/taskotron-vmbuilder
[2] http://libguestfs.org/virt-builder.1.html
pros:
- already does almost everything we need
- fits all requirements
- builds quickly
- well supported
cons:
- requires blobs which are out of our control
* yes, I know who does the work behind virt-builder. My concern
isn't with him, it's the general concept that I don't like. This
also gets into the fact that we would have pretty much no control
over timing of release for the base images.
- limited support for rawhide and branched releases
- limited support for non-server spins
- output images are large in size
- virt-builder is not written in python
imagefactory [3] is a system for building os images and potentially
shipping those images to various cloud systems. Images are specified
with a kickstart file and an xml template descriptor. Imagefactory
builds images from scratch, essentially using the kickstart to run an
install inside a VM and processing that install into the desired image
type.
[3] http://imgfac.org/
pros:
- used by releng to create Fedora cloud images
- builds images from packages: no blobs that we don't have control over
- already has a mostly-complete RESTful api that can list images and
trigger new builds
- can support almost all spins; anything that can be represented in a
kickstart
- written in python
cons:
- not as fast as virt-builder
- somewhat more complex than virt-builder
- when something goes wrong, debugging can be difficult due to how the
tool works
- we may be somewhat on our own to fix issues if releng is not hitting
similar problems
- may not run well in a VM (would need nested virt)
8 years
Upgrading Phabricator on qadevel
by Tim Flink
I apologize for the short notice on this but I don't think that
anyone's using phabricator at the moment, so it's a good time to update.
I'm taking qadevel down for a bit to upgrade phabricator. I don't
expect the process to take any more than an hour but I'll send an email
out when its done.
Tim
8 years
Proposal to CANCEL: 2015-11-16 Fedora QA Devel Meeting
by Tim Flink
Most of the regular attendees aren't going to be around for the meeting
time this week so there's little to be gained by actually holding said
meeting.
If anyone can think of a topic that should be discussed as a group now,
reply to this thread and we can still meet. Otherwise, we'll just sync
up as needed outside the meeting.
Tim
8 years
Log Data Retention
by Tim Flink
Now that we've had a second flavor of this issue (running out of
inodes on a buildmaster) hit us, it's probably time to address log data
retention.
At the moment, we don't have a log data retention policy which has lead
to filling up disks with logs. We need some policy for how long we're
going to keep this data but I don't want to just decide something
without some form of discussion/documentation.
When we had this problem with AutoQA, we implemented a cronjob that
would delete logs older than 30 days but we also had a lot less disk to
work with back then.
There are 2 forms of log data that this new policy would affect: the
artifacts created by task execution and the build logs/data stored by
the buildmaster. Both are relatively simple file-based data which can
be removed without any additional consequences than no longer being
available.
The questions raised so far are:
1. How long is long enough to keep log and execution data?
2. Should be be cleaning up anything that references builds/artifacts
(like links in resultsdb) before we delete them?
3. Do we want to put resources into figuring out whether the result was
a PASS or FAIL before deleting it?
4. Should fesco be involved in this decision?
Thoughts or Suggestions? I really don't want to spend much time on this
but that statement does seem to come out of me when we're about to
spend too much time on a topic (at least some of which ends up being my
fault) :)
Tim
8 years, 1 month