On Mon, Sep 14, 2015 at 9:17 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Mon, Sep 14, 2015 at 8:08 AM, Fabian Deutsch <fdeutsch@redhat.com> wrote:
On Mon, Sep 14, 2015 at 7:45 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Fri, Sep 11, 2015 at 5:43 PM, Fabian Deutsch <fdeutsch@redhat.com> wrote:
Hey,
I'd like to make it easier to discover what oVirt release is installed,
Just installed? You can find this in engine-prolog.sh, no? # . /usr/share/ovirt-engine/bin/engine-prolog.sh # echo $PACKAGE_VERSION # echo $DISPLAY_VERSION
and what potential variant (i.e Node) is used.
engine-prolog.sh sources all of /etc/ovirt-engine/engine.conf.d/*.conf , so you can add there your own file(s) if needed. Note that some of these files are packaged in various RPMS, and some are generated by engine-setup (usually starting with 10-setup, but that's just a convention).
Currently we are using some Node specific files to identify this "variant".
With this patch [0] I'm suggesting to add the /etc/ovirt-release file, with the following contents:
NAME=oVirt ID=ovirt VERSION="4.0 (master)" VERSION_ID=4.0 PRETTY_NAME="oVirt 4.0" CPE_NAME="cpe:/a:ovirtproject:ovirt:4.0:dev" VARIANT="" VARIANT_ID=
I think all of these already exist or are easy to add.
The variables are close to what is used by Fedora and CentOS. The variant field is left empty by default, but can be populated with defined values for variants like Node or i.e. a container variant.
what if multiple ovirt-releaseX are installed? for example, upgrading from 3.5 to 3.6 keeping rollback support during the upgrade requires to have ovirt-release35 and ovirt-release36 installed side by side.
Does the oVirt specific rpm based delivery allow rolling back?
I think Sandro referred to your implementation, patching the package ovirt-release. Perhaps better do that by patching ovirt-engine - some static files and/or engine-setup - if what I wrote above is not enough.
well yes, if for some reason the upgrade from 3.5 to 3.6 fails, transaction rollback should work, restoring 3.5 to previous state.
Could you point me to that logic?
it's within engine-setup, provided by otopi framework.
Specifically, grep for TransactionElement - instances of the classes that inherit from it are created, and their 'abort' method is called when we need to rollback. As Sandro said, some of them are in engine-setup and some in otopi.
A general approach could be to make /etc/ovirt-release a symlink.
Right now I'd even consider to move this file to /usr/lib/ovirt-release, this will be much better suioted for image based deliveries …
- fabian
A CPE [1] is also included for convenience.
Thoughts?
- fabian
-- [0] https://gerrit.ovirt.org/#/c/46067/ [1] http://cpe.mitre.org/
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
-- Fabian Deutsch <fdeutsch@redhat.com> RHEV Hypervisor Red Hat
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Best, -- Didi