ausil reported a new issue against the project: `atomic-wg` that you are following:
``
@releng had setup a atomic-ci tree based on the rawhide buildroot to enable a place for quick availability to test rawhide builds. per https://pagure.io/releng/pull-request/7094 it had been broken for the last 3 months. I would like for it to be evaluated and either be something cared about and used, setting up automated testing, or something we nuke from orbit due to no longer needing to be used.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/349
dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
I started [a thread](https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-April/msg00022.html) some time ago on including firewalld in atomic host. I don't believe we received any major objections there so I'm going to propose we move forward with including it in the host.
Some highlights from the mail thread:
- good for new users
since docker adds iptables rules dynamically it's really hard to properly get an iptables config that accurately reflects the rules you want to add without including the dynamic rules docker adds. Also if you do get a config that works and apply it while the system is running then you lost the dynamic rules docker added.
- good for openshift origin / kubernetes
From @jdetiber : *The iptables-based management that is done in openshift-ansible has always been a hack that was only meant to be a stopgap until firewalld was fully supported up and down the entire stack. There are way too many edge cases that could cause issues with the create/save/restore process. We tried to limit those by using a dedicated chain for openshift-ansible rules, but having another process modify rules without using '-w' or other modifications to the firewall could inadvertently be persisted with the iptables-save.*
- make sure we avoid the default zones/policies from firewalld
from ben breard on list: if we include it we would want to *clean up the absurd default zones & policies and have something relevant for AH out of the box*
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/372
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
1. wrote Fedora-Atomic-ostree-x86_64-26-20171003.0.iso to usb key (used in prior tests)
2. ran kickstart install of Atomic using my standard f26 kickstart
3. install ran
4. On rebook, system goes through bootup messages and dmesg for around 20 seconds, then without warning reboots. This cycle continues as long as I let it (I counted 5 cycles, then turned it off).
5. Tested with a new USB key and a different minnowboard. Same result.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/345
andreasn reported a new issue against the project: `atomic-wg` that you are following:
``
The website says "Fedora Atomic", but the uses branding that says "Fedora Cloud"
<!!image>
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/385
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
Article Title: Managing Fedora 27 Atomic with Cockpit
Deadline: December 1
Publication: Project Atomic Blog OR Fedora Community Blog
Priority: Nice To Have
Would be great to have a blog post, with pictures/videos, showing how to manage some of Atomic's particular capabilities (containers, ostree layers, etc.) with the latest Cockpit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/358
dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
This is needed for (including firewalld in atomic host)[https://pagure.io/atomic-wg/issue/372]. Basically right now anaconda will always enable firewalld on the host if firewalld is installed. Since we want to include firewalld in atomic host, but we want to leave it disabled by default, then we need anaconda to leave the system alone and not enable or disable it.
We need a `firewall --use-system-defaults` flag inside anaconda for this.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/401
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
The current list of members, carried over from the Cloud SIG, is here:
https://fedoraproject.org/wiki/Atomic_WG#Working_Group_Members_and_Points_o…
Things we need to change:
1. Who should we remove? Are jsmith and nzwulfin active anymore?
2. Who needs to be added? Jlebon? ashcrow?
QUORUM ISSUE:
We currently list meeting quorum as 51% of all members. With our open membership, though, that means that we need at least 11 people at a Fedora Atomic meeting to make decisions. We need to either lower that threshold (I suggest six) or we need to restrict membership in the WG.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/363
smilner opened a new pull-request against the project: `atomic-wg` that you are following:
``
Update manual steps for releasing atomic host
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/pull-request/397
jberkus reported a new issue against the project: `atomic-wg` that you are following:
``
Currently, we ship docker in the base image for Fedora Atomic Host. With the release of CRI-O, as well as the issues around docker versions, one possible solution is to ship only runc with the base Atomic Host, and make container runtimes installable as system containers. If we don't move docker to a system container, there's a strong argument to also ship CRI-O as part of the base image.
Arguments in favor of System Containers for CRs:
* minimizes the base system image
* helps deal with docker/containerd versioning issues
* doesn't require users to ship container runtimes they don't want
* consistent with our general modularity approach
* puts CRI-O/docker on a separate upgrade cycle, which can help around kube/openshift updates
* allows community to add other runtimes if they want (e.g. Rkt)
Arguments against using System Containers for CRs:
* extra step (or two) for new user startup
* total disk size for atomic + cri-o + docker will actually be larger
* not sure if all things docker work as a system container
* puts docker/CRI-O on a separate upgrade cycle, which could break around kernel updates
Discuss!
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/360
smilner reported a new issue against the project: `atomic-wg` that you are following:
``
Having buildah available in some for for Atomic Host seems to make sense. How should/would we do this? Options include:
- part of the base compose
- as a container itself
- require it be installed via rpm layering
/cc @nalin @dwalsh @sdodson @dustymabe @miabbott
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/402