Deploy VMs into existing OpenStack Neutron network

[MrBatschner]

What this PR does / why we need it:
Adds the ability to specify an already existing OpenStack Neutron network in the subnetID of an OpenStackMachineClass. MCM will deploy new machines into the given subnet by pre-allocating Neutron ports and pass them to the Nova server object. Pre-allocated ports will be specifically removed upon server termination. This is required to specify an existing subnet in a shoot manifest.
With this PR it is only possible to specify an already existing network, not a list of otherwise pre-allocated ports.

Which issue(s) this PR fixes:
Partly fixes #535

Special notes for your reviewer:
This change is a necessary precondition for PR 169 in gardener-extension-provider-openstack.

Release note:

Adds the ability to specify an already existing OpenStack Neutron network in the subnetID of an OpenStackMachineClass. MCM will deploy new machines into the given subnet by pre-allocating Neutron ports and pass them to the Nova server object. 

[MrBatschner]

/invite @dkistner
/invite @kon-angelo

[dkistner]

Had a brief look and seems to look good.
I need a little bit more time to play around with it.

[dkistner]

I guess we need to make sure that the port gets also deleted when the machine/server is already gone. Currently the port deletion logic is not executed when the machine is already deleted. We need to ensure that we check within each machine deletion flow for existing ports. See here:

machine-controller-manager/pkg/driver/driver_openstack.go

Lines 316 to 324 in ec67a43

	func (d *OpenStackDriver) Delete(machineID string) error {
	res, err := d.GetVMs(machineID)
	if err != nil {
	return err
	} else if len(res) == 0 {
	// No running instance exists with the given machine-ID
	klog.V(2).Infof("No VM matching the machine-ID found on the provider %q", machineID)
	return nil
	}

[MrBatschner]

I guess we need to make sure that the port gets also deleted when the machine/server is already gone. Currently the port deletion logic is not executed when the machine is already deleted. We need to ensure that we check within each machine deletion flow for existing ports.

True, we just pushed a commit that puts the port delete logic into a separate function which will always get called - even if the VM no longer exists.

On another note:
This whole PR means that MCM will (for new shoots created with our proposed changes to the openstack-provider-extension) always go through the create port->create VM with port and the delete VM -> delete its port logic. The old code-path create VM and let OpenStack do the port stuff itself is still in the MCM but once the openstack-provider-extension starts providing the subnetID in the OpenStackMachineClass, this code will no longer be triggered.

I do not see a problem with this behaviour but what do you think about it?

[dkistner]

looks good to me.

/invite @kon-angelo

@kon-angelo Could you please have a look as well?
@kayrus Could you also please have a brief look if you have time :)

[prashanth26]

/lgtm
/needs second-opinion

[kon-angelo]

/lgtm

[hardikdr]

cc @zuzzas

[hardikdr]

Hm, earlier the integration test of freeze failed.

Check for freezing and unfreezing of machine-set due to rapid scaleUp and scaleDown	Failed: Freezing of machineSet failed. Exiting Test to avoid further conflicts.

And now the unit test related to the freeze failed:

Summarizing 1 Failure:
13:04:16

13:04:16
[Fail] #machine_safety ##reconcileClusterMachineSafetyOvershooting [It] Freeze a machineSet and its machineDeployment 
13:04:16
/tmp/build/a94a8fe5/pull-request-gardener_machine-controller-manager-pr_master/pkg/controller/machine_safety_test.go:247

Tests are flaky somehow.

[hardikdr]

@MrBatschner Can you please squash the commits?

[MrBatschner]

@hardikdr Done, squashed all 11 commits into one.

[hardikdr]

/lgtm
Let's wait for a day, in case @kayrus is willing to take a look.