3. What is the nature and description of the request? The ovsdb-client implements a monitoring capability and vdsm should use this capability allow to notified of changes changes to OVS configuration and state. 4. Why does the customer need this? (List the business requirements here) This will eliminate the need to poll each hypervisor that has an open vswitch installed for state in information. 5. How would the customer like to achieve this? (List the functional requirements here) vdsm should interface with the openvswitch database to detect changes and report those changes to RHEV-M usage: ovsdb-client [OPTIONS] COMMAND [ARG...] Valid commands are: list-dbs [SERVER] list databases available on SERVER get-schema [SERVER] [DATABASE] retrieve schema for DATABASE from SERVER get-schema-version [SERVER] [DATABASE] retrieve schema for DATABASE from SERVER and report only its version number on stdout list-tables [SERVER] [DATABASE] list tables for DATABASE on SERVER list-columns [SERVER] [DATABASE] [TABLE] list columns in TABLE (or all tables) in DATABASE on SERVER transact [SERVER] TRANSACTION run TRANSACTION (a JSON array of operations) on SERVER and print the results as JSON on stdout monitor [SERVER] [DATABASE] TABLE [COLUMN,...]... monitor contents of COLUMNs in TABLE in DATABASE on SERVER. COLUMNs may include !initial, !insert, !delete, !modify to avoid seeing the specified kinds of changes. monitor [SERVER] [DATABASE] ALL monitor all changes to all columns in all tables in DATBASE on SERVER. dump [SERVER] [DATABASE] dump contents of DATABASE on SERVER to stdout The default SERVER is unix:/var/run/openvswitch/db.sock. The default DATABASE is Open_vSwitch. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. RHEV-M will receive a notification of an event or change in the ovs topology. Additionally, RHEV-M will need functionality to act upon these events. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? No. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? RHEV 4.0 9. Is the sales team involved in this request and do they have any additional input? Yes, the sales team is involved and may add additional comments later. 10. List any affected packages or components. vdsm 11. Would the customer be able to assist in testing this functionality if implemented? Yes.
Are they looking for being able to add themselves as a monitor or having their info collected by VDSM and sent to the management?
(In reply to Yaniv Dary from comment #2) > Are they looking for being able to add themselves as a monitor or having > their info collected by VDSM and sent to the management? Customer response: "We would want VDSM to collect the info and sent to RHEV-M. We would access via RHEV-M."