phillxnet
February 4, 2019, 8:54pm
8
(3.9.2-45 by GitHub release and Git tag)
Merged end November 2018
This was another large one which ended up being an umbrella issue for a number of things related to our openSUSE (non legacy) move. Including fixing Rock-ons functionality within Leap15.0 (at the time) and Tumbleweed.
Also note the additional distro indicator to the left of the Linux kernel Web-UI header element.
Issue:https://github.com/rockstor/rockstor-core/issues/1989
Code Changes:
rockstor:master ← phillxnet:1989_fix_non_legacy_build/docker_issues_plus_dev_to_rpm_install_mechanism
opened 09:32PM - 19 Nov 18 UTC
Fix a number of the remaining build and docker issues concerning the proposed mo… ve to openSUSE as an upstream linux ditro base. Includes a fix to facilitate moving from a developer (source) install to an rpm based one: currently this only supports our existing legacy CentOS base, pending the instantiation of an openSUSE rpm build backend along with related distro aware repository config code changes.
Docker specific notes:
Many more modern dockerd invocations require a number of command line arguments. Previously we passed, from the docker.service file, only one: our --data-root target. The included modifications allows for more custom or distro specific requirements to be met via accommodation of any number of arguments (unfiltered). All prior Rockstor specific dockerd arguments are preserved and applied as before.
Summary:
- Add dependency on python ‘distro’ library.
- Store build system distro info in django settings, the assumption here is we build on our target distro: normally the case.
- Add distro UI element, uses prior 2 items.
- Normalise prior UI subheader linux info formatting.
- Remove prior incorrect data_collector code comment.
- Selectively run postgresql-setup (legacy) or initdb (non legacy) in initrock.
- Update psycopg2 from 2.6 to 2.7.4.
- Normalise on direct paths for commands: avoids redundant fs redirection ie in CentOS root we have “/bin -> /usr/bin" and "/sbin - > /usr/sbin"; as these dir links are not found in our non legacy base move all hard wired command paths using them to their canonical reference.
- Use Django settings for a selection of variably located (distro specific) command paths: again with the assumption that we build on our target distro.
- Fix version indicator and software update page display for dev (source) installs.
- Fix dev (source install) to rpm install transition mechanism - necessarily considered as a re-install so db is wiped during the transition. Note that this, in part, involved the addition of an explicit 'yum install rockstor' command during update, along with ensuring that initrock is re-run on next rockstor.service start.
- Add distro aware docker.service template file selection based on distro.id(); moving fully to a live edit (during Rock-on service enable) rather than build time customization: ie to accommodate for our docker wrapper redirect and it’s consequent requirement for NofityAccess=all for Type=notify docker configs. Both included openSUSE templates are taken from their respective distro default installs of docker-ce.
- Establish docker-generic.service failover config for unknown distro ids taken from default upstream docker-ce 18.09 CentOS example.
- Enhance docker wrapper to pass additional arguments to dockerd.
- Minor additional rock-ons-root config exception logging.
- Catch and log harmless reboot/shutdown command exceptions with rc=-15. The exception log reports from these Web-UI initiated events are misleading as they suggest malfunction where there is none as both commands execute as expected with: out='', err='', and rc=-15.
Fixes #1989
See issue text for context and forum reference.
@suman Ready for review. Please note the additional ‘python-distro’ package dependency required of the rpm. My understanding is that the included entry in base-buildout.cfg [rpm-deps] section is sufficient, but I am not certain of this. N.B. my experience so far is that the build system will also require this package installed due to its use in settings.conf.in and it’s invocation from within initrock. Apologies for the inconvenience here. Also note the use of subprocess to run ‘which’ within settings.conf.in: this makes the assumption that the build system is as per the target system, ie CentOS (currently), with regard to binary locations of the commands in question (‘udevadm’, ‘shutdown’, and ‘chkconfig’ (see #1986 )). The package name of ‘python-distro’ works across all 3 current target distros, CentOS (currently only python2 variant) and both python2 and python3 variants in the openSUSE distros: both currently defaulting / resolving to their python2 versions.
Testing:
Source to rpm install transition (source install assumed not to be in /opt/rockstor).
Worked on CentOS distro base (only rpms currently available), with caveat that browser (Firefox) prompted for new cert exception upon transition as this is treated as a re-install / fresh install: db is wiped due to unknown state from development / source install. N.B. re-activation of the chosen update channel is also require, again due to this transition having a re-install status (prior db wiped). However the prior yum repo config is unaffected until a selection is made.
Distro adaptive docker config.
Tested on an original legacy CentOS (‘rockstor’ distro.id()) install as well as on current openSUSE Leap 15.0 (opensuse-leap distro.id()) and Tumbleweed (opensuse-tumbleweed distro.id()) installs. In all cases a successful Rock-ons-root config was achieved with the consequent test of installing a Plex Rock-on and ensuring that it auto started on reboot. The Rock-ons service was also successfully enabled and disabled on all systems via the Web-UI services page.
Images to follow in comments to illustrate the functioning Rock-on system and the added distro UI element.
The rpm release was short lived due to the following missing dependency issue:
@vesper1978 Thanks for the interest.
I’m not quite ready to make those changes in the repo just yet as I’m still ‘stepping up’ to take on / help out with some of these duties (and don’t want to step on toes) but I’m about to start a new forum thread such as we use to have that explains in less GitHub pull request techno speak how each release differs from the last. And as it goes 3.9.2-47 was used to merge more pending code improvements so I’ll detail in my proposed thread. We’ve had a little h…
