#93: Getting sha256sum published for the cloud images
--------------------------------------------------+-----------------------
Reporter: kushal | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Infrastructure & Release Engineering | Keywords: meeting
--------------------------------------------------+-----------------------
This will help things systemd to search the images provided by Fedora in a
standard way using nspawn tool.
Example of such file from ubuntu:
https://cloud-images.ubuntu.com/trusty/current/SHA1SUMShttps://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/93>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#126: python3 only means ansible won't work
------------------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: major | Milestone: Future
Component: Cloud Base Image | Keywords: meeting
------------------------------+---------------------
If we have only python3 in our cloud images then ansible won't work as it
assumes /usr/bin/python is there. You end up with:
```
GATHERING FACTS
***************************************************************
failed: [f23] => {"failed": true, "parsed": false}
/bin/sh: /usr/bin/python: No such file or directory
```
We need to figure out a solution to this. For f23 cloud base image maybe
we decide that adding it via cloud-init is enough.. For vagrant I think we
should definitely include it in the image.
There also could be some workaround that I don't know about for this.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/126>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
Hey all,
So dgilmore pointed out that f22 docker images will not have yum
installed - which means we need to update the Dockerfiles for f22 to use
dnf and not yum.
We probably ought to go through and sanity-check them all to ensure they
work with the f22 image as well before, say, beta.
I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of the
work so far on the Dockerfiles - but also, I think he's looking for
assistance there in keeping the effort going.
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
#138: Produce updated cloud base images monthly
-----------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-----------------------+---------------------
An extension of https://fedorahosted.org/cloud/ticket/94
We have elected to release cloud base images monthly for the "current"
release of Fedora. The releng infra is in place to do this already, we
just need appropriate testing and process around it to release new images
and verify they aren't broken.
This ticket will track progress/status of this.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/138>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#131: make docker archived image get imported with lowercase tag
-----------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-----------------------+---------------------
Our docker image has a repositories file with this in it:
```
{"Fedora-Docker-Base-23_TC1-20150929.x86_64": {"latest":
"27653b989fba2fada76e804f4112b87d7b013758e99bbb88a26c070dbcae5962"}}
```
This means that the docker image gets tagged with Fedora-Docker-Base-
23_TC1-20150929.x86_64 when it gets loaded in. Unfortunately if you try to
build on top of this image by having a Dockerfile with `FROM Fedora-
Docker-Base-23_TC1-20150929.x86_64` then you will get an error because
only lowercase letters are allowed in tags of images in a registery:
"[a-z0-9]+(?:[._-][a-z0-9]+)*"
We should update this so that users can have a better experience.
[1] - //dl.fedoraproject.org/pub/alt/stage/23_TC1/Docker/x86_64/Fedora-
Docker-Base-23_TC1-20150929.x86_64.tar.xz
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/131>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#123: Document process for using Fedora-Dockerfile branches
----------------------+--------------------
Reporter: scollier | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords:
----------------------+--------------------
This should probably go on the github repo home page. Need to provide
instructions for users to submit to a specific branch, and not just to
master.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/123>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#88: Social Media for Dockerfiles
-----------------------------------+---------------------
Reporter: jzb | Owner: jzb
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Docker Base Container | Keywords: meeting
-----------------------------------+---------------------
We need to work with marketing to tweet about things regularly. I'd like
to put out regular tweets to promote individual Dockerfiles. Thoughts?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/88>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#99: AMI lifetimes (Cloud WG members vote needed)
-------------------------------------+-------------------------------------
Reporter: oddshocks | Owner: oddshocks
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Infrastructure & | Keywords: aws, images, vote,
Release Engineering | policy
-------------------------------------+-------------------------------------
This ticket is to discuss and vote on appropriate lifetimes for Fedora
Cloud AMIs on our official and community cloud accounts, as discussed on
the Cloud SIG list this month[1] and in this week's meeting.
Everyone seems to agree that after a final release, all TC, RC, Alpha,
Beta, and scratch builds should be deleted. This makes sense because
there'd be no reason to use any of these AMIs after the final release.
Still, we need to definitively decide on:
1. When should TC, RC, Alpha, Beta, and scratch builds be deleted? (1)
After a final release? (2) Progressively, when a newer build of the same
type comes out? (3) After a set amount of time, depending on the build
type? Note that with (2) or (3), we'd need some way to mark each build
with it's type. I don't think that necessarily happens now.
2. When should final release AMIs be deleted? (1) After a certain number
of newer final releases? (2) After a certain amount of time? (3) Never?
Also note that if we choose any age-based deletion policies, we'd need to
set up some sort of regular polling of *all* our AMIs on both accounts.
We want to hold as few AMIs at one time as is reasonable. There are many
AMIs created for each image build that happens, so our AWS storage charges
will become quite high if we don't keep our accounts clean. Discuss, and
then perhaps a vote?
[1]:
https://lists.fedoraproject.org/pipermail/cloud/2015-March/005087.html
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/99>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#139: Producing 2 week atomic images
-----------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-----------------------+---------------------
This is upon us now. Nightly images are here:
http://alt.fedoraproject.org/pub/alt/atomic/testing/
This ticket should track any issues/blockers/improvements we need to make
to this process.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/139>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#135: Fedora 23 Retrospective
--------------------+---------------------
Reporter: jzb | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
--------------------+---------------------
We need to look back on the 23 process and what went right and wrong.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/135>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System