Ocata -> Pike undercloud upgrade: stack user is not able to connect to docker daemon after undercloud upgrade

[Marius Cornea]

Ocata -> Pike undercloud upgrade: stack user is not able to connect to docker daemon after undercloud upgrade:

[stack@undercloud-0 ~]$ openstack undercloud upgrade

#############################################################################
Undercloud upgrade complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$
[stack@undercloud-0 ~]$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

After exiting the current shell session it is able to connect to the daemon:

[stack@undercloud-0 ~]$ logout
[root@undercloud-0 ~]# su - stack
Last login: Wed Jun 21 09:42:25 UTC 2017 on pts/2
[stack@undercloud-0 ~]$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

[Brent Eagles (beagles)]

stack user is added to docker group during upgrade/install, but group membership will not take effect until stack user logs out and back in or the host is restarted.

[Sofer Athlan-Guyot (sofer-athlan-guyot)]

Hi,

there is no proper solution to this. There is only one way to have the group taken into account for the current shell after modifying the user's group membership:

  newgrp docker # start a subshell whose group is docker
  newgrp stack # start a subshell whose group is stack

in that last subshell you can directly "docker ps" without reloging.

The problem is that it would only work if we keep the process where we triggers those commands in a shell opened as a child of the undercloud.py command.

One side effect will be that the history of the user will be as it was before his/her last login which might surprise the user.

The other is that the user will be in a subshell of the still running openstack undercloud command, which doesn't /feel/ right.

One last issue is that in automation the undercloud command would appears like a never ending one.

So I'm open to discussion, but beside telling adding a comment telling the user that he/she needs to login/logout I'm not sure there is a proper solution.

[Emilien Macchi (emilienm)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, PIKE, QUEENS, ROCKY, STEIN).
  Valid example: CONFIRMED FOR: FUTURE