Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake
On 2021-05-20 08:51:00 +0200, Thomas Goirand wrote: > On 5/19/21 9:21 PM, Sebastian Ramacher wrote: > > Control: tags -1 moreinfo > > > > On 2021-05-07 10:56:51 +0200, Thomas Goirand wrote: > >> Package: release.debian.org > >> Severity: normal > >> > >> Hi, > >> > >> I need to discuss with the release team what to do in order to address > >> this bug: https://bugs.debian.org/987904 > >> > >> What happens is that each Horizon plugin is installing a bunch of python > >> files under /etc/openstack-dashboard/enable. > >> > >> When an Horizon plugin is removed, as the enable folder is in /etc, the > >> enable files of the plugins aren't removed. As a consequence, whenever > >> Horizon attemps to list its plugins (for example, when it tries to do a > >> "collect static" operation, which is kind of compiling all the JS files > >> into a single one, each time a plugin is added/removed or when Horizon > >> upgrades), it just fails, because the files in the enable folder are > >> referencing Python modules that do not exist anymore (since the plugin > >> package has been removed). > >> > >> The solution to fix this is strait forward: replace our symlink in > >> /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder, > >> and push the enable files in there instead of /etc. This way, the plugins > >> removal will also remove the enable files. > >> > >> The problem is that there are 20 Horizon plugins in Debian, and at this > >> point in the release cycle, it doesn't feel like it is a good time to > >> update 20 packages. > > > > Maybe I am missing some of the context, but it appears to me that in > > if the case the plugin package was removed but not purged, a > > ModuleNotFoundError is raised. So, wouldn't it be sufficient for horizon > > to ignore those plugins that raise a ModuleNotFoundError? > > > > Cheers > > Hi Sebastian, > > Thanks for your answer in this bug, I was desperate for an answer! :) > > I tried to do as Andreas suggested, and then it fails later on, the code > is harder to understand than just this. > > At this point, I've been able to stage the fix in Experimental, and I am > confident that I can backport the fixes to unstable. It's just a large > amount of packages to patch, but I'm confident I can do it. > > Your thoughts? Sorry for slacking on a reply. If you still feel that you can do that before the full freeze, please go ahead. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake
On 5/19/21 9:21 PM, Sebastian Ramacher wrote: > Control: tags -1 moreinfo > > On 2021-05-07 10:56:51 +0200, Thomas Goirand wrote: >> Package: release.debian.org >> Severity: normal >> >> Hi, >> >> I need to discuss with the release team what to do in order to address >> this bug: https://bugs.debian.org/987904 >> >> What happens is that each Horizon plugin is installing a bunch of python >> files under /etc/openstack-dashboard/enable. >> >> When an Horizon plugin is removed, as the enable folder is in /etc, the >> enable files of the plugins aren't removed. As a consequence, whenever >> Horizon attemps to list its plugins (for example, when it tries to do a >> "collect static" operation, which is kind of compiling all the JS files >> into a single one, each time a plugin is added/removed or when Horizon >> upgrades), it just fails, because the files in the enable folder are >> referencing Python modules that do not exist anymore (since the plugin >> package has been removed). >> >> The solution to fix this is strait forward: replace our symlink in >> /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder, >> and push the enable files in there instead of /etc. This way, the plugins >> removal will also remove the enable files. >> >> The problem is that there are 20 Horizon plugins in Debian, and at this >> point in the release cycle, it doesn't feel like it is a good time to >> update 20 packages. > > Maybe I am missing some of the context, but it appears to me that in > if the case the plugin package was removed but not purged, a > ModuleNotFoundError is raised. So, wouldn't it be sufficient for horizon > to ignore those plugins that raise a ModuleNotFoundError? > > Cheers Hi Sebastian, Thanks for your answer in this bug, I was desperate for an answer! :) I tried to do as Andreas suggested, and then it fails later on, the code is harder to understand than just this. At this point, I've been able to stage the fix in Experimental, and I am confident that I can backport the fixes to unstable. It's just a large amount of packages to patch, but I'm confident I can do it. Your thoughts? Cheers, Thomas Goirand
Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake
Control: tags -1 moreinfo On 2021-05-07 10:56:51 +0200, Thomas Goirand wrote: > Package: release.debian.org > Severity: normal > > Hi, > > I need to discuss with the release team what to do in order to address > this bug: https://bugs.debian.org/987904 > > What happens is that each Horizon plugin is installing a bunch of python > files under /etc/openstack-dashboard/enable. > > When an Horizon plugin is removed, as the enable folder is in /etc, the > enable files of the plugins aren't removed. As a consequence, whenever > Horizon attemps to list its plugins (for example, when it tries to do a > "collect static" operation, which is kind of compiling all the JS files > into a single one, each time a plugin is added/removed or when Horizon > upgrades), it just fails, because the files in the enable folder are > referencing Python modules that do not exist anymore (since the plugin > package has been removed). > > The solution to fix this is strait forward: replace our symlink in > /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder, > and push the enable files in there instead of /etc. This way, the plugins > removal will also remove the enable files. > > The problem is that there are 20 Horizon plugins in Debian, and at this > point in the release cycle, it doesn't feel like it is a good time to > update 20 packages. Maybe I am missing some of the context, but it appears to me that in if the case the plugin package was removed but not purged, a ModuleNotFoundError is raised. So, wouldn't it be sufficient for horizon to ignore those plugins that raise a ModuleNotFoundError? Cheers > > So in my point of view, what we can do now is: > - tag #987904 as bullseye-ignore > - add a warning in the release notes that Horizon plugins should never > be just removed, but should be *purged*, to avoid the problem > > In the mean while, I'll fix the Horizon packaging in Experimental, and > see how it goes. > > Dear release team, please let share your view on this bug. > I remain available if you need more explanations. > > Cheers, > > Thomas Goirand (zigo) > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake
Package: release.debian.org Severity: normal Hi, I need to discuss with the release team what to do in order to address this bug: https://bugs.debian.org/987904 What happens is that each Horizon plugin is installing a bunch of python files under /etc/openstack-dashboard/enable. When an Horizon plugin is removed, as the enable folder is in /etc, the enable files of the plugins aren't removed. As a consequence, whenever Horizon attemps to list its plugins (for example, when it tries to do a "collect static" operation, which is kind of compiling all the JS files into a single one, each time a plugin is added/removed or when Horizon upgrades), it just fails, because the files in the enable folder are referencing Python modules that do not exist anymore (since the plugin package has been removed). The solution to fix this is strait forward: replace our symlink in /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder, and push the enable files in there instead of /etc. This way, the plugins removal will also remove the enable files. The problem is that there are 20 Horizon plugins in Debian, and at this point in the release cycle, it doesn't feel like it is a good time to update 20 packages. So in my point of view, what we can do now is: - tag #987904 as bullseye-ignore - add a warning in the release notes that Horizon plugins should never be just removed, but should be *purged*, to avoid the problem In the mean while, I'll fix the Horizon packaging in Experimental, and see how it goes. Dear release team, please let share your view on this bug. I remain available if you need more explanations. Cheers, Thomas Goirand (zigo)
