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
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
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.23registry.fedoraproject.org/cockpit:0.95-1.24registry.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
#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
#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
#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
#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