September 2016 - cloud - Fedora mailing-lists

Announcing Fedora Atomic "latest" download URLs
by Adam Miller 23 Dec '16

23 Dec '16

Hello all, On behalf of the Fedora Cloud Working Group, I am happy to announce that we now have a persistent point of download for users who would like to simply reference a single URL for scripting purposes or otherwise. There is also a companion set of URLs that provide the image name that can be downloaded for informational purposes or scripting. This will allow users to download the image and know the resulting image name without any human interaction needed. The rationale behind this was to make sure that users always be aware of the version (compose id) of the image they downloaded in order to not have issues/bugs filed against an image named "latest" that is changing out from under users every two weeks. The new URLs are below: https://getfedora.org/atomic_qcow2_latest https://getfedora.org/atomic_raw_latest https://getfedora.org/atomic_vagrant_libvirt_latest https://getfedora.org/atomic_vagrant_virtualbox_latest https://getfedora.org/atomic_qcow2_latest_filename https://getfedora.org/atomic_raw_latest_filename https://getfedora.org/atomic_vagrant_libvirt_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_latest_filename I have also updated the Cloud Wiki[0] page to include information about these as well as a sample script of how to use them together. Thank you, -AdamM [0] - https://fedoraproject.org/wiki/Cloud#Fedora_Cloud_Atomic_Image_Download_Lin…

5 7

Separate Repository for Atomic Specific Fedora-Dockerfiles
by Trishna Guha 16 Nov '16

16 Nov '16

Hi, We have a repository on Github named Fedora-Dockerfiles [0]. The Repository contains Dockerfiles but those are not **atomic** specific. So adding ability to use **atomic** command will make **other hosts** lose the ability to use the Dockerfiles. Since we are focusing on having production ready Dockerfiles for Atomic host, Should we create a separate repository that contains Atomic specific Dockerfiles? [0] https://github.com/fedora-cloud/Fedora-Dockerfiles -- Regards, Trishna Guha

4 6

Fedora Release Tools Demo (Canceled) - Written Status
by Amanda Carter 07 Nov '16

07 Nov '16

Hi folks, due to travel and various obstacles, we're not able to host a recorded demo this month. Instead we've put together a status report that includes some additional highlights we think you might be interested in. If you have feedback and/or think this works well, I'd love to know b/c I think this vehicle covers more information than a demo alone so I might do both in the future if it's worth it. Apologies for missing the actual show and tell - if there's anything you'd like to see specifically, I'm sure we can arrange something. https://fedoraproject.org/wiki/ReleaseEngineering/StatusReport#13SEP2016 -- Amanda Carter

1 2

Docker Layered Image Naming and Tagging
by Adam Miller 02 Nov '16

02 Nov '16

Hello all, I was recently discussing some items around docker layered image release process in the future with Randy (bowlofeggs) and Patrick (puiterwijk). As a side effect of our discussion there were two questions I wanted to ask of the Cloud WG: 1) Do we want to maintain docker images for every Fedora Release or do we want to focus only on latest? (i.e. - do we want to maintain them like we do rpms or take a different position) 2) Do we want to keep around multiple versions of a container? For example: If we had the following images: registry.fedoraproject.org/cockpit:0.95-1.23 registry.fedoraproject.org/cockpit:0.95-1.24 registry.fedoraproject.org/cockpit:0.95-1.25 One we release to stable 0.95-1.25, can we delete -1.24 and/or -1.23? What kind of retention do we want here? (Note that rpm content does not currently maintain a N and N-1 in the repositories) Thank you, -AdamM

4 14

[cloud] #153: design, deploy and document Fedora OpenShift Playground (FOSP)
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#153: design, deploy and document Fedora OpenShift Playground (FOSP) --------------------+--------------------- Reporter: goern | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting --------------------+--------------------- This ticket is to coordinate the activities to design, deploy and document the Fedora OpenShift Playground (FOSP). Technical work is conducted by puiterwijk and misc, help is offered by scollier and goern jzb to create a wiki page describing the SLA of FOSP -- Ticket URL: <https://fedorahosted.org/cloud/ticket/153> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 19

