Open Stack

On 13/09/15 23:56, Sergey Kraynev wrote:
> Hi folks,
>
> Currently during implementation rich-network bp [1] (spec - [2]) we 
> met with issue on Tripleo
>  [3]. As temporary solution patch [4] was reverted.
>
> According traceback mentioned in bug description current issue related 
> with mac
>  addresses which should be used for specific hypervisor [5] [6].
> Previously in Tripleo, when we created vm without 'port-id' in 
> networks parameters, it was
>  handled by Nova [7], so new port got mac address from list of allowed 
> addresses.
>
> According rich-network BP, we want to use pre-created port (which we 
> create in Heat code
>  directly) during booting VM. Unfortunately in this case validation 
> mentioned above fails due
>  to different mac_addresses (for port and for hypervisor).
>
> We discussed it with Derek, and it looks like for Tripleo  it's 
> overhead work to get such mac
>  addresses and pass it in Heat template. Also I personally think, that 
> it's not user side issue,
> i.e. we should solve it inside Heat code ourselves. So we probably 
> need to ask Nova Ironic driver (because we can not ask ironic directly 
> from Heat) for this information - about list
> of allowed mac-addresses and then use it during creating port.
>
> I have investigated Novaclient code, but did not met any ability to do 
> it, except make to_dict() for Hypervisor object, but I am not sure, 
> that it will be presented in this output.
>
> So I'd ask Nova guys about some suggestions.
> Also any thoughts are welcome.
>
>
> [1] https://blueprints.launchpad.net/heat/+spec/rich-network-prop
> [2] https://review.openstack.org/#/c/130093
> [3] https://bugs.launchpad.net/tripleo/+bug/1494747
> [4] https://review.openstack.org/#/c/217753/
> [5] 
> https://github.com/openstack/nova/blob/309301381039b162588e5f2d348b5b666c96bd3a/nova/network/neutronv2/api.py#L477-L488
> [6] 
> https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L662-L678
> [7] 
> https://github.com/openstack/nova/blob/309301381039b162588e5f2d348b5b666c96bd3a/nova/network/neutronv2/api.py#L278
>
We may need to reconsider always pre-creating the port, given the above 
scenario plus comments like this[8].

One option would be to only pre-create if the template specifies 
explicit subnet or port_extra_properties, and otherwise let nova create 
the port on the specified network,

This would have implications for handling replace and rollback[9]. 
Either the server resource also needs to build resource data 
corresponding to the external_ports as well as the internal_ports, or 
the prepare_ports_for_replace needs to discover external ports too with 
a nova server get.

[8] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070648.html
[9] https://review.openstack.org/#/c/221032