[SRU] keystone-signing folders fill /tmp and seriously slow down reboots

[Matt Fischer]

[Impact]

During a night maintenance and reboot of a control (non-keystone node) that had been up for around 300 days, we found that we have over 144k keystone-signing- folders in /tmp. This caused the maintenance window to be missed because it took so long to clean /tmp on reboot. It is my understanding that these folders are for PKI. We don't use PKI and would like to the option to disable the creation of these folders.

[PROD] root@control-002:/tmp# ls -al | grep keystone-sign | wc -l
144200

more info, the folders are owned by non-keystone services, mainly glance for us:

drwx------ 2 glance glance 4096 Jul 9 2015 keystone-signing-zZocUc
drwx------ 2 glance glance 4096 Jul 20 07:55 keystone-signing-ZZOibD
drwx------ 2 designate designate 4096 May 26 2015 keystone-signing-ZZoKgT
drwx------ 2 glance glance 4096 Jul 14 2015 keystone-signing-zzOmtb
drwx------ 2 glance glance 4096 Jul 12 2015 keystone-signing-zzOubp
drwx------ 2 glance glance 4096 Jul 15 17:22 keystone-signing-zzpD6x
drwx------ 2 designate designate 4096 Jun 9 2015 keystone-signing-ZzPeNQ
drwx------ 2 glance glance 4096 Jul 2 2015 keystone-signing-ZZPJ4H
drwx------ 2 glance glance 4096 Jul 9 2015 keystone-signing-zZPnd0
drwx------ 2 designate designate 4096 May 20 2015 keystone-signing-ZZQK3i
drwx------ 2 glance glance 4096 Jun 30 2015 keystone-signing-ZZQmEI

[Test Case]

See above.

[Regression Potential]

The fix is contained in an upstream stable point release which we're releasing to ubuntu xenial. The regression potential is fairly minimal since upstream is very careful with what gets into stable point releases.

[David Stanek (dstanek)]

I've check a few of my environments and I have the same problem.

[David Stanek (dstanek)]

