You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.
While working on #1131 I discovered that devpi didn't seem to be used by lms and cms.
From a search for the port number on GitHub, it looks like the only reference is in the configuration repo's devpi_consumer role, which creates /dev/.pip/pip.conf. (This is also mentioned in devstack's own documentation on devpi.)
The lms and cms images do not contain a /dev/.pip/pip.conf (presumably this role is not used when building the images any more) and the devpi logs do not show any traffic.
If I create the config file on lms, then the devpi logs start showing traffic
The image was originally added as a caching layer for devstack users with slow network connections, but due to inefficiencies in the Ansible-based image build it ends up at 1.69 GB, mitigating most or all of the package caching benefits. And the cache is really only useful when running make upgrade in multiple services with similar dependencies or repeatedly running make upgrade on the same old base service image.
Given that the devpi image itself is causing size and CPU issues and the benefits are seemingly small and hard to quantify, let's remove this from devstack.
The text was updated successfully, but these errors were encountered:
While working on #1131 I discovered that devpi didn't seem to be used by lms and cms.
devpi_consumer
role, which creates/dev/.pip/pip.conf
. (This is also mentioned in devstack's own documentation on devpi.)/dev/.pip/pip.conf
(presumably this role is not used when building the images any more) and the devpi logs do not show any traffic.The image was originally added as a caching layer for devstack users with slow network connections, but due to inefficiencies in the Ansible-based image build it ends up at 1.69 GB, mitigating most or all of the package caching benefits. And the cache is really only useful when running
make upgrade
in multiple services with similar dependencies or repeatedly runningmake upgrade
on the same old base service image.Given that the devpi image itself is causing size and CPU issues and the benefits are seemingly small and hard to quantify, let's remove this from devstack.
The text was updated successfully, but these errors were encountered: