Bug 1312422 - installing the custom CA cert from satellite 6 results in restarting a running docker service
installing the custom CA cert from satellite 6 results in restarting a runnin...
Status: ON_QA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Installer (Show other bugs)
6.1.0
Unspecified Unspecified
high Severity high (vote)
: GA
: --
Assigned To: Stephen Benjamin
Katello QA List
: Triaged
Depends On:
Blocks: GSS_Sat6Beta_Tracker/GSS_Sat6_Tracker 1186913
  Show dependency treegraph
 
Reported: 2016-02-26 11:23 EST by Jim Lyle
Modified: 2017-09-16 01:42 EDT (History)
13 users (show)

See Also:
Fixed In Version: tfm-rubygem-katello-3.4.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2179911 None None None 2017-06-16 18:01 EDT
Foreman Issue Tracker 19271 None None None 2017-04-13 11:27 EDT

  None (edit)
Description Jim Lyle 2016-02-26 11:23:10 EST
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 11:23:15 EDT
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 11:28:01 EDT
(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-15 22:16:54 EDT
Any reason why this ticket is internal only?
Comment 8 Stephen Benjamin 2017-04-13 11:27:35 EDT
Created redmine issue http://projects.theforeman.org/issues/19271 from this bug
Comment 11 pm-sat@redhat.com 2017-05-25 14:17:10 EDT
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 00:26:18 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.