Multiple Build.sh issues about orchestrator

[shlomi-noach]

TOPDIR:

The build script sets this as /tmp/orchestrator-release, which clearly isn't and shouldn't be in your GOPATH. I'm not sure what happened that caused you thinking it should. If you paste output of build.sh execution on your system I can look into, but I have no input right now.

PREFIX:

Correct. Good catch. I didn't contribute the PREFIX change and have never used it myself, therefore never encountered this.

I'm not sure what the correct solution would be: just sed through the init script? That's possible. If you like to come up with a PR, I'm more than happy.

[samveen]

@shlomi-noach Once I started to change the init script, I find that it could use a complete overhaul. If it's OK, I'm gonna do a pretty drastic rewrite of the init script, to match LSB Base specs, as well as provide a systemd unit file for the service.

There is one concern that pops up, either way: The lack of an option for specifying the location of resources. This removes a hard requirement that orchestrator needs to run inside PREFIX.

[shlomi-noach]

I find that it could use a complete overhaul

If you think that's needed, please explain why so; what's not working well with the existing script.

There is one concern that pops up, either way: The lack of an option for specifying the location of resources. This removes a hard dependency that orchestrator needs to run inside PREFIX.

Please open a new Issue asking for resources path to be configurable.

[samveen]

If you think that's needed, please explain why so; what's not working well with the existing script.

The existing script is built around the requirements of init scripts from Centos/RHEL5 era(the origin is an old old script), and doesn't use any of the facilities provided by the initscripts package. Not only that, the script also deviates from LSB specs.

[shlomi-noach]

@samveen I'm not familiar wit the LSB specs. What would it take to make the script comply? I don't object to a complete rehaul if necessary.

[samveen]

@shlomi-noach As per LSB, there are some default capabilities to be provided by distributions for daemon init scripts as listed here.

Please note that these capabilities are independent of distribution, as long as the distribution supports LSB (and most do). However, this adds a dependency for the package lsb-core-noarch: this is a meta-package on both debian(and family) and RH (and family) that installs the requirements for LSB.

I have a WIP version at samveen/orchestrator@9c56824
Please review.

Note 1 It's trivial to add a non-root user option (again, an LSB provided facility using the --user option) which would take care of #117 (packages need a user addition pre-install script as appropriate).
Note 2: This init script will run without modification on any LSB compliant system, However, it can be made a little simpler if targeting just the Redhat family for installs.
Note 3: Probably move to systemd and create a service unit, instead of an init.d script?

[sturem]

Or even provide both, say, as orchestrator_init.bash and orchestrator_unit.bash; then install either, based on o/s version or systemd presence-or-absence?

[shlomi-noach]

Or even provide both, say, as orchestrator_init.bash and orchestrator_unit.bash

I like this suggestion!

[samveen]

That's needs to be a build time decision, IMHO.

[shlomi-noach]

@samveen so a command line flag to build.sh?

This will put some burden on distributing orchestrator as I'd need to multiply everything by 2. I'd rather not go down that way.

Or we can choose to distribute only one option, and leave it to the user to build option # 2.

[samveen]

@shlomi-noach I say a build time decision, as the packages should specify install time dependencies correctly, and then apply the appropriate post-install script to set up the service.

However, all that goes out of the window if we ignore the init system being used and package everything all together, and let the person doing the install set up the service as appropriate for him. However, in edge cases, that may be too much rope...