#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
#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
#120: Fedora 22 Cloud vagrant image does not extend filesystem to disk size
------------------------------+--------------------
Reporter: pwnall | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Future
Component: Cloud Base Image | Keywords:
------------------------------+--------------------
Copied from RHBZ #1260800, based on responses seen on other bugs related
to the Vagrant image.
Description of problem:
The Vagrant image for Fedora 22 cloud does not extend the filesystem to
fill up the entire disk.
Version-Release number of selected component (if applicable):
https://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_6…
/Fedora-Cloud-Base-Vagrant-22-20150521.x86_64.vagrant-virtualbox.box
How reproducible:
Always
Steps to Reproduce:
1. Set up a new Vagrant box using the Fedora 22 cloud base box.
2. vagrant ssh
3. Inspect the partition table.
Actual results:
[vagrant@localhost ~]$ sudo fdisk -l /dev/sda
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe02b2711
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 6146047 6144000 3G 83 Linux
Expected results:
I'd expect to see the filesystem grown to fill the virtual disk.
Additional info:
This is a serious obstacle to deploying Fedora Cloud for me. I need to be
able to test things out in a Vagrant box before pushing things out to
production. The 3G filesystem makes it impossible for me to load
everything I need into the VM.
Please let me know if there is any other information I can provide to help
narrow this down.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/120>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#34: External need: batched updates
--------------------+------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Flock 2014
Component: --- | Keywords:
--------------------+------------------------
'''Summary:''' We want to produce updated images on a monthly cadence. It
would be nice if we could produce those from QA'd bunches of packages.
'''Importance:''' moderate (it will be hard to implement image refresh
without this, but we could do it)
'''Timeframe:''' F21 release + 1 month / Obviously better if we get things
lined up earlier
'''Fedora Sub-Project/SIG:''' Primarily QA, but Rel Eng and Infrastructure
too. This is pretty big.
'''
Cloud SIG owner:''' TBD (this probably needs someone actively contributing
to initial and ongoing work)
See the related Change proposal "(A)Periodic Updates to the Images"
http://flock2013.sched.org/event/8c4f702e42814598e0e4e31b188a0ae6
What's this ticket about? We need an owner for this — someone to drive it
forward.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/34>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#110: Make NFS file sync work with Vagrant seamlessly
------------------------------+--------------------------
Reporter: rtnpro | Owner: rtnpro
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Software Updates | Keywords: vagrant, nfs
------------------------------+--------------------------
Issues
======
1. Vagrant 1.7.2 does not identify proper flavor for Fedora, so, during
starting NFS client services in a Fedora guest, it fails. This issue seems
to have been fixed in Vagrant's master branch. We need to patch the
current RPM package for vagrant with the fixes.
2. By default vagrant guest OS tries to communicate to NFS server in the
host Fedora box using NFS v3 and it fails. It works correctly if we
explicitly ask vagrant to use NFS v4 using nfs_version: 4. This needs to
be documented for Fedora properly.
3. The biggest obstacle is mapping UID, GID from host OS to guest OS for
NFS 'all_squash' option to work. For example, in my host OS,the UID and
GID for my user is 1000, while that of vagrant's in the guest OS is 1001.
I am not sure what's the right way to fix it. Use some provisioning
scripts to configure the box on the fly?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/110>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#81: Create cloud training materials for ambassadors
-------------------------------------------+-----------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Collaboration & Communication | Keywords:
-------------------------------------------+-----------------------
Many Fedora Ambassadors come from a desktop or old-school sysadmin
background. Cloudy concepts are new and foreign. In talking with some of
them, it was suggested that it'd be really, really helpful to have some
basic training materials for our own ambassadors -- what is cloud, why
does it matter, what is Fedora Cloud, what is our strategy, why do _we_
matter, and so on.
http://mattdm.org/fedora/cloud2013/#1 might be a starting point. Maybe
some more interactive training would even be useful.
Of course, it'd also be awesome to get some people from the new modern
world interested in being ambassadors as well -- another direction to
approach the same issue. (But even then, training on what _we_ are doing
would be useful.)
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/81>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#38: Automatic Smoketests on Image Build
--------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Alpha)
Component: Testing & QA | Keywords:
--------------------------+-------------------------------
'''Summary:''' When a new image is built in Koji, automatically boot it
and run a basic matrix of tests.
'''Importance:''' moderate (worst case, we can keep doing this by hand)
'''Timeframe:''' F21 alpha / Want to reduce manual test workload
'''Fedora Sub-Project/SIG:''' QA and the Taskotran project
'''Cloud SIG owner:''' Sandro Mathys
https://fedoraproject.org/wiki/Taskotron
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/38>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#25: File F21 change: OpenShift Out-of-the-Box Image
--------------------------------+------------------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Feature Deadline)
Component: OpenShift Origin | Keywords:
Image |
--------------------------------+------------------------------------------
'''Summary:''' Fedora Cloud agreed to make a base image plus several
tailored to specific purposes. This is one of the tailored ones —
OpenShift ready to run.
'''Importance:''' nice to have (if we fail to do it, we are not any worse-
off than we are now, and OpenShift can still be installed on the base
iamge.)
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed
this release
'''Scope:''' self-contained (in collaboration with OpenShift developers)
'''Cloud SIG owner:''' TBD
https://fedoraproject.org/wiki/Changes/OpenShift_Out-of-the-
Box_Cloud_Image
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/25>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System