On Wed, Jul 24, 2024 at 9:28 AM Francesco Di Nucci <
francesco.dinucci(a)na.infn.it> wrote:
Thank you both,
do you think this should be fixed by the Puppet module or in the package
itself?
Regards
Francesco
On 7/22/24 16:22, thomas(a)goirand.fr wrote:
>
> On Jul 22, 2024 8:56 PM, Radomir Dopieralski <rdopiera(a)redhat.com>
wrote:
> >
> > I think the most sensible thing to do would be to be consistent and
> have symlinks for all configuration-related files, including
> local/local_settings.d, local/enabled, and the policy files.
> > There is code in the .spec file for at least some of that, but it
> seems to be conditional for some reason.
I guess you mean:
https://github.com/rdo-packages/horizon-distgit/blob/rpm-master/python-dj...
It could be unconditionalized. My only concern is about how to manage the
upgrade.
> >
> > On Thu, Jul 11, 2024 at 9:12 AM Francesco Di Nucci
> <francesco.dinucci(a)na.infn.it> wrote:
> >>
> >> Hello,
> >>
> >> some time ago I found that on EL9 Horizon searches for extra Python
> snippets in
>
"/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.d",
> while puppet-horizon places dashboards snippets in
> "/etc/openstack-dashboard/local_settings.d", so these are not loaded.
> At the same time,
>
"/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py"
> is a symlink to "/etc/openstack-dashboard/local_settings".
> >>
> >> Of the following, what should be adopted as proper approach on a
> machine?
> >>
> >> Having symlinks to /etc/openstack-dashboard for both
> local_settings.py and local_settings.d
> >> Editing files in /usr/share/openstack-dashboard without having
symlinks
> >> Using a symlink for local_settings.py but placing snippets under
> /usr/share/openstack-dashboard
>
> Config files must be in /etc. Anything else is wrong...
>
> Thomas
>
_______________________________________________
dev mailing list -- dev(a)lists.rdoproject.org
To unsubscribe send an email to dev-leave(a)lists.rdoproject.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
To unsubscribe: %(_internal_name)s-unsubscribe@%(host_name)s