Backlog #3897

FHS: remotes in "/var/lib/one" instead of "/usr/lib/one"?

Added by Dmitry Smirnov almost 6 years ago. Updated over 5 years ago.

Status:PendingStart date:07/28/2015
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I've noticed that Opennebula 4.12 installs "remotes" scripts to "/var/lib/one/remotes" which appears to be a violation of FHS.
Probably they should go to "/usr/lib/one/remotes" (or to "/usr/share/one/remotes" if they are all arch-independent).

Unless there is some divine reason for current location please consider moving scripts from "/var/lib/one/remotes" to "/usr/lib/one/remotes".

Thanks.

History

#1 Updated by Dmitry Smirnov almost 6 years ago

On second thought it is a very serious bug -- suppose one follows Quick Start Instructions ยง2.4 [1] and mount shared `/var/lib/one` --
now installing "opennebula" package overwrites scripts in "/var/lib/one/remotes" that was installed on another machine(s) or fails to install due to permissions problem. Such collision is a very bad problem indeed.

If every node needs those scripts then they should be installed to non-shared location (e.g. "/usr/lib/one/remotes") by "opennebula-node" package.

[1]: http://docs.opennebula.org/4.12/design_and_installation/quick_starts/qs_ubuntu_kvm.html

P.S. please upgrade my access so I could manipulate bug severity.

#2 Updated by Ruben S. Montero almost 6 years ago

Scripts are in /var/lib/one because their are supposed to be modified with custom probes or scripts by sys admins. These scripts are copied to each host with onehost sync and are (potentially) specific to each host as the state may or may not be in sync. This is the reason we consider this monitor scripts as data rather than programs.

Also, as you probably know changing a path like this in a project of the size of OpenNebula is far from trivial, and probably with a limited benefit for the users. Just think of the nightmare of an upgrade. So if there any other stronger reason we'll keep our view that remotes is oned data rather than lib or bins.

THANK YOU VERY MUCH FOR YOUR TIME, EFFORT & FEEDBACK!!!!!

P.S. We use priority to queue the issues in the implementation line (i.e. their "urgency"), not to label whether they are important or not. Probably we could add another field to add information or just as stated in the description in this issue. So the priority is a result of the number of people interested in the issue, its alignment with the strategic roadmap of the Project, effort needed to implemented, current release plans, etc...

#3 Updated by Dmitry Smirnov almost 6 years ago

Ruben S. Montero wrote:

Scripts are in /var/lib/one because their are supposed to be modified with custom probes or scripts by sys admins.

Typically locally modified scripts are installed to `/usr/local`.

These scripts are copied to each host with onehost sync and are (potentially) specific to each host as the state may or may not be in sync.

Perhaps it is my lack of experience but I'm not sure how and when "onehost sync" is expected to be used...
Apparently instructions regarding shared "/var/lib/one" are in conflict with use of "onehost sync"...

This is the reason we consider this monitor scripts as data rather than programs.

Unfortunately that's not how Debian packaging is implemented...

Also, as you probably know changing a path like this in a project of the size of OpenNebula is far from trivial, and probably with a limited benefit for the users. Just think of the nightmare of an upgrade. So if there any other stronger reason we'll keep our view that remotes is oned data rather than lib or bins.

I respectfully disagree here. :) Imagine a hypothetical situation when an upgrade introduce a new dependency or incompatibility to script(s) in "remotes". When "/var/lib/one" is shared, upgrade of OpenNebula on one machine will break remotes cluster-wide until all other nodes are upgraded too. Risk of such scenario is not negligible.

I'm not sure when/why remotes-scripts are expected to be customised but if they are specific to host then they should be installed by the packages to permanent location (e.g. "/usr/lib/one") with local customisation under "/usr/local/lib/one" or somewhere similar.

If remotes-scripts are really data that is safe to share among all nodes (which does not seem to be the case), then it should be copied from permanent location to "/var/lib/one/remotes" manually by "onehost sync". In this case documentation should be updated accordingly to describe the procedure.

THANK YOU VERY MUCH FOR YOUR TIME, EFFORT & FEEDBACK!!!!!

No worries. Thank you. ;)

P.S. We use priority to queue the issues in the implementation line (i.e. their "urgency"), not to label whether they are important or not. Probably we could add another field to add information or just as stated in the description in this issue. So the priority is a result of the number of people interested in the issue, its alignment with the strategic roadmap of the Project, effort needed to implemented, current release plans, etc...

Thanks for explaining. Typically serious bugs are to be fixed first hence priority/severity is an advisory field to help developers to choose next problem to address. It is nice to be able to classify severity of problems -- for example it could be useful to distinguish bug that can lead to loss of data from minor documentation update that can wait until more serious issues are fixed.

In Redmine, scheduling is usually handled by "Due Date" so it seems that you are (mis)using "Priority" for scheduling instead of using it as "Severity" of the issue although it could be a work flow that I am not familiar with. ;)

#4 Updated by Ruben S. Montero almost 6 years ago

  • Tracker changed from Bug to Backlog
  • Target version set to Release 5.0

I'm moving this to backlog and consider for 5.0 release where this type of changes can be included; 5.0 is hopefully the next one.... We want also to change the hiearchy of etc files, so it'll be the right place to further discuss this.

Cheers

#5 Updated by Ruben S. Montero over 5 years ago

  • Target version deleted (Release 5.0)

Also available in: Atom PDF