The code for creating the signing dir[1] is used by the auth_token middleware and at first glance appears to create the directory aggressively without knowing if it will actually be used. This is silly since it appears to only be used for PKI (or at least that's what the config option documentation implies).

A couple possible solutions in the code are:
  - to wait until first use to create, but we still don't have a good way to cleanup.
  - nothing, but push deployers to use something more standard and under their control like /var/run/keystone/
  - nothing and wait for it to be deleted once PKI is deprecated

@Matt: setting your keystone_authtoken/signing_dir in your {service}.conf files to something like /var/run/{service} should stop it from creating temporary directories.

1. https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_signing_dir.py
2. https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L685

[Matt Fischer (mfisch)]

So I think with the work-around you've provided we can go with the 3rd option and let it die.

One small issue is going to be that each service will want a dir owned by itself [1] and will warn, but I can live with that and just make one generic directory. Otherwise it's an orchestration nightmare.

[1] https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_signing_dir.py#L75-L76

I will update here once I see how it works.

[Matt Fischer (mfisch)]

I ended up just setting the folder to /var/run/$service since that folder exists when the service starts and has the right owner.

With puppet:
  cinder_config {
    'keystone_authtoken/signing_dir': value => '/var/run/cinder',
  }
  glance_api_config {
    'keystone_authtoken/signing_dir': value => '/var/run/glance',
  }
  glance_registry_config {
    'keystone_authtoken/signing_dir': value => '/var/run/glance',
  }
  neutron_config {
    'keystone_authtoken/signing_dir': value => '/var/run/neutron',
  }

We run other services in docker, which wont have this issue, but others will need to set nova, heat, and designate (amongst others) in a similar way.

[Guang Yee (guang-yee)]

I think we should fix this in keystonemiddleware instead. Asking all its dependents to make the change seem a bit too much. I vote for lazy loading. If PKI token is never used, those dirs will never be created in the first place.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/304255

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/304255
Committed: https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=0f426e7f9e86385cab698f73d6ecb1d8e6b4898a
Submitter: Jenkins
Branch: master

commit 0f426e7f9e86385cab698f73d6ecb1d8e6b4898a
Author: Colleen Murphy <email address hidden>
Date: Mon Apr 11 10:38:34 2016 -0700

    Create signing_dir upon first usage

    Without this patch, if a signing_dir value is not provided in the
    keystone_authtoken section for a given service, keystonemiddleware will
    create a secure temporary directory upon startup. For users not using
    the 'pki' pr 'pkiz' token providers, this is unnecessary and causes
    /tmp to fill up needlessly. This patch moves the directory
    creation out of SigningDirectory.__init__ and into
    SigningDirectory.calc_path, so that the first time calc_path is called,
    the directory is created. If the user has provided the directory name,
    we still log that and verify the directory at __init__. If the temp
    directory must be created, we log and verify that only once at the time
    of creation.

    Change-Id: I501d96d35bcf0039d2f5c5987471f496fc830f61
    Closes-bug: #1533724

[Steve Martinelli (stevemar)]

backport to mitaka?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/304924

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/304924
Committed: https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=c34f4cc37539a8491f98142ec728261786c8df37
Submitter: Jenkins
Branch: stable/mitaka

commit c34f4cc37539a8491f98142ec728261786c8df37
Author: Colleen Murphy <email address hidden>
Date: Mon Apr 11 10:38:34 2016 -0700

    Create signing_dir upon first usage

    Without this patch, if a signing_dir value is not provided in the
    keystone_authtoken section for a given service, keystonemiddleware will
    create a secure temporary directory upon startup. For users not using
    the 'pki' pr 'pkiz' token providers, this is unnecessary and causes
    /tmp to fill up needlessly. This patch moves the directory
    creation out of SigningDirectory.__init__ and into
    SigningDirectory.calc_path, so that the first time calc_path is called,
    the directory is created. If the user has provided the directory name,
    we still log that and verify the directory at __init__. If the temp
    directory must be created, we log and verify that only once at the time
    of creation.

    Change-Id: I501d96d35bcf0039d2f5c5987471f496fc830f61
    Closes-bug: #1533724
    (cherry picked from commit 0f426e7f9e86385cab698f73d6ecb1d8e6b4898a)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/keystonemiddleware 4.5.0 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/keystonemiddleware 4.4.1 release.

[Brian Murray (brian-murray)]

Hello Matt, or anyone else affected,

Accepted python-keystonemiddleware into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-keystonemiddleware/4.4.1-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[James Page (james-page)]

Hello Matt, or anyone else affected,

Accepted python-keystonemiddleware into mitaka-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:mitaka-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-mitaka-needed to verification-mitaka-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-mitaka-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Corey Bryant (corey.bryant)]

Hello Brian and James,

python-keystonemiddleware 4.4.1-0ubuntu1 and 4.4.1-0ubuntu1~cloud0 have been tested successfully.

Thanks,
Corey

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-keystonemiddleware - 4.4.1-0ubuntu1

---------------
python-keystonemiddleware (4.4.1-0ubuntu1) xenial; urgency=medium

  * New upstream point release (LP: #1533724).
  * d/gbp.conf: Update debian-branch to ubuntu/mitaka.
  * d/control: Update maintainer to Ubuntu Developers.

 -- Corey Bryant <email address hidden> Mon, 11 Jul 2016 09:07:04 -0400

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for python-keystonemiddleware has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[James Page (james-page)]

The verification of the Stable Release Update for python-keystonemiddleware has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[James Page (james-page)]

This bug was fixed in the package python-keystonemiddleware - 4.4.1-0ubuntu1~cloud0
---------------

 python-keystonemiddleware (4.4.1-0ubuntu1~cloud0) trusty-mitaka; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 python-keystonemiddleware (4.4.1-0ubuntu1) xenial; urgency=medium
 .
   * New upstream point release (LP: #1533724).
   * d/gbp.conf: Update debian-branch to ubuntu/mitaka.
   * d/control: Update maintainer to Ubuntu Developers.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystonemiddleware 4.4.1 release.