Bug 1260747 - Create the filesystem layout at install time in the places where needed
Create the filesystem layout at install time in the places where needed
Status: NEW
Product: vdsm
Classification: oVirt
Component: General (Show other bugs)
4.17.9
Unspecified Unspecified
medium Severity low (vote)
: ovirt-4.2.0
: ---
Assigned To: Yaniv Bronhaim
Gil Klein
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-07 11:22 EDT by Fabian Deutsch
Modified: 2016-11-28 09:14 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ybronhei: ovirt‑4.2?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2015-09-07 11:22:13 EDT
Description of problem:
While looking at vdsm/vdsmd_init_common.sh.in I notice that some
directories are created at runtime (when the service comes up in this
case).

Creating the dirs at installation time would be very beneficial for image based deliveries like Node or containers, because in those scenarios the filesystem tree is often read-only at runtime.

However, for some parts it still makes sense to check at runtime if the FS layout needs to be created, i.e. for /run.
Comment 1 Fabian Deutsch 2015-09-24 08:51:56 EDT
Some more details are given here: http://0pointer.net/blog/projects/stateless.html
Comment 2 Yaniv Bronhaim 2015-10-18 09:02:15 EDT
Dan, any historical reason why we create those folders on first run and not as part of the installation?


task_mkdirs(){                                                                  

    _mk_data_center - /rhev - ? any reason we don't create it in installation time?
    _mk_core_path   - /var/log/core ? we do ""install -dDm 1777 %{buildroot}%{_localstatedir}/log/core"" only in rhel. why not always?

    _mk_dom_backup  - /var/log/vdsm/backup - we create it in spec - this can be removed (line 1057) no?

    _mk_run_path    - we do create those subfolders /var/run/vdsm subfolders as part of installation - we can remove the mkdir, no?

    _mk_console_path - /var/run/ovirt-vmconsole-console - isn't ovirt-vmconsole should take care of creating this folder? how can it not be there? why do we have this condition there?

    "/usr/bin/chmod" 1777 /dev/shm                                              
}
Comment 3 Dan Kenigsberg 2015-10-19 03:25:36 EDT
(In reply to Yaniv Bronhaim from comment #2)
> Dan, any historical reason why we create those folders on first run and not
> as part of the installation?

There might have been special considerations on ovirt-node. Placing mkdir in startup gives a little bit more protection against someone deleting a required directory by mistake, or chaning its permission. It also provides a more precise error log in case the directory does not exist and cannot be created.

However, these are mostly excuses. We should conform to standards. At most, we can check (and fail startup) if these directories are missing.


> task_mkdirs(){                                                              
> 
> 
>     _mk_data_center - /rhev - ? any reason we don't create it in
> installation time?
>     _mk_core_path   - /var/log/core ? we do ""install -dDm 1777
> %{buildroot}%{_localstatedir}/log/core"" only in rhel. why not always?

commit 670503889: conform to Fedora standards. We need to remove this dropbox completely.

> 
>     _mk_dom_backup  - /var/log/vdsm/backup - we create it in spec - this can
> be removed (line 1057) no?
> 
>     _mk_run_path    - we do create those subfolders /var/run/vdsm subfolders
> as part of installation - we can remove the mkdir, no?

Just double check they exist on boot time (with /var/run being tmpfs) and on the node.

> 
>     _mk_console_path - /var/run/ovirt-vmconsole-console - isn't
> ovirt-vmconsole should take care of creating this folder? how can it not be
> there? why do we have this condition there?

I believe it was only Francesco trying to be nicer and not recreate an existing directory.

> 
>     "/usr/bin/chmod" 1777 /dev/shm                                          

Long long ago this was required by spice server. I think it can (and should!) be gone.
Comment 4 Yaniv Bronhaim 2016-04-25 06:52:32 EDT
it mostly about cleanup and arrangement of vdsm init script. moving that to 4.1

Note You need to log in before you can comment on or make changes to this bug.