[ovirt-devel] Adding /etc/ovirt-release

[Yedidyah Bar David]

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

Best,
-- 
Didi