OpenNebula

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.

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...

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. ;)