Bug 1312422

Summary: installing the custom CA cert from satellite 6 results in restarting a running docker service
Product: Red Hat Satellite Reporter: Jim Lyle <jlyle>
Component: InstallationAssignee: Stephen Benjamin <stbenjam>
Status: CLOSED ERRATA QA Contact: Sanket Jagtap <sjagtap>
Severity: high Docs Contact:
Priority: high    
Version: 6.1.0CC: amith.patil, bbuckingham, bkearney, cduryee, dnunes, dornelas, egolov, ehelms, jcallaha, jlyle, mmithaiw, phess, sellis, sjagtap, stbenjam, vgrosu, xdmoon
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tfm-rubygem-katello-3.4.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-21 17:31:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1115190, 1186913    

Description Jim Lyle 2016-02-26 16:23:10 UTC
Description of problem:
When preparing to register a content host, installing the custom CA from the satellite via # rpm -Uvh http://sat6.lyletech.lab/pub/katello-ca-consumer-latest.noarch.rpm will restart a running docker service, resulting in any containers running on that service to stop

Version-Release number of selected component (if applicable):
katello-ca-consumer-latest.noarch.rpm

How reproducible:
always

Steps to Reproduce:

1)Configure docker repo
# sudo tee /etc/yum.repos.d/docker.repo <<-EOF
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

2) install docker
# yum install docker-engine

3) start the service
# systemctl start  docker.service

4) install the ca from satellite 6
# rpm -Uvh http://sat6.lyletech.lab/pub/katello-ca-consumer-latest.noarch.rpm


Actual results:
The docker daemon is restarted, and all running containers are stopped as a part of that

Feb 26 07:32:25 localhost systemd: Stopping Docker Application Container Engine...
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.834120906-05:00" level=info msg="Processing signal 'terminated'"
Feb 26 07:32:25 localhost systemd: Stopping Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Starting Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Listening on Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Starting Docker Application Container Engine...
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.902235735-05:00" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to dm.thinpooldev section."
Feb 26 07:32:25 localhost systemd: Device dev-disk-by\x2duuid-520e3171\x2dc715\x2d42b8\x2d8d75\x2dbeeaa17b2cdd.device appeared twice with different sysfs paths /sys/devices/virtual/block/loop0 and /sys/devices/virtual/block/dm-1
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.911991914-05:00" level=warning msg="devmapper: Base device already exists and has filesystem xfs on it. User specified filesystem  will be ignored."
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.915409421-05:00" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.915694159-05:00" level=info msg="Graph migration to content-addressability took 0.00 seconds"
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.924557829-05:00" level=info msg="Firewalld running: false"
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.959092750-05:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002059141-05:00" level=info msg="Loading containers: start."
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002096026-05:00" level=info msg="Loading containers: done."
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002103382-05:00" level=info msg="Daemon has completed initialization"
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002112994-05:00" level=info msg="Docker daemon" commit=c3959b1 execdriver=native-0.2 graphdriver=devicemapper version=1.10.2
Feb 26 07:32:26 localhost systemd: Started Docker Application Container Engine.
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.006647271-05:00" level=info msg="API listen on /var/run/docker.sock"


Expected results:
Would not expect the rpm to restart a running service


Additional info:
~~~
rpm -qp --scripts katello-ca-consumer-latest.noarch.rpm

# restart docker if it is installed and running
  if [ -f /usr/lib/systemd/system/docker.service ]; then
    systemctl status docker >/dev/null && \
    systemctl restart docker >/dev/null 2&>1
  elif [ -f /etc/init.d/docker ]; then
    service docker status >/dev/null && \
    service docker restart >/dev/null 2&>1
~~~

Perhaps remove this behavior from the RPM, and we could update the docs telling users they will need to restart the docker service prior to being able to build containers with Satellite?

Comment 1 Bryan Kearney 2016-04-08 15:23:15 UTC
Is there a better behaviour? I ask because without the restart, the docker client will not against the satellite.

Comment 2 Jim Lyle 2016-04-08 15:28:01 UTC
(In reply to Bryan Kearney from comment #1)
> Is there a better behaviour? I ask because without the restart, the docker
> client will not against the satellite.

Agreed, but this restart of the service should be in the users hands IMO, not automated through a seemingly innocuous action.  I also have a docs BZ open to at least warn the users of such action.

Perhaps a combination of removing the automated restart and letting the users know what a restart of the service is required prior to using docker from the sat?

Thanks,

Jim

Comment 5 Steven Ellis 2017-03-16 02:16:54 UTC
Any reason why this ticket is internal only?

Comment 8 Stephen Benjamin 2017-04-13 15:27:35 UTC
Created redmine issue http://projects.theforeman.org/issues/19271 from this bug

Comment 11 Satellite Program 2017-05-25 18:17:10 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19271 has been resolved.

Comment 12 Amith Patil 2017-07-26 04:26:18 UTC
We tried to migrate satellite clients from 6.2.8 to 6.2.10 and it did affect the production environment. Any timeline on the fixure please?

Comment 13 Sanket Jagtap 2017-12-11 15:40:23 UTC
Build : Satellite 6.3.0 Snap 28

Docker service was not restarted, when installing katello ca on registering client

docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
b80373a43aa8        fedora              "bash"              14 minutes ago      Up 13 minutes                           pedantic_goldberg
959567ed2947        fedora              "bash"              18 minutes ago      Up 12 minutes                           gifted_northcutt
[root@bkr-hv01-guest27 ~]# rpm -Uvh http://qe-capsule-feature-rhel6/pub/katello-ca-consumer-latest.noarch.rpm
Retrieving http://qe-capsule-feature-rhel6.capqe/pub/katello-ca-consumer-latest.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:katello-ca-consumer-qe-capsule-fe################################# [100%]
[root@bkr-hv01-guest27 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
b80373a43aa8        fedora              "bash"              15 minutes ago      Up 14 minutes                           pedantic_goldberg
959567ed2947        fedora              "bash"              19 minutes ago      Up 13 minutes                           gifted_northcutt

Comment 14 Bryan Kearney 2018-02-21 17:31:45 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336

Comment 16 Vlada Grosu 2019-11-04 16:48:20 UTC
Hi Stephen,

It seems that at the time that this bug was opened, the documentation procedure that describes how to register a host to Red Hat Satellite 6 was edited as well to warn that: 
"Any running Docker Daemons are restarted." [1]

Since then, this behaviour has been altered (and changes were tracked in this ticket), and the Docker service is no longer restarted. The documentation has not been updated to reflect that.

I am currently working on BZ#1764591 that requests we remove that information for Satellite docs versions 6.3, 6.4, 6.5, and 6.6.  

I just wanted to check with you if there is any other information that must be updated as a result of these changes. Perhaps a recommendation for when in the process of registering a host to Satellite to manually restart the Docker service, if required at all. 

Many thanks!

Kind regards,
Vlada



[1] - https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/managing_hosts/registering_hosts#registering-a-host-to-satellite

Comment 17 Stephen Benjamin 2019-11-04 16:51:30 UTC
Hi Vlada,

I'm no longer on the Satellite team and I'm not aware of the current status of this.  I would try contacting satellite6-list or asking on IRC.

Thanks!