#76: Explore possibility of shipping preconfigured KVM cloud image on live DVD
--------------------+--------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
--------------------+--------------------
I suggested this for Fedora Server, and Josh mentioned to me that we could
do it for the cloud.
What about prepackaging the cloud image on-disk with a live Workstation-
based image, with an existing KVM configuration including a preconfigured
config-drive allowing SSH access to the local user.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/76>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#71: libmicrohttpd is back as a systemd dependency
--------------------+--------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
--------------------+--------------------
This was gone from F20
(https://bugzilla.redhat.com/show_bug.cgi?id=908081) but is back now.
As noted in this bug, it is undesirable because libmicrohttpd pulls in
gnutls (and nettle) , which is not otherwise on the base image. Reducing
the number of crypto libraries there by default reduces the need to respin
off-cycle security updates -- this is not an abstract concern.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/71>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#60: Enable serial console for bootloader
---------------------+--------------------
Reporter: fabiand | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
---------------------+--------------------
The bootloader of the current cloud images is not attached to a serial
console.
Please change this, so we can also follow the bootloader part on the
serial console, i.e. for test automation.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/60>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#53: anaconda doesn't allow installation of current fedora-cloud-base.ks
---------------------+--------------------
Reporter: walters | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
---------------------+--------------------
Cloud images are expected to come with:
* root password locked
* No user precreated; instead, an agent (cloud-init, min-metadata-service)
pull config data from the hypervisor and inject ssh keys, create users,
etc.
The problem is Anaconda's user.py is a mandatory step.
A suggested hack is to set a root password, then unset it in %post.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/53>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#44: hey we should have a vagrant base box
--------------------+--------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
--------------------+--------------------
This is a very long-standing request. Here is a ticket for it. :)
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/44>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#23: File F21 change: Re-factor cloud-init
------------------------------+------------------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Feature Deadline)
Component: Cloud Base Image | Keywords:
------------------------------+------------------------------------------
'''Summary:''' Cloud Init was initially designed for a different
distribution and is only loosely tailored for our needs. As it stands, it
pulls in a rather large set of packages not used for other things. It is
also written in Python, itself a large subsystem which it would eventually
be nice to leave out of the base. Effort is moderate, with some low-
hanging fruit which may be addressed easily.
'''Importance:''' vital long term, but just moderate for F21 (We really
need this, but if we don't get work it now, it's in acceptable shape for
this release.)
'''Timeframe:''' F21 alpha, or F22 / if we don't make alpha with changes,
this can go in next release.
'''Scope:''' Self-contained
'''Cloud SIG owner:''' TBD
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/23>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#145: Include bind-utils or similar in base image
-------------------------------+--------------------
Reporter: jfindley | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future
Component: Docker Host Image | Keywords:
-------------------------------+--------------------
On an empty atomic host, there is no reasonable way of manually performing
DNS lookups.
This makes it very hard to debug DNS-related issues, and so it'd be great
if bind-utils (dig) or similar could be included in the base image.
This cannot be solved with a container, because if DNS is broken then
docker pull won't work.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/145>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#112: Ultimately reducing the tools installed in the Fedora docker image, but
first getting messaging and expectations right
-------------------------+--------------------
Reporter: bex | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
-------------------------+--------------------
See: https://fedoraproject.org/wiki/User:Bex/docker_image_reduction
A quick examination of just commands loaded in /usr/bin showed significant
differences between the F21 and F22 docker images. Consensus seems to be
forming around the idea that the Fedora docker image should be composed of
a minimum install of Fedora required to get dnf running. After that all
tools desired by the consumer should be added by the consumer. This is
inline with the "one process per container" philosphy that many people use
when thinking about containers.
However, we did ship more than a minimal image with F21 and we broke that
expectation in F22. Additionally, other distributions are shipping images
that contain some "non-minimal" tools, such as 'ps' or 'vi', therefore
users may expect them be in the Fedora images.
One solution is to include these tools today, but to explicitly note that
they are not guaranteed to be included in future versions. Additionally,
we should begin to encourage a new best practice of explicitly `dnf
install`ing any tools needed. Today these installs will be noops, tomorrow
they will actually do the install.
The full list of proposed re-additions for F22 and ultimate deletions is
on the wiki page
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/112>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#101: Proposed for Fedora 23 - Support for Windows 10 Client Hyper-V
----------------------------+--------------------
Reporter: znmeb | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future
Component: Docker (Other) | Keywords:
----------------------------+--------------------
I'm currently testing the F22 Project Atomic as a guest on Windows 8.1
Client Hyper-V. I can convert the TC 2 beta qcow2 to vhdx via qemu-img,
boot the disk with the credentials ISO in a Generation 1 Hyper-V guest,
log in as "fedora", sudo to "root" and do a 'docker run' pulling an image
from Docker Hub.
I still need to test browsing to a host-only network adapter from the
Windows desktop but that's just a matter of reading a few more manuals.
And generation 2 VMs don't work and would need to work for this to be
supportable. So I would like to propose supporting this use case in Fedora
23.
I don't have an effort estimate at the moment. A minimum task list so far
would be:
1. Operationalize the conversion from qcow2 to vhdx in the release
process.
2. Get generation 2 machines working. This may have to wait until Windows
10 ships.
3. Define test scenarios and build Windows PowerShell scripts to execute
them.
4. Documentation!
I'll volunteer for 3 and 4 for now - it's on my road map for my remix
anyway.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/101>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#129: RabbitMQ fails to build
----------------------------+--------------------
Reporter: coolsvap | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Future
Component: Docker (Other) | Keywords:
----------------------------+--------------------
Currently rabbitmq fails to build from the Docker file. Stuck at
RUN /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/129>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System