#89: Add Dockerfile Section to Downloads Page?
--------------------+--------------------
Reporter: jzb | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
--------------------+--------------------
For discussion - should we add a Dockerfile section on the downloads site?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/89>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#83: participation in OpenShift Commons
--------------------+---------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
--------------------+---------------------
Take a look at http://origin.openshift.com/commons
I brought up joining this to the board, and got the reasonable response of
"have you gotten the Cloud SIG committed to actually doing the
participation asked for?"
I've talked to a couple of people and I think there's sufficient interest,
but it seemed reasonable to ask formally if this is something we're
interested in. The actual formal requirements seem to be low:
> OpenShift Commons is open to anyone. We have no Contributor License
Agreement (CLA) or required donation to join. Instead we take each
organization at their word to be active participants in forums, Special
Interest Groups (SIGs), mailing lists and events.
and I think it'd be _great_ to have Fedora officially involved in that
way. What do you all think?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/83>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#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
#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
#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
#28: discuss modularized SELinux policy packaging
------------------------------+-----------------------
Reporter: mattdm | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Fedora 22
Component: Cloud Base Image | Keywords:
------------------------------+-----------------------
Possible F22 feature?
Summary: Monolith SELinux policy has rules for everything that could
exist, not just that which is installed. Possible room for reduction here.
'''Importance:''' nice-to-have
'''Timeframe:''' F21 or F22 / This is not low-hanging fruit.
'''Scope:''' self-contained (SELinux)
'''
Cloud SIG owner:''' TBD
(No Feature filed at this time -- discuss with SELinux policy maintainers)
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/28>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#73: test cases for cloud-init
--------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Final)
Component: Testing & QA | Keywords:
--------------------------+-------------------------------
We have a number of bugs for #cloud-config syntax not working properly --
probably because it's mostly been tested with debian/ubuntu-universe
tools.
For example:
* https://bugzilla.redhat.com/show_bug.cgi?id=1126857
* https://bugzilla.redhat.com/show_bug.cgi?id=1126365
We should fix these, obviously, but also, each time we fix one, we should
make a test case -- ideally an automatic test case! -- to make sure it
stays fixed.
It would also be nice to have some other test cases for cloud-config
syntax we expect to work.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/73>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#57: get official images uploaded into Rackspace
-------------------------------------------------+-------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21
Component: Infrastructure & Release | (Final)
Engineering | Keywords:
-------------------------------------------------+-------------------------
Work with Rackspace engineers... they don't yet have public image sharing,
but getting our official images uploaded to a fedora account as part of
the release process would be a good start.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/57>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#42: policies for batched updates
------------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Final)
Component: Software Updates | Keywords:
------------------------------+-------------------------------
See ticket #18
We want to putting out updated images periodically (or aperiodically as
needed). What are the rules? What are the procedures? Where are they
documented?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/42>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#12: send list of packages on cloud images to spot for change from %doc to
%license
------------------------------+-----------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21
Component: Cloud Base Image | Keywords: easyfix
------------------------------+-----------------------
See https://fedorahosted.org/fpc/ticket/411
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/12>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#37: External Need: software collections
-------------------------------------+-------------------------------------
Reporter: mattdm | Owner: mattdm
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Feature
Component: Collaboration & | Deadline)
Communication | Keywords:
-------------------------------------+-------------------------------------
External Need: Software Collections for Cloud Users
Summary: Provides selection of language stacks of particular versions to
users.
'''Importance:''' vital (provides a meaningful reason to use Fedora cloud
image, and helps insulate against rapid change)
'''Timeframe:''' F21 release / This is a requirement of users in
production.
'''Fedora Sub-Project/SIG:''' Environments and Stacks
'''Cloud SIG owner:''' mattdm -- more help wanted :)
Draft feature proposal:
https://fedoraproject.org/wiki/Cloud_Changelist#External_Need:_Software_Col…
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/37>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#63: list fedora accounts needed for releng to make official cloud images
content
--------------------+--------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Branch)
Component: --- | Keywords:
--------------------+--------------------------------
What official accounts and agreements do we need to upload cloud images to
our intended targets, including Amazon AWS, Google GCE, and etc?
What do we need to a) upload docker base images and b) do docker trusted
builds?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/63>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#39: External Need: Scratch Builds on Change
--------------------+--------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Branch)
Component: --- | Keywords:
--------------------+--------------------------------
'''Summary:''' Whenever the kickstart changes, _or_ an RPM which is on the
image hits the tree, a new scratch image is automatically built.
'''Importance:''' nice to have (makes development much easier, and makes
it quick to spot and fix problems before they affect anyone)
'''Timeframe:''' whenever we can get it / this adds value whenever it
happens
'''Fedora Sub-Project/SIG:''' Release Engineering, possibly Infrastructure
for resources
'''Cloud SIG owner''': TBD
We need an owner for this -- someone to drive it. And someone to help
release engineering and infrastructure with the actual implementation work
(not necessarily
the same person, but also not necessarily different)
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/39>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#59: Process for determining when and why Docker trusted images need to be
rebuilt
----------------------------+--------------------
Reporter: scollier | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Docker (Other) | Keywords:
----------------------------+--------------------
We have several Docker trusted images hosted on the Docker index:
https://index.docker.io/u/fedora/
These are built from the Fedora Cloud github account here:
https://github.com/fedora-cloud/Fedora-Dockerfiles
We need a clear process for deciding when these layered images need to be
rebuilt. Is it when new RPMs are released? Security errata? Changes to
config files? What are other criteria that could trigger the need for a
rebuild?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/59>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#72: go over f21 changes, make sure they're all in good shape
--------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Alpha)
Component: --- | Keywords: meeting
--------------------+-------------------------------
https://fedorahosted.org/fesco/ticket/1322
This is a meeting agenda item. Make sure all of the cloud-related changes
are in good shape:
* have owner
* are on track
* are updated with relevant info
And when not, find a way to fix them :)
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/72>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#62: notification of pending security updates in motd
------------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Alpha)
Component: Cloud Base Image | Keywords:
------------------------------+-------------------------------
I think it would be nice if the /etc/motd (or some other mechanism) would
inform users of pending security updates on login.
And, a welcome side-effect is that having cloud images check with the
update server network periodically gives us a better measure of whether
we're actually being used. Right now, cloud images are probably being
drastically undercounted, as many aren't updated ever.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/62>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#55: define shell command API available in Fedora Cloud Base Image
------------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Alpha)
Component: Cloud Base Image | Keywords:
------------------------------+-------------------------------
This is a list of shell commands (or at least the packages which contain
them) which are expected to work in a cloud metadata userscript at initial
Fedora Cloud Base Image launch. We should maintain this list and note
changes in the release notes, have a deprecation procedure, and so on.
The initial goal for Fedora Cloud Base Image is to balance size and
usefulness -- python and yum/dnf will be in the list, for example. For a
more "edgy" image, see Fedora Atomic.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/55>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System