<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 8:08 AM, Fabian Deutsch <span dir="ltr"><<a href="mailto:fdeutsch@redhat.com" target="_blank">fdeutsch@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Sep 14, 2015 at 7:45 AM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>> wrote:<br>
><br>
><br>
> On Fri, Sep 11, 2015 at 5:43 PM, Fabian Deutsch <<a href="mailto:fdeutsch@redhat.com">fdeutsch@redhat.com</a>> wrote:<br>
>><br>
>> Hey,<br>
>><br>
>> I'd like to make it easier to discover what oVirt release is<br>
>> installed, and what potential variant (i.e Node) is used.<br>
>> Currently we are using some Node specific files to identify this<br>
>> "variant".<br>
>><br>
>> With this patch [0] I'm suggesting to add the /etc/ovirt-release file,<br>
>> with the following contents:<br>
>><br>
>> NAME=oVirt<br>
>> ID=ovirt<br>
>> VERSION="4.0 (master)"<br>
>> VERSION_ID=4.0<br>
>> PRETTY_NAME="oVirt 4.0"<br>
>> CPE_NAME="cpe:/a:ovirtproject:ovirt:4.0:dev"<br>
>> VARIANT=""<br>
>> VARIANT_ID=<br>
>><br>
>> The variables are close to what is used by Fedora and CentOS.<br>
>> The variant field is left empty by default, but can be populated with<br>
>> defined values for variants like Node or i.e. a container variant.<br>
><br>
> what if multiple ovirt-releaseX are installed?<br>
> for example, upgrading from 3.5 to 3.6 keeping rollback support during the<br>
> upgrade requires to have ovirt-release35 and ovirt-release36 installed side<br>
> by side.<br>
<br>
</span>Does the oVirt specific rpm based delivery allow rolling back?<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you point me to that logic?<br>
<br></blockquote><div><br></div><div><br></div><div>it's within engine-setup, provided by otopi framework. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A general approach could be to make /etc/ovirt-release a symlink.<br>
<br>
Right now I'd even consider to move this file to<br>
/usr/lib/ovirt-release, this will be much better suioted for image<br>
based deliveries …<br>
<br>
- fabian<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><br>
>> A CPE [1] is also included for convenience.<br>
>><br>
>> Thoughts?<br>
>><br>
>> - fabian<br>
>><br>
>> --<br>
>> [0] <a href="https://gerrit.ovirt.org/#/c/46067/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/46067/</a><br>
>> [1] <a href="http://cpe.mitre.org/" rel="noreferrer" target="_blank">http://cpe.mitre.org/</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Sandro Bonazzola<br>
> Better technology. Faster innovation. Powered by community collaboration.<br>
> See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Fabian Deutsch <<a href="mailto:fdeutsch@redhat.com">fdeutsch@redhat.com</a>><br>
RHEV Hypervisor<br>
Red Hat<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Sandro Bonazzola<br>Better technology. Faster innovation. Powered by community collaboration.<br>See how it works at <a href="http://redhat.com" target="_blank">redhat.com</a><br></div></div></div></div>
</div></div>