*** Bug 1510853 has been marked as a duplicate of this bug. ***

We have 3 issue here:
Scenario 1:
1. Try to edit existing OVN network and change its name value on CFME interface.

This is an engine problem.
Engine is only changing it's own network record, but does not make a request to the provider to change the OVN name. It must be changed on the engine.

Scenario 2:
1. Try to edit existing OVN subnet and change its name on the CFME interface.
This is a provider bug. Will fix in provider.

Scenario 3:
1. Try to edit existing OVN subnet, turn DHCP off, and try to update it on the CFME interface.
Do we want to support turning DHCP off?
In ovn we do not have a concept of 'subnet', but 'dhcp_option'. It's purpose is to automatically assign ip's, so disabling it does not make sense.

Maybe we could split this into 3 bugs for better tracking?

ElementNotFoundError: Network 2527f7fb-0a0f-4d2e-a052-c530358f8eeb.json does not exist

This is probably an issue in manageiq. The provider is receiving a malformed id of the network.

This bug tracks only Schenario 2 of comment 3 (edit existing OVN subnet)

The bug now concerns only this issue:

Scenario 2:
1. Try to edit existing OVN subnet and change its name on the CFME interface.



Subnet update logs (ovirt-provider-ovn.log):
-------------------------------------------
2017-11-08 12:06:55,378   Request: PUT : /v2.0/subnets/6eccac64-192f-4148-84c2-d07f2e5c934d
2017-11-08 12:06:55,379   Request body:
{"subnet":{"name":"test1234","enable_dhcp":true}}
2017-11-08 12:06:55,381   Starting new HTTPS connection (1): network-ge-2.scl.lab.tlv.redhat.com
2017-11-08 12:06:55,424   "POST /ovirt-engine/sso/oauth/token-info HTTP/1.1" 200 322
2017-11-08 12:06:55,508   Unable to move subnet to network None. The network does not exit.
Traceback (most recent call last):
  File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line 117, in _handle_request
    method, path_parts, content)
  File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", line 175, in handle_request
    return self.call_response_handler(handler, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron.py", line 36, in call_response_handler
    return response_handler(ovn_north, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron_responses.py", line 179, in put_subnets
    subnet = nb_db.update_subnet(received_subnet, parameters[SUBNET_ID])
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 58, in wrapper
    return (f(wrapped_self, rest_data, entity_id) if entity_id
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 42, in wrapper
    return cls.rest2row(wrapped_self, f, rest_data, entity_id)
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 290, in rest2row
    dns=dns,
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north.py", line 506, in update_subnet
    ' does not exit.'.format(network_id=network_id)
SubnetConfigError: Unable to move subnet to network None. The network does not exit.

CFME: 5.9.0.11.20171127204214_e316988
OVN provider: ovirt-provider-ovn-1.2.1-1.el7ev.noarch
 
I still don't find the suggested fix quite complete, and I'm not sure whether to verify this or assign it back.

In case I edit subnet and try to change the name, I have to explicitly set the DHCP to ON, otherwise it will fail. The default option fails:

2017-12-07 18:50:58,080   Setting enable_dhcp value to False is not supported
Traceback (most recent call last):
  File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line 126, in _handle_request
    method, path_parts, content)
  File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", line 176, in handle_request
    return self.call_response_handler(handler, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron.py", line 36, in call_response_handler
    return response_handler(ovn_north, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron_responses.py", line 179, in put_subnets
    subnet = nb_db.update_subnet(received_subnet, parameters[SUBNET_ID])
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 57, in wrapper
    validate_rest_input(rest_data)
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 408, in validate_update_rest_input
    SubnetMapper._validate_common(rest_data)
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 416, in _validate_common
    False
UnsupportedDataValueError

Mor, you are right - both https://developer.openstack.org/api-ref/network/v2/#update-subnet create-subnet state that

 enable_dhcp (Optional) 	body 	boolean 	Indicates whether dhcp is enabled or disabled for the subnet. Default is true.

Updating a subnet with a name only, works fine on setup.
I'm doing:
PUT: http://localhost:9696/v2.0/subnets/7e9cad6e-80ed-4682-a667-72c4dc715d85
{"subnet": {"name": "subnet3"}}
Is this how you are reproducing this?

The validation checks if enable_dhcp value is True only if it is present.

(In reply to Marcin Mirecki from comment #8)
> Updating a subnet with a name only, works fine on setup.
> I'm doing:
> PUT: http://localhost:9696/v2.0/subnets/7e9cad6e-80ed-4682-a667-72c4dc715d85
> {"subnet": {"name": "subnet3"}}
> Is this how you are reproducing this?
> 
> The validation checks if enable_dhcp value is True only if it is present.

No, I am not using REST to reproduce the issue. This bug is about setting it through the CFME UI. See the attached screenshot for the required change to make it work.

2017-12-10 09:43:13,090   Request body:
{"subnet":{"name":"test_subnet_2","enable_dhcp":false}}
2017-12-10 09:43:13,093   Starting new HTTPS connection (1): network-ge-2.scl.lab.tlv.redhat.com
2017-12-10 09:43:13,138   "POST /ovirt-engine/sso/oauth/token-info HTTP/1.1" 200 325
2017-12-10 09:43:13,225   Setting enable_dhcp value to False is not supported
Traceback (most recent call last):
  File "/usr/share/ovirt-provider-ovn/handlers/base_handler.py", line 126, in _handle_request
    method, path_parts, content)
  File "/usr/share/ovirt-provider-ovn/handlers/selecting_handler.py", line 176, in handle_request
    return self.call_response_handler(handler, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron.py", line 36, in call_response_handler
    return response_handler(ovn_north, content, parameters)
  File "/usr/share/ovirt-provider-ovn/handlers/neutron_responses.py", line 179, in put_subnets
    subnet = nb_db.update_subnet(received_subnet, parameters[SUBNET_ID])
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 57, in wrapper
    validate_rest_input(rest_data)
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 408, in validate_update_rest_input
    SubnetMapper._validate_common(rest_data)
  File "/usr/share/ovirt-provider-ovn/ovndb/ovn_north_mappers.py", line 416, in _validate_common
    False
UnsupportedDataValueError

CFME provider sends PUT request with DHCP off by default. Neutron API states that default should be True (as Dan mentioned in comment #7).

Created attachment 1365498 [details]
screenshot for default setting

Setting DHCP to FALSE is not supported by the provider at this moment.
If users don't want dhcp, they should not create a subnet.

It is a limitation of the ovn provider, not a bug.

If really needed, please request this as a feature.

Edit of existing subnet with the default 'Enable DHCP' option (screenshot will be attached) fails since CFME sends enable_dhcp->false, which is not supported by ovirt-provider-ovn.

Since this bug is on ovirt-provider-ovn, I will verify it but I think that we should send true since Neturon API documentation states that the default is true.

Verified on:
RHV Version 4.2.0.2-0.1.el7
CFME 5.9.0.12.20171205180333_3e32b3d 
ovirt-provider-ovn ovirt-provider-ovn-1.2.2-1.el7ev.noarch

Created attachment 1367832 [details]
Screenshot for CFME edit subnet

This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 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.