[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
8 years
Proposal to CANCEL: 2015-12-21Fedora 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, 4 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, 4 months
