8:52 a.m.
On Mon, Sep 14, 2015 at 9:17 AM, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
On Mon, Sep 14, 2015 at 8:08 AM, Fabian Deutsch <fdeutsch(a)redhat.com> wrote:
>
> On Mon, Sep 14, 2015 at 7:45 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
> wrote:
> >
> >
> > On Fri, Sep 11, 2015 at 5:43 PM, Fabian Deutsch <fdeutsch(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Best,
--
Didi