Sorry hit send too soon. other thing i was going to mention is if we have 2 bases, then the minimal one should take advantage of Colin's research into yum micro (I forget the exact name).
On Fri, Oct 21, 2016 at 12:52 PM, Jeremy Eder <je...@redhat.com> wrote: > 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 > -- -- Jeremy Eder
