We do not have recent Ubuntu versions defined. It would require to add it first. We can probably add 20.04 as an exception....we stopped adding OSes until refactoring which never happened

Anyway, no functional impact. We don’t require OGA anywhere, it’s just an extra unused channel definition

Michal, can you elaborate on the refactoring mentioned in comment 1?
adding the new Ubuntu versions and disable guest agent channel seems trivial.

disabling GA is trivial and can be done easily
See bug 1341161 for past discussions about additional OSes

I would prefer to have a generic "Ubuntu x.y+" or even better a Debian x+ based OS or something like that, than making the list even longer...

(In reply to Michal Skrivanek from comment #3)
> disabling GA is trivial and can be done easily
> See bug 1341161 for past discussions about additional OSes
> 
> I would prefer to have a generic "Ubuntu x.y+" or even better a Debian x+
> based OS or something like that, than making the list even longer...

I see, but the current pattern is to grow the list. We currently have [1]. Because we need to turn off the ovirtGuestAgentChannel only for versions 18 and 20, it may become quite confusing and due to the fact that the change affects the WebAdmin display, one should be a little cautious when changing the look and feel. 

For clarification is the suggestion to remove those already implemented [1] to replace them with a Debian x+ including version 16 and then a second one for 18 and 20 while turning off the OGA for the later two?

[1]
ubuntu_12_04
ubuntu_12_10
ubuntu_13_04
ubuntu_13_10
ubuntu_14_04

(In reply to Steven Rosenberg from comment #4)
> (In reply to Michal Skrivanek from comment #3)

> I see, but the current pattern is to grow the list. We currently have [1].

no, so that's the thing - we stopped doing that years ago, and we try to add only when there is a real functional difference (e.g. that Other (kernel 4.x)). It wasn't such a big deal with Windows but with Ubuntu with 2 releases a year that's a long list of OSes where nothing changes...

(In reply to Michal Skrivanek from comment #5)
> (In reply to Steven Rosenberg from comment #4)
> > (In reply to Michal Skrivanek from comment #3)
> 
> > I see, but the current pattern is to grow the list. We currently have [1].
> 
> no, so that's the thing - we stopped doing that years ago, and we try to add
> only when there is a real functional difference (e.g. that Other (kernel
> 4.x)). It wasn't such a big deal with Windows but with Ubuntu with 2
> releases a year that's a long list of OSes where nothing changes...

I would consider tracking only LTS supported version (supported by Ubuntu I mean): https://ubuntu.com/about/release-cycle

Ubuntu 20.04 LTS
Ubuntu 18.04 LTS
Ubuntu 16.04 LTS
Ubuntu 14.04 LTS

Any other older version is not supported anymore by Ubuntu itself, I don't see value in trying to support them within oVirt.
Also I wouldn't trak interim releases, not suited for an enterprise grade deployment where oVirt is meant to run.

Dropping the existing values doesn't seem to worth its cost - we can leave them as-is.
I'd say we can just go with 'groups' to make things simpler.
"Ubuntu Trusty Tahr LTS" would become "Ubuntu Trusty Tahr LTS+" so it would also cover 16.04
and add a new one "Ubuntu Trusty Tahr LTS+/Debian 10+" (or "Ubuntu 18.04+/Debian 10+") to cover 18.04 and 20.04 (and probably later ones) that don't require ovirt-guest-agent channel

(In reply to Arik from comment #7)
> Dropping the existing values doesn't seem to worth its cost - we can leave
> them as-is.
> I'd say we can just go with 'groups' to make things simpler.
> "Ubuntu Trusty Tahr LTS" would become "Ubuntu Trusty Tahr LTS+" so it would
> also cover 16.04
> and add a new one "Ubuntu Trusty Tahr LTS+/Debian 10+" (or "Ubuntu
> 18.04+/Debian 10+") to cover 18.04 and 20.04 (and probably later ones) that
> don't require ovirt-guest-agent channel

I think Sandro's Comment 6 has a very good point. If Ubuntu is not supporting the older versions, it does make sense to deprecate them and then to only support the newer versions. This does reduce the list size as per Michal's request and will be less confusing for the user who may not understand what '+' is. We may have an issue with upgrading, but we can downgrade the missing OS choices to Other Linux which is what the older Ubuntu versions are derived from anyway. We also have Debian 7 (not 10) which derives from Ubuntu 12.04 [1] and can also be deprecated. The equivalent Ubuntu to Debian for Sandro's suggestion seem to be from Debian 8-11 [1] [2] (Ubuntu 18.04 correlating with Debian 9). But maybe we can keep it simple and just add the equivalent Debian version in the description, but keep the labels as Ubuntu, for example: ubuntu_14_04 as that part of your suggestion.


[1] 

Ubuntu            Debian  
20.04  focal      bullseye/ sid   - 11
19.10  eoan       buster  / sid   - 10
19.04  disco      buster  / sid
18.10  cosmic     buster  / sid
18.04  bionic     buster  / sid
17.10  artful     stretch / sid   - 9
17.04  zesty      stretch / sid
16.10  yakkety    stretch / sid
16.04  xenial     stretch / sid
15.10  wily       jessie  / sid   - 8
15.04  vivid      jessie  / sid
14.10  utopic     jessie  / sid
14.04  trusty     jessie  / sid
13.10  saucy      wheezy  / sid   - 7
13.04  raring     wheezy  / sid
12.10  quantal    wheezy  / sid
12.04  precise    wheezy  / sid
11.10  oneiric    wheezy  / sid
11.04  natty      squeeze / sid   - 6
10.10  maverick   squeeze / sid
10.04  lucid      squeeze / sid

[2] https://itectec.com/ubuntu/ubuntu-what-debian-version-are-the-different-ubuntu-versions-based-on/

(In reply to Steven Rosenberg from comment #8)
> I think Sandro's Comment 6 has a very good point. If Ubuntu is not
> supporting the older versions, it does make sense to deprecate them and then
> to only support the newer versions. This does reduce the list size as per
> Michal's request and will be less confusing for the user who may not
> understand what '+' is.

Feel free to suggest other notation instead of '+'

> We may have an issue with upgrading, but we can
> downgrade the missing OS choices to Other Linux which is what the older
> Ubuntu versions are derived from anyway. We also have Debian 7 (not 10)
> which derives from Ubuntu 12.04 [1] and can also be deprecated. The
> equivalent Ubuntu to Debian for Sandro's suggestion seem to be from Debian
> 8-11 [1] [2] (Ubuntu 18.04 correlating with Debian 9). But maybe we can keep
> it simple and just add the equivalent Debian version in the description, but
> keep the labels as Ubuntu, for example: ubuntu_14_04 as that part of your
> suggestion.

So as I wrote in comment 7, I don't think that this cleanup would worth its cost (I believe you'll find it harder than it sounds)
If you're really passionate about it, you can give it a shot
But that's less of a priority and is not part of the scope of this bz

(In reply to Arik from comment #9)
> (In reply to Steven Rosenberg from comment #8)
> > I think Sandro's Comment 6 has a very good point. If Ubuntu is not
> > supporting the older versions, it does make sense to deprecate them and then
> > to only support the newer versions. This does reduce the list size as per
> > Michal's request and will be less confusing for the user who may not
> > understand what '+' is.
> 
> Feel free to suggest other notation instead of '+'
> 
> > We may have an issue with upgrading, but we can
> > downgrade the missing OS choices to Other Linux which is what the older
> > Ubuntu versions are derived from anyway. We also have Debian 7 (not 10)
> > which derives from Ubuntu 12.04 [1] and can also be deprecated. The
> > equivalent Ubuntu to Debian for Sandro's suggestion seem to be from Debian
> > 8-11 [1] [2] (Ubuntu 18.04 correlating with Debian 9). But maybe we can keep
> > it simple and just add the equivalent Debian version in the description, but
> > keep the labels as Ubuntu, for example: ubuntu_14_04 as that part of your
> > suggestion.
> 
> So as I wrote in comment 7, I don't think that this cleanup would worth its
> cost (I believe you'll find it harder than it sounds)
> If you're really passionate about it, you can give it a shot
> But that's less of a priority and is not part of the scope of this bz

The suggestion in Comment 7 also seems costly for support due to changing the patterns for the user, due to inconsistencies.

Though we could change the description to Ubuntu Trusty Tahr LTS and later", and it seems we may have enough real state for that on the WebAdmin, it may be a source of confusion not only with the Webadmin, but even more so with the restapi. Trying to align the proper Debian version with the proper Ubuntu versions will also be problematic as per Comment 8.

It may be better to deliver a consistent version first and then to deprecate older Ubuntu x86 Operating System versions as a separate issue instead of an inconsistent solution, partially solution that will require further maintenance.

Verified with:
- ovirt-engine-4.4.4.5-0.10.el8ev.noarch
- vdsm-4.40.40-1.el8ev.x86_64
- libvirt-6.6.0-7.module+el8.3.0+8424+5ea525c5.x86_64
- Ubuntu 18.04.5 (Bionic Beaver)


Verification steps:
1. Make sure the following OS appears on the `Operating System` list (add/edit a VM): Debian 7+, Debian 9+, Ubuntu Bionic Beaver LTS+
2. Create a 'Ubuntu 18.04.5 (Bionic Beaver)' VM with OS == Ubuntu Bionic Beaver LTS+.
3. Create a 'Ubuntu 18.04.5 (Bionic Beaver)' VM with OS == Other OS.


Result:
- The ovirt-guest-agent service in the VM created in section 2 is off (see logs below).
- The ovirt-guest-agent service in the VM created in section 3 is runs and works as expected.


/var/log/ovirt-guest-agent/ovirt-guest-agent.log (on the VM from section 2):

  MainThread::INFO::2020-12-20 11:10:12,011::ovirt-guest-agent::59::root::Starting oVirt guest agent
  MainThread::ERROR::2020-12-20 11:10:12,106::ovirt-guest-agent::141::root::Unhandled exception in oVirt guest agent!
  Traceback (most recent call last):
    File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 135, in <module>
      agent.run(daemon, pidfile)
    File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run
      self.agent = LinuxVdsAgent(config)
    File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 472, in __init__
      AgentLogicBase.__init__(self, config)
    File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in __init__
      self.vio = VirtIoChannel(config.get("virtio", "device_prefix"))
    File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 162, in __init__
      self._stream = VirtIoStream(vport_name)
    File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 143, in __init__
      self._vport = os.open(vport_name, os.O_RDWR)
  OSError: [Errno 2] No such file or directory: '/dev/virtio-ports/ovirt-guest-agent.0'

Just to clarify, the result for section 2 (stopped OGA) is as expected,
- the service is stopped because the VM configured with OS == `Ubuntu Bionic Beaver LTS+`.

This bugzilla is included in oVirt 4.4.4 release, published on December 21st 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.