[ovirt-devel] Moving configuration files to separate directory

Yaniv Bronheim ybronhei at redhat.com
Tue Aug 2 09:05:54 UTC 2016


On Tue, Aug 2, 2016 at 11:06 AM, Martin Polednik <mpolednik at redhat.com>
wrote:

> Hey devels,
>
> last week, I've been working on patch series that moves most of
> configuration and "static" files away from our source code to a dir
> called "static"[1]. (based on the previous' week VDSM weekly)
>
> Current version has static dir's layout as flat - keeping all files in
> the directory with few exceptions (mom.d and systemd). The downside of
> the approach is that we still have to rename some of the files in
> makefile due to possibility of name clashes if we had similarly named
> files (50_vdsm from sudoers and 50_vdsm anything else).
>
> There is another possibility - hierarchy within the folder. Instead of
> current structure -
>
> static
> ├── Makefile.am
> ├── limits.conf
> ├── logger.conf.in
> ├── mom.conf.in
> ├── mom.d
> │   ├── 00-defines.policy
> │   ├── 01-parameters.policy
> │   ├── 02-balloon.policy
> │   ├── 03-ksm.policy
> │   ├── 04-cputune.policy
> │   ├── 05-iotune.policy
> │   └── Makefile.am
> ├── sudoers.vdsm.in
> ├── svdsm.logger.conf.in
> ├── systemd
> │   ├── Makefile.am
> │   ├── mom-vdsm.service.in
> │   ├── supervdsmd.service.in
> │   ├── vdsm-network.service.in
> │   └── vdsmd.service.in
> ├── vdsm-bonding-modprobe.conf
> ├── vdsm-logrotate.conf
> ├── vdsm-modules-load.d.conf
> ├── vdsm-sysctl.conf
> └── vdsm.rwtab.in
>
> we could structure the directory to a corresponding subfolders over
> the system:
>
> etc
> ├── modprobe.d
> │   └── vdsm-bonding-modprobe.conf
> ├── modules-load.d
> │   └── vdsm.conf
> ├── rwtab.d
> │   └── vdsm
> ├── security
> │   └── limits.d
> │       └── 99-vdsm.conf
> ├── sudoers.d
> │   ├── 50_vdsm
> ├── sysctl.d
> │   └── vdsm.conf
> └── vdsm
>    ├── logger.conf
>    ├── logrotate
>    │   └── vdsm
>    ├── mom.conf
>    ├── mom.d
>    │   ├── 00-defines.policy
>    │   ├── 01-parameters.policy
>    │   ├── 02-balloon.policy
>    │   ├── 03-ksm.policy
>    │   ├── 04-cputune.policy
>    │   └── 05-iotune.policy
>    ├── svdsm.logger.conf
>    ├── vdsm.conf
>    └── vdsm.conf.d
>

Second approach is much better. More organized and more clean. It's more
reasonable that way for developers, and having more makefiles is not a big
deal.


> There is little downside to the second approach, that is more code is
> added to VDSM in a sense that more makefiles will have to exist. On
> the other hand, we can drop all the renaming and have the files named
> as they would be named on their destination after install.
> Opinions?
>
> [1]
> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:static-assets
>



-- 
*Yaniv Bronhaim.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160802/36d7a91c/attachment-0001.html>


More information about the Devel mailing list