[cloud] #104: Atomic PXE tree does not work for interactive installs
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#104: Atomic PXE tree does not work for interactive installs ---------------------+-------------------- Reporter: walters | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ---------------------+-------------------- Due to the change to *not* embed the content in squashfs (so that you can use kickstart to download newer trees via HTTP), the simple: virt-install --name f22-atomic-test --ram 2048 --disk size=8 -l https://dl.fedoraproject.org/pub/alt/stage/22_TC2/Cloud_Atomic/x86_64/os/ breaks unless you use e.g. initrd-inject to add a kickstart. This is hard to fix without actually having a Software UI in anaconda for rpmostreepayload. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/104> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 3

[cloud] #103: bugzilla components for base image and Atomic Host
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#103: bugzilla components for base image and Atomic Host ---------------------+-------------------- Reporter: walters | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ---------------------+-------------------- https://git.fedorahosted.org/cgit/spin- kickstarts.git/commit/?id=6ba647a663f09da4ba740eb99733a39cba58d204 shows that we really need a Bugzilla entries in Fedora for both the Docker base image and the Atomic Host. And to define the maintainers of them. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/103> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 2

[cloud] #89: Add Dockerfile Section to Downloads Page?
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 2

[cloud] #83: participation in OpenShift Commons
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 4

[cloud] #78: Draft charter change, new slate (Cloud WG members vote needed!)
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#78: Draft charter change, new slate (Cloud WG members vote needed!) --------------------+-------------------- Reporter: mattdm | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: --------------------+-------------------- Joe has prepared a draft change to the charter https://lists.fedoraproject.org/pipermail/cloud/2014-October/004372.html making it easier to select new members. Additionally, I've proposed a new WG membership slate based on current activity: https://lists.fedoraproject.org/pipermail/cloud/2014-October/004372.html By the existing rules, both of these need 5 +1 votes from existing members of the WG to pass. That is, the people listed https://fedoraproject.org/w/index.php?title=Cloud/Governance&oldid=368062#C… — so, current members, please vote on each. If we can't reach quorum in a week, I'll take this to FESCo for "override approval", but I hope that won't be necessary. -- Ticket URL: <https://fedorahosted.org/cloud/ticket/78> cloud <https://fedorahosted.org/cloud> Fedora Cloud Working Group Ticketing System

1 7

[cloud] #76: Explore possibility of shipping preconfigured KVM cloud image on live DVD
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 1

[cloud] #71: libmicrohttpd is back as a systemd dependency
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 2

[cloud] #60: Enable serial console for bootloader
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 5

[cloud] #53: anaconda doesn't allow installation of current fedora-cloud-base.ks
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 2

[cloud] #44: hey we should have a vagrant base box
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 14

[cloud] #23: File F21 change: Re-factor cloud-init
by Nobody 13 Oct '16

13 Oct '16

#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

2 15

[cloud] #145: Include bind-utils or similar in base image
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 14

[cloud] #112: Ultimately reducing the tools installed in the Fedora docker image, but first getting messaging and expectations right
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 6

[cloud] #101: Proposed for Fedora 23 - Support for Windows 10 Client Hyper-V
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 1

[cloud] #129: RabbitMQ fails to build
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 1

[cloud] #120: Fedora 22 Cloud vagrant image does not extend filesystem to disk size
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 10

[cloud] #34: External need: batched updates
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 2

[cloud] #110: Make NFS file sync work with Vagrant seamlessly
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 1

[cloud] #81: Create cloud training materials for ambassadors
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

2 3

[cloud] #38: Automatic Smoketests on Image Build
by Fedora Cloud Trac Tickets 13 Oct '16

13 Oct '16

#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

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud September 2016