[ovirt-devel] VARIANT_ID usage - with our without oVirt version?

[Fabian Deutsch]

On Thu, Jan 14, 2016 at 5:50 PM, Douglas Schilling Landgraf
<dougsland at redhat.com> wrote:
>
>
> On 01/14/2016 08:26 AM, Moti Asayag wrote:
>
>
> On Wed, Jan 13, 2016 at 5:17 PM, Fabian Deutsch <fdeutsch at redhat.com> wrote:
>>
>> Hey,
>>
>> we've now merged a patch [0] to use and populate the VARIANT and
>> VARIANT_ID fields on Node.
>>
>> Currently the value is something like "ovirt-node-$BRANCH", i.e.
>> "ovirt-node-master" or "ovirt-node-3.6".
>>
>> I'd like to question if we should include the oVirt version in the ID,
>> or if we should just use "ovirt-node" without the version.
>>
>> From my POV the variant is not depending on a specific version, that
>> is why I'd like to discuss it.
>
> My point of view is that variant_id doesn't depend of specific version, it
> only shows the
> 'flavor' of distro and may or may not include numbers as the link [1]
> showed.
>
> One benefit to have the branding/ovirt release in variant id is that in the
> new oVirt Node
> it uses Cockpit which reads /etc/os-release (ID + VARIANT_ID ) to show to
> the users in the login
> page such data, i.e:
>
> "CentOS oVirt Node 3.6"
>
> Username:
> Password:

I actually see that it's completely configurable, from branding.css:

"""
#brand {
    font-size: 18pt;
    text-transform: uppercase;
    content: "${NAME} <b>${VARIANT}</b>";
}
"""

We can easily update the file to take i.e. pretty name or something else.

> +1
> I agree the variant-id should not be a version specific. It should only
> describe the flavour of the host.
> I don't see why the engine should be aware of the specific version of it,
> especially since we'd like to have a unified process for all host types and
> furthermore for the same host type of different versions.
>
>
> I agree that Engine shouldn't care about a specific version at all but
> probably VDSM will be sending /etc/os-release to Engine for displaying data
> to the users.
>
>>
>>
>> The oVirt version can still be retieved like on any other host i.e.
>> using rpm or maybe some file(?).
>
>
>  Resolving the supported version of the hypervisor should be done the same
> way as for any host by monitoring the capabilities as reported by VDSM.

+1

- fabian