rhel7:pet On Fri, Oct 21, 2016 at 12:48 PM, Daniel J Walsh <dwa...@redhat.com> wrote:
> Well we got to figure out how/if upstart can run in a non-privileged > container. but yes. > > rhel7-init or rhel7-system > > rhel6-init or rhel6-system > > Perhaps > > On 10/21/2016 12:42 PM, Daniel Riek wrote: > > We will need the same for rhel6 (with upstart). We should think about a > consistent naming model. > > D. > > On Oct 21, 2016 12:38 PM, "Mrunal Patel" <mpa...@redhat.com> wrote: > >> >> >> On Fri, Oct 21, 2016 at 9:29 AM, Daniel J Walsh <dwa...@redhat.com> >> wrote: >> >>> That might make the most sense. >>> >>> RHEL7 == Base Image >>> >>> RHEL7Systemd == BaseImage + Config to run systemd as pid1. >>> >> +1, maybe call it RHEL7-system image? >> >>> >>> >>> >>> On 10/21/2016 12:26 PM, Daniel Riek wrote: >>> >>> Question: should we separate a true minimal base image that as default >>> run's a shell and the default iamge that runs systemd and behaves more like >>> a linux system? >>> >>> On Fri, Oct 21, 2016 at 12:02 PM, Clayton Coleman <ccole...@redhat.com> >>> wrote: >>> >>>> This seems like a breaking API change (as you note) for downstream >>>> consumers. Seems more correct to create a new image for that. >>>> >>>> > On Oct 21, 2016, at 11:50 AM, Daniel J Walsh <dwa...@redhat.com> >>>> wrote: >>>> > >>>> > If we make this change, we would want to do it in Fedora and Centos >>>> also. >>>> > >>>> > https://bugzilla.redhat.com/show_bug.cgi?id=1387282 >>>> > >>>> > The benefits of making this change are that people new to containers >>>> > could follow a simple workflow similar to what the do on the OS, where >>>> > all they need to do is install an rpm service and enable and it is >>>> ready >>>> > to go. >>>> > >>>> > >>>> > # cat Dockerfile >>>> > >>>> > FROM rhel7 >>>> > >>>> > RUN dnf -y install httpd; systemctl enabled httpd >>>> > >>>> > ADD MYAPP / >>>> > >>>> > >>>> > # docker build -t MYAPP . >>>> > >>>> > >>>> > And they are done. Now if they run their container >>>> > >>>> > docker run -d MYAPP >>>> > >>>> > And their app runs with systemd/journald and httpd with their app >>>> runnin >>>> > inside of it. >>>> > >>>> > >>>> > For users who don't want to use systemd, they would just override the >>>> > CMD field and their container would work fine. >>>> > >>>> > Since the current default is bash, they would need to do this anyways. >>>> > >>>> > >>>> > A couple of things will break, >>>> > >>>> > docker run -ti rhel7 >>>> > >>>> > Currently runs a shell. With the new change, systemd would start up >>>> > inside of the contaienr. >>>> > >>>> > >>>> > Users who want a shell would need to execute >>>> > >>>> > docker run -ti rhel7 /bin/sh >>>> > >>>> > (I always do this anyways, but I guess some people do not) >>>> > >>>> > >>>> > The other big issue is on stopping of containers. docker stop >>>> currently >>>> > defaults to sending SIGTERM to the pid 1 of the container. >>>> > >>>> > systemd requires that SIGRTMIN+3 be sent to it to close down properly. >>>> > If we want to have systemd work by default, we would >>>> > >>>> > need to change the default SIGSTOP of the base image. This means any >>>> > application based on the base image that does not >>>> > >>>> > override the SIGSTOP would get SIGRTMIN+3. Most apps will die when >>>> they >>>> > get this signal, but if the App had a signal handler for >>>> > >>>> > SIGTERM, the signal handler will not work correctly. >>>> > >>>> > >>>> > Adding >>>> > >>>> > SIGSTOP SIGTERM >>>> > >>>> > to a Dockerfile would fix the issue, but it will cause unexpected >>>> > breakage. I don't see an easy solution for this. >>>> > >>>> > >>>> > >>>> >>>> >>> >>> >>> -- >>> Daniel Riek <r...@redhat.com> >>> * Sr. Director Systems Design & Engineering >>> * Red Hat Inc, Tel. +1-617-863-6776 >>> >>> >>> >> > -- -- Jeremy Eder
