Re: [atomic-devel] Storage for system containers
The only issue I have with using the same location is that when troubleshooting, it's fairly common to wipe the storage pool. I think we'd want users to rm -rf /var/lib/docker without worrying about removing system containers. Is this still an issue after the current partition scheme moves to OverlayFS? On Mon, Apr 24, 2017 at 12:56 PM, Dusty Mabe wrote: > NOTE: please reply-all when responding to this message > > > In Fedora Atomic Host if we use system containers as advertised > we end up using `atomic pull --storage ostree` which by default > throws images into /var/lib/containers/atomic/. This is on the > root filesystem which may be undesirable. > > Since in Fedora 26 the new version of container-storage-setup allows > us greater control over a "CONTAINER_ROOT" should we consider trying > to make sure both ostree storage and docker storage get placed under > that CONTAINER_ROOT? > > The current default [1] is to just mount the CONTAINER_ROOT on > /var/lib/docker. > > Dusty > > [1] https://src.fedoraproject.org/cgit/rpms/docker.git/tree/ > docker.spec?h=f26#n535 > > -- Ben Breard Sr Technology Product Manager - Linux Containers Mobile: 972-816-9081
Re: [atomic-devel] firewalld in atomic host
I'm starting to warm up to the idea of adding firewalld in Atomic Host. If we do this, it would be a requirement to clean up the absurd default zones & policies and have something relevant for AH out of the box. On Mon, Apr 24, 2017 at 9:13 PM, Jason DeTiberus wrote: > > > On Sun, Apr 23, 2017 at 11:33 PM, Dusty Mabe wrote: > >> >> >> On 04/21/2017 01:42 PM, Jason DeTiberus wrote: >> > >> > While I can see firewalld improving the situation wrt documenting how >> to add/persist firewall changes for Atomic Host (especially when using >> moby/docker), I think there is a bigger concern with firewalld being >> absent. If a user is running multiple applications that modify the host >> firewall (docker, Kubernetes, OpenShift, etc), firewalld provides a way to >> make firewall modifications in a consistent and repeatable manner, where >> iptables does not. There is the --wait flag for iptables, however any >> applications/users that are interacting with iptables will need to ensure >> they use it consistently. >> > >> >> So you are saying firewalld makes your life easier if it was >> available? >> > > Correct, 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. > > As mentioned in another reply on the thread, layered packages would allow > for firewalld to be used today, but the restart requirement adds another > level of complexity that adds the potential for non-determinism to the > OpenShift install process. Having both iptables and firewalld available in > the base would allow for parity between AH-based and non-AH-based installs. > > -- > Jason DeTiberus > -- Ben Breard Sr Technology Product Manager - Linux Containers Mobile: 972-816-9081
Re: [atomic-devel] firewalld in atomic host
On Sun, Apr 23, 2017 at 11:33 PM, Dusty Mabe wrote: > > > On 04/21/2017 01:42 PM, Jason DeTiberus wrote: > > > > While I can see firewalld improving the situation wrt documenting how to > add/persist firewall changes for Atomic Host (especially when using > moby/docker), I think there is a bigger concern with firewalld being > absent. If a user is running multiple applications that modify the host > firewall (docker, Kubernetes, OpenShift, etc), firewalld provides a way to > make firewall modifications in a consistent and repeatable manner, where > iptables does not. There is the --wait flag for iptables, however any > applications/users that are interacting with iptables will need to ensure > they use it consistently. > > > > So you are saying firewalld makes your life easier if it was > available? > Correct, 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. As mentioned in another reply on the thread, layered packages would allow for firewalld to be used today, but the restart requirement adds another level of complexity that adds the potential for non-determinism to the OpenShift install process. Having both iptables and firewalld available in the base would allow for parity between AH-based and non-AH-based installs. -- Jason DeTiberus
Re: [atomic-devel] Change to listed projects on projectatomic.io home page
On Mon, Apr 24, 2017 at 5:05 PM, Josh Berkus wrote: > Folks, > > Currently our "top 3" projects on the PA.io homepage are Atomic Host, > Atomic Registry, and AtomicApp. > > Since AtomicApp is EOL, we need to replace it on the homepage. > > I was thinking that it might be good to replace it with "Container > Libraries", that is, links to the FLIBS and Centos Container Pipeline. > Barring other ideas, I'll do that this week. +1 > > (and yes, we still plan on a total website redesign, but that's still > wating on design resources) > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS >
[atomic-devel] Change to listed projects on projectatomic.io home page
Folks, Currently our "top 3" projects on the PA.io homepage are Atomic Host, Atomic Registry, and AtomicApp. Since AtomicApp is EOL, we need to replace it on the homepage. I was thinking that it might be good to replace it with "Container Libraries", that is, links to the FLIBS and Centos Container Pipeline. Barring other ideas, I'll do that this week. (and yes, we still plan on a total website redesign, but that's still wating on design resources) -- -- Josh Berkus Project Atomic Red Hat OSAS
Re: [atomic-devel] Httpd vs. Containers
On Mon, Apr 24, 2017, at 02:18 PM, Josh Berkus wrote: > > 1. Is there a *reason* we didn't relocate the HTTPD logs to Journald > when Fedora went Systemd? It impacts performance: https://bugzilla.redhat.com/show_bug.cgi?id=963620
Re: [atomic-devel] Httpd vs. Containers
On 04/24/2017 10:43 AM, Micah Abbott wrote: > On 04/21/2017 05:34 PM, Josh Berkus wrote: >> Folks, >> >> I've been building some containers for our libraries, and I'm noticing >> that there's a serious deficiency in the standard Fedora and CentOS >> httpd packages for running them in a container, namely: >> >> httpd doesn't log to journald >> >> Our default packages for httpd still log to /var/log/httpd/ This means >> that not only can we not redirect the log output to the host (or >> kubernetes), but the container itself will grow indefinitely due to >> those log files. >> >> Given that the httpd packages should have been changed when Fedora and >> CentOS switched to systemd, I'm guessing that there's something else >> holding this back? >> >> What would people suggest is a good way to make our httpd RPMs usable in >> containers? >> > > Perhaps we should start using 'mod_journal'? > > https://httpd.apache.org/docs/trunk/mod/mod_journald.html That leaves some questions unanswered: 1. Is there a *reason* we didn't relocate the HTTPD logs to Journald when Fedora went Systemd? 2. How many other server packages do we have that don't log to Journald? As we start containerizing our entire catalog, server software which writes to anywhere other than systemd is going to become more and more of an issue. I'm trying to get a handle on the problem scope. -- -- Josh Berkus Project Atomic Red Hat OSAS
[atomic-devel] Storage for system containers
NOTE: please reply-all when responding to this message In Fedora Atomic Host if we use system containers as advertised we end up using `atomic pull --storage ostree` which by default throws images into /var/lib/containers/atomic/. This is on the root filesystem which may be undesirable. Since in Fedora 26 the new version of container-storage-setup allows us greater control over a "CONTAINER_ROOT" should we consider trying to make sure both ostree storage and docker storage get placed under that CONTAINER_ROOT? The current default [1] is to just mount the CONTAINER_ROOT on /var/lib/docker. Dusty [1] https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26#n535
Re: [atomic-devel] Httpd vs. Containers
On 04/21/2017 05:34 PM, Josh Berkus wrote: Folks, I've been building some containers for our libraries, and I'm noticing that there's a serious deficiency in the standard Fedora and CentOS httpd packages for running them in a container, namely: httpd doesn't log to journald Our default packages for httpd still log to /var/log/httpd/ This means that not only can we not redirect the log output to the host (or kubernetes), but the container itself will grow indefinitely due to those log files. Given that the httpd packages should have been changed when Fedora and CentOS switched to systemd, I'm guessing that there's something else holding this back? What would people suggest is a good way to make our httpd RPMs usable in containers? Perhaps we should start using 'mod_journal'? https://httpd.apache.org/docs/trunk/mod/mod_journald.html
Re: [atomic-devel] Httpd vs. Containers
You can just symbolic link that to /data or /tmp Or adjust config /etc/httpd/ to use /dev/stdout and /dev/stderr On Mon, Apr 24, 2017, 7:49 PM Josh Berkus wrote: > Folks, > > I've been building some containers for our libraries, and I'm noticing > that there's a serious deficiency in the standard Fedora and CentOS > httpd packages for running them in a container, namely: > >httpd doesn't log to journald > > Our default packages for httpd still log to /var/log/httpd/ This means > that not only can we not redirect the log output to the host (or > kubernetes), but the container itself will grow indefinitely due to > those log files. > > Given that the httpd packages should have been changed when Fedora and > CentOS switched to systemd, I'm guessing that there's something else > holding this back? > > What would people suggest is a good way to make our httpd RPMs usable in > containers? > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS > >
[atomic-devel] Httpd vs. Containers
Folks, I've been building some containers for our libraries, and I'm noticing that there's a serious deficiency in the standard Fedora and CentOS httpd packages for running them in a container, namely: httpd doesn't log to journald Our default packages for httpd still log to /var/log/httpd/ This means that not only can we not redirect the log output to the host (or kubernetes), but the container itself will grow indefinitely due to those log files. Given that the httpd packages should have been changed when Fedora and CentOS switched to systemd, I'm guessing that there's something else holding this back? What would people suggest is a good way to make our httpd RPMs usable in containers? -- -- Josh Berkus Project Atomic Red Hat OSAS
