On Mon, Sep 14, 2015 at 9:17 AM, Sandro Bonazzola <[email protected]> wrote: > > > On Mon, Sep 14, 2015 at 8:08 AM, Fabian Deutsch <[email protected]> wrote: >> >> On Mon, Sep 14, 2015 at 7:45 AM, Sandro Bonazzola <[email protected]> >> wrote: >> > >> > >> > On Fri, Sep 11, 2015 at 5:43 PM, Fabian Deutsch <[email protected]> >> > 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 <[email protected]> >> RHEV Hypervisor >> Red Hat > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel Best, -- Didi _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
