Bug 805602
Summary: | validate numbers values, don't proceed if they are invalid | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | David Jaša <djasa> |
Component: | spice-xpi | Assignee: | Peter Hatina <phatina> |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.3 | CC: | acathrow, alevy, dblechte, ecohen, marcandre.lureau, mkrcmari, syeghiay, tsmetana, uril |
Target Milestone: | rc | ||
Target Release: | 6.4 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | spice-xpi-2.7-22.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-21 10:57:50 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Jaša
2012-03-21 16:38:23 UTC
It's not spice-xpi job to validate arguments, since the various programs spawned are the one consuming them, and spice-xpi is not responsible for coming up with those values. But it could help to identify more easily the guilty part if it would do some sanity check at spice-xpi level. Though, I would lower priority/severity of this bug. It seems to happen for vanilla ovirt installs. I'm not sure the priority/severity should be lowered. (In reply to comment #2) > It seems to happen for vanilla ovirt installs. I'm not sure the > priority/severity should be lowered. But spice-xpi is not responsible, it would be more appropriate in the html page or at the ovirt server level, or both. spice-xpi isn't going to tell us where the problem come from. (In reply to comment #3) > (In reply to comment #2) > > It seems to happen for vanilla ovirt installs. I'm not sure the > > priority/severity should be lowered. > > But spice-xpi is not responsible, it would be more appropriate in the html page > or at the ovirt server level, or both. spice-xpi isn't going to tell us where > the problem come from. As Marc-Andre said - spice-xpi is kind of proxy between the web page and the spicec/remote-viewer. On the other hand, it would make sense, if spice-xpi does not blindly execute a process with nonsense parameters. Einav, can you, please, clarify whether RHEV-M is able to send via spice-xpi one of 2 ports (secured or unsecured one)? If one of those ports is not used, what values are sent? Something specifc, eg. -1 or empty string? (In reply to comment #6) > Einav, can you, please, clarify whether RHEV-M is able to send via spice-xpi > one of 2 ports (secured or unsecured one)? If one of those ports is not used, > what values are sent? Something specifc, eg. -1 or empty string? RHEV-M sends to spice-xpi the "displaySecurePort" and "displayPort" values as reported by vdsm for the relevant VM via the 'getVmStats' vdsm verb. In case one of these values, for some reason, isn't reported from vdsm, RHEV-M will set "0" in the relevant spice-xpi property; i.e. if "displaySecurePort" isn't reported from vdsm, RHEV-M will set "0" in the spice-xpi "SecurePort" property; if "displayPort" isn't reported from vdsm, RHEV-M will set "0" in the spice-xpi "port" property. I am not sure if/when/how frequently "displaySecurePort" and/or "displayPort" aren't reported from vdsm. Please consult someone from the vdsm team if you need this information. Some clarification after discussions in rhev-devel: [http://post-office.corp.redhat.com/mailman/private/rhev-devel/2012-April/msg00281.html] - There are scenarios in which RHEV-M sends to spice-xpi SecurePort = "-1" (for spice with insecure communication). - There are scenarios in which RHEV-M sends to spice-xpi port = "-1" and SecurePort = "-1" (when VM is in "Powering Up" status / for the VM's initial boot period, until qemo starts listening to the spice ports). - There might be corner cases in which RHEV-M will send to spice-xpi port = "0" and SecurePort = "0" (highly improbable IMO). Einav, you said, that there is a scenario, when one of the ports can be "0". Does it make sense to start spicec/remote-viewer, with ports 0? Port 0 is the first valid and reserved transport layer port, but what does it indicate? The port is unused or can be used? What I am trying to figure out, when to start controller and when to log an error and do nothing. The value "-1" is clear, that port is unused, but can you explain, what does "0" indicate? Should I just run controller? agreed, moving to 6.4 (In reply to comment #9) > Einav, you said, that there is a scenario, when one of the ports can be "0". > Does it make sense to start spicec/remote-viewer, with ports 0? Port 0 is the > first valid and reserved transport layer port, but what does it indicate? The > port is unused or can be used? What I am trying to figure out, when to start > controller and when to log an error and do nothing. The value "-1" is clear, > that port is unused, but can you explain, what does "0" indicate? Should I > just > run controller? AFAIK, "0" and "-1" mean the same thing in our (rhevm GUI) point of view, i.e., port is unused. And again, sending "0" is highly improbable. Fixed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0459.html |