On Tue, Aug 2, 2016 at 4:06 AM, Martin Polednik <mpoled...@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
>
> 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?
>

For my two cents, I prefer the second option. One to one name matching is
definitely preferable to renaming, in my opinion.

> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to