Re: [Engine-devel] network features review

Please forgive the late response and the lengthy remarks, some you may not like :) ----- Original Message ----- Bootstarp does not support most of the possible network configuration. It will fail if there is already a non bridged bond/Vlan etc. I think that what should be done here is nothing, the bootstrap need not touch the network configuration at all. All the admin has to do is verify that the host has connectivity to the engine Then 1. On initial setup on the engine side, before adding any host allow to edit the management network properties. (Vlan/VM network/MTU etc) 2. Allow to add the host 3. Use setup-networks to assign the management network according to the topology selected by the admin. It can be done easily by allowing the user to detach it and then attach. As long as it is within the context of the edit menu before he hits OK this is allowed. The above should allow for any supported network configuration to be applied without all the issues and limitations around that ATM. It also simplifies the bootstrap - it does not care about network. See the suggestion above it also solves this scenario. Agree, and this is should be always the default. Again the solution suggested above solves this too. If the IP is on the same network - you should be able to do so. But this is not the problem, usually the need to change an IP is not during host/node installation, so there is no problem here, if the user wants a different IP at installation phase he need to set it before he adds the host/node, thus you only need to worry about IP changes for already added host (see comment below) As I recall this is true if the cert is created based on IP and not FQDN. The re-install is required to replace the certs. What should be done is to use FQDN to create the certs and not the IP. This should allow for change of the rhevm network IP as long as it resolves to the same FQDN. I think this was fixed when installing using boot strap or add a node from the New host button (But can't be sure). When doing from the node, then last time I checked it still uses the IP of the host. Also missing indication that a network topology change has been applied but not saved. This lead into situations where after setting a configuration and it works the user forgets to save. Everything works well until the first reboot of the node/host. This may happen days/weeks/months after the actual configuration has been changed so the user may not understand what has happened (/me old geezer with bad memory has done it more then once :)) +1 I like the first option better. I understand the complexity of having mixed mode so I won't dare suggesting doing the propagation on live hosts (Though on some properties this should be possible) however you can relax the above a bit and just request maintenance. Then upon activation, if networks properties are different then the current definition update the host (actually you don't have to check, just send new topo) There is a difference between placing 100 hosts into maintenance and between placing into maintenance, removing them, change definition and then re-adding. I just changed 3 host and it was irritating. I had to: 1. Place them all into maintenance 2. Move them into temp cluster with no network requirements 3. Change the network 4. Move the hosts back 5. Activate. With the suggest above only steps 1 and 5 are required. Not that much considering what the user will have to do (look at the suggested solution) - it will pay back after the first user that forgot to set a network as vm-network after adding few hosts and calls support. getVdsCaps is nothing compared to getAllVmsStats and you do the later every 10 seconds right? so why bother with on demand, why not just read it once a minute? When the update logic was created hot plug HW, virtual devices (NICs), etc was only a musing new comer, now with UCS and it's like it is a reality. There is no reason not to just update periodically.