Fwd: Invitation: Hack Day @ Tue Dec 20, 2016 (jberkus@redhat.com)
by Josh Berkus
Given that we're working with Openshift-Ansible, as many of us as
possible should participate in this.
-------- Forwarded Message --------
Subject: Invitation: Hack Day @ Tue Dec 20, 2016 (jberkus(a)redhat.com)
Date: Fri, 16 Dec 2016 23:38:18 +0000
From: Daniel McPherson <dmcphers(a)redhat.com>
Reply-To: Daniel McPherson <dmcphers(a)redhat.com>
To: jberkus(a)redhat.com
7 years, 4 months
Re: [atomic-devel] Fedora 26 change: using overlayfs as default
by Daniel J Walsh
On 12/16/2016 03:16 AM, Marius Vollmer wrote:
> Vivek Goyal <vgoyal(a)redhat.com> writes:
>
>> [...] And if overlayfs does not work for a user, switching back to
>> devmapper should be easy.
>>
>> - atomic storage reset
>> - edit /etc/sysconfig/docker-storage-setup and set
>> STORAGE_DRIVER=devicemapper
>> - restart docker
> Should we have a button in Cockpit to do this?
>
Yes I think have cockpit provide mechanisms to switch from one store to
another. And to preserve
state while doing it would be nice.
7 years, 4 months
Re: Announcement: Fedora Docker Layered Image Build Service is GO!
by Adam Miller
On Tue, Dec 13, 2016 at 2:52 PM, Igor Gnatenko <ignatenko(a)redhat.com> wrote:
> On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
> <maxamillion(a)fedoraproject.org> wrote:
>> It is with great pleasure that the Fedora Project Announces the availability
>> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
>> Community!
>>
>> With this announcement we are opening availability of the Docker Layered
>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
>> official components of Fedora. From there we will be extending an invitation
>> to all Fedora Contributors to maintain Docker Layered Image Containers for
>> official release by the Fedora Project. Currently this effort is to enable
>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
>> primary deliverable to power the future of Cloud. This is also to enable the
>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
>> becomes fundamentally more modular in nature.
>>
>> How do I get started?
>>
>> Contributors will go through a simliar process as what they currently do
>> with RPM Review Requests. There will be Container Reviews as well as
>> Container Guidelines:
>>
>> https://fedoraproject.org/wiki/Container:Review_Process
>> https://fedoraproject.org/wiki/Container:Guidelines
> Nice job!
>
> I have couple of questions:
> * why "FROM fedora:25", how do I choose version on which I want to
> base container?
The 'FROM fedora:25' line should coordinate with the branch of DistGit
you're working in. Since Docker doesn't have a mechanism like RPMs do
with macros where we can parameterize things like that, we just have
to define it for now (we may later change it to where the 'FROM
fedora:$version' is inferred and something makes a modification to the
Dockerfile before building.
> * is there containers in registry for rawhide?
There are not at this moment, only for Fedora 24 and Fedora 25. I hope
to have rawhide enabled very soon though. The layout of DistGit
branches correlated to Fedora release information fed into the Build
System is something that needs be sorted since "branched" Fedora
Releases have a version number tied to DistGit but Rawhide is
technically f26 right now. I'll update as soon as this is live.
-AdamM
>>
>> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
>> the Review Process along with input from all Fedora Contributors. This may
>> change later with the formation of a Fedora Container Committee (similar to
>> the Fedora Packaging Committee[6]).
>>
>> Please note that both the Guidelines and the Review Process are likely to
>> evolve along with the Container technologies as we move into the future so
>> we encourage community members to check the documentation for updates.
>>
>> For more information, please see the following Fedora Community Blog:
>>
>> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build...
>>
>> [0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>> [1] - https://fedoraproject.org/wiki/Cloud
>> [2] - https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
>> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
>> [4] - https://getfedora.org/en/atomic/download/
>> [5] - https://fedoraproject.org/wiki/Modularity
>> [6] - https://fedoraproject.org/wiki/Packaging_Committee
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7 years, 4 months
Re: [atomic-devel] Fedora 26 change: using overlayfs as default
by Josh Berkus
Dan, Dusty, Vivek:
So far nobody has defined (technically) the exact problem with overlayfs
and how it affects applications which want to write data inside the
container.
Note that just saying "don't use Overlay for persistent data" really
isn't good enough. Apps in containers frequently write data to places
users aren't aware of, such as writing port information to /var/run.
While this data may not be important to the user, the app will fail if
it errors out.
Pushing a change which will cause 30% of a user's containers to start
failing for reasons which are opaque to them is not something we should
do lightly.
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
7 years, 4 months
meeting minutes
by Josh Berkus
===================================
#fedora-meeting-1: fedora_atomic_wg
===================================
Meeting started by jberkus at 17:02:34 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-12-14/fedora_atom...
.
Meeting summary
---------------
* Roll Call (jberkus, 17:02:55)
* roshi is awesome, he helps out with cloud/atomic WG and will be back
soon (dustymabe, 17:06:44)
* FDLIBS (jberkus, 17:07:06)
* LINK: https://fedoraproject.org/wiki/Container:Review_Process
(misc, 17:13:13)
* Kubenetes in Fedora Atomic (jberkus, 17:26:45)
* ACTION: add kubernetes packages back into the base OStree for FAH 25
(jberkus, 17:30:41)
* ACTION: jberkus to create tickets for prerequisites for removing
kube packages from base ostree (jberkus, 17:31:09)
* ISO Images (jberkus, 17:32:50)
* LINK: https://pagure.io/atomic-wg/issue/185 (jberkus, 17:33:05)
* ACTION: dustymabe to follow-up on merge of UEFI patch into anaconda
(jberkus, 17:37:03)
* ACTION: dustymabe, walters to discuss new release process at
beginning of calendar year 2017 (jberkus, 17:41:53)
* other issues (jberkus, 17:42:23)
* LINK: https://getfedora.org/en/atomic/download/ (jbrooks,
17:45:27)
* LINK: https://pagure.io/atomic-wg/issue/180 (jberkus, 17:51:05)
* open floor (jberkus, 17:53:25)
* ACTION: dustymabe walters jberkus to explore overlayfs writeability
issue (jberkus, 18:01:38)
* ACTION: dustymabe to blog using overlayfs in Atomic (jberkus,
18:01:47)
Meeting ended at 18:02:13 UTC.
Action Items
------------
* add kubernetes packages back into the base OStree for FAH 25
* jberkus to create tickets for prerequisites for removing kube packages
from base ostree
* dustymabe to follow-up on merge of UEFI patch into anaconda
* dustymabe, walters to discuss new release process at beginning of
calendar year 2017
* dustymabe walters jberkus to explore overlayfs writeability issue
* dustymabe to blog using overlayfs in Atomic
Action Items, by person
-----------------------
* dustymabe
* dustymabe to follow-up on merge of UEFI patch into anaconda
* dustymabe, walters to discuss new release process at beginning of
calendar year 2017
* dustymabe walters jberkus to explore overlayfs writeability issue
* dustymabe to blog using overlayfs in Atomic
* jberkus
* jberkus to create tickets for prerequisites for removing kube
packages from base ostree
* dustymabe walters jberkus to explore overlayfs writeability issue
* walters
* dustymabe, walters to discuss new release process at beginning of
calendar year 2017
* dustymabe walters jberkus to explore overlayfs writeability issue
* **UNASSIGNED**
* add kubernetes packages back into the base OStree for FAH 25
People Present (lines said)
---------------------------
* jberkus (111)
* dustymabe (62)
* maxamillion (35)
* roshi (31)
* zodbot (19)
* walters (16)
* jbrooks (14)
* misc (11)
* trishnag (6)
* bowlofeggs (2)
* tflink (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
--
Josh Berkus
Project Atomic
Red Hat OSAS
7 years, 4 months
Re: [atomic-devel] Fedora 26 change: using overlayfs as default
by Dusty Mabe
On 12/14/2016 07:51 AM, Daniel J Walsh wrote:
>
> I have heard that the issue with yum/rpm is being worked on in the kernel.
> For those that to not know the issue is for programs that open a file twice
> once for readonly and then later for read/write. In the first open the file is
> on the lower file system. When you open the second time for read/write,
> Overlay does a COPY/UP which creates a separate file. The program thinks
> that it has the same file opened twice, but it actually has two different files
> open.
That is great information. Is there an issue somewhere where we can
track the progress of the "fix"?
Dusty
7 years, 4 months
Re: [atomic-devel] Fedora 26 change: using overlayfs as default
by Dusty Mabe
On 12/13/2016 01:02 PM, Colin Walters wrote:
> On Tue, Dec 13, 2016, at 12:45 PM, Clayton Coleman wrote:
>> Are the POSIX issues in applications running on overlay mostly resolved now? I.e. if we flipped the default would be reasonably able to support a diverse range of Linux workloads without the risk that previously existed?
>
> overlayfs will never be fully POSIX compatible, but I think that's OK,
> because remember - you shouldn't use overlayfs for persistent data,
> or really anything that's not code/config files (and we want to get
> to where that's overlayfs-type semantics for builds, and read-only
> for deployment). Data should be in Kube persistent volumes etc.
>
> I think the thing to focus on is tools that are run during builds - the
> yum-in-overlayfs bug is a good example, because the RPM database
> *is* a database which is the type of workload that's going to
> be sensitive to the overlayfs semantics. How many of those
> are there? Probably not many, I suspect most of the compat
> issues with userspace have been shaken out by now.
>
> (But long term we may end up in a situation where people
> who want to run e.g. rhel5's yum in a container need to
> somehow fall back to devmapper)
>
So if we were to propose the "overlayfs as default" change for all of
Fedora, would you consider that to be problematic considering your
"you shouldn't use overlayfs for persistent data," stance. In the case
of a user running pet containers on their local desktop environment,
what is the sentiment?
Dusty
7 years, 4 months