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
On thursday night the image builds didn't run because pagure was intermittently down.
For the past 2 nights they have failed to build. I'm not sure why exactly but there is
some libvirt error [1] in the logs.
Dennis has been looking into this for us.
I'm hoping we can an image built to look at before the freeze on Tuesday. If we do get
one I'll post here and ask everyone to give it a spin if they can.
Dusty
[1] https://kojipkgs.fedoraproject.org//work/tasks/4430/16254430/oz-x86_64.log
Hi all,
Today, and tomorrow are holidays in India. On Wednesday I will be
travelling to Cambodia for FUDCon APAC. I will be back home on Monday
evening. I am hoping to have a working internet connection during the
conference.
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.inhttps://dgplug.org
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2016-11-02 from 17:00:00 to 18:00:00 UTC
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://apps.fedoraproject.org/calendar/meeting/1999/
walters added a new comment to an issue you are following:
``
To repeat again, I am a big fan of this effort - having a nicer interactive experience is great! The cockpit guys were working on something similar to what CoreOS does with displaying the host IP addresses in the console too.
But the PAM and update stacks are about some of the most senstitive/critical aspects of the OS, and we have to be really careful when tying them together.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/160