Adding /etc/ovirt-release
Hey, I'd like to make it easier to discover what oVirt release is installed, and what potential variant (i.e Node) is used. 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= 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. A CPE [1] is also included for convenience. Thoughts? - fabian -- [0] https://gerrit.ovirt.org/#/c/46067/ [1] http://cpe.mitre.org/
This is a multi-part message in MIME format. --------------030301090104000104000700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 On 11-09-2015 12:43, Fabian Deutsch wrote:
Hey,
I'd like to make it easier to discover what oVirt release is installed, and what potential variant (i.e Node) is used. 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=
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.
A CPE [1] is also included for convenience.
Thoughts?
- fabian
-- [0] https://gerrit.ovirt.org/#/c/46067/ [1] http://cpe.mitre.org/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--------------030301090104000104000700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> +1<br> <div class="moz-signature"> <style> .signature, .small-signature { font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New Roman"; color:#7F7F7F; } .signature { font-size:10pt; } .small-signature { font-size:8pt; }</style><br> </div> <div class="moz-cite-prefix">On 11-09-2015 12:43, Fabian Deutsch wrote:<br> </div> <blockquote cite="mid:CA+PVUaTRDtMr39-oCtk92mpHv87OT59T-sjttnegC2M+uzzSyQ@mail.gmail.com" type="cite"> <pre wrap="">Hey, I'd like to make it easier to discover what oVirt release is installed, and what potential variant (i.e Node) is used. 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= 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. A CPE [1] is also included for convenience. Thoughts? - fabian -- [0] <a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/46067/">https://gerrit.ovirt.org/#/c/46067/</a> [1] <a class="moz-txt-link-freetext" href="http://cpe.mitre.org/">http://cpe.mitre.org/</a> _______________________________________________ Devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/devel">http://lists.ovirt.org/mailman/listinfo/devel</a> </pre> </blockquote> <br> </body> </html> --------------030301090104000104000700--
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, and what potential variant (i.e Node) is used. 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=
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.
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
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, and what potential variant (i.e Node) is used. 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=
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? Could you point me to that logic? 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
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>
Hey,
I'd like to make it easier to discover what oVirt release is installed, and what potential variant (i.e Node) is used. 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=
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
wrote: the
upgrade requires to have ovirt-release35 and ovirt-release36 installed side by side.
Does the oVirt specific rpm based delivery allow rolling back?
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.
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
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
participants (4)
-
Christopher Pereira -
Fabian Deutsch -
Sandro Bonazzola -
Yedidyah Bar David