No docs about usage of format for switch_id for ports

Bug #1655381 reported by George Shuklin
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ironic
Invalid
Low
Unassigned

Bug Description

There is no information about how to use local_link_connection/switch_id for ports. Why it should be a MAC address, whose MAC address it is and where that MAC address should be written outside of switch_id field?

Here chat log from IRC:

(02:00:05 PM) amarao: I'm trying to make Ironic works with vendor driver for ML2 (neutron). And I stuck with 'switch_id' field for local_link_connection. It should be MAC address. But whose address it is? I can't understand what kind of MAC address I need put there. Can someone help me clarify this? Thanks.
(02:01:01 PM) sambetts: amarao: the Mac address of the switch you baremetal server is plugged into
(02:01:56 PM) amarao: But ports on switches do not have mac addresses by themselves. Only L3 interfaces do have them.
(02:02:27 PM) sambetts: amarao: the chassis_id of the switch, is traditionally the mac address of the mgntment port of the switch
(02:03:04 PM) amarao: Oh! Thank you!!!! I would never imagine this!

I believe it should be properly documented.

summary: - No information about usage of format for switch_id for ports
+ No docs about usage of format for switch_id for ports
description: updated
description: updated
description: updated
Revision history for this message
Jay Faulkner (jason-oldos) wrote :

I'm sorry, but even reading the chat log, I'm not sure exactly what's being referred to. Can you be more clear about what needs to be cleaned up?

I'm also adding Sam to this patch so maybe he can chime in and make it more clear.

Thanks for the report!

Changed in ironic:
status: New → Incomplete
Revision history for this message
Sam Betts (sambetts) wrote :

We provide documentation for this in step 4 here: http://docs.openstack.org/developer/ironic/deploy/multitenancy.html#configuring-nodes

Is it that you think that we need to be more specific about what the switch_id refers too, for example: a rewording to make it more obvious its the MAC address of the switch? or
Perhaps a link through to LLDP chassis_id documentation, which switch_id is based on.

Revision history for this message
George Shuklin (george-shuklin) wrote :

Yes, from that description there is absolutely no information whose MAC address it should be. Main unclear thing: where that MAC adddress should be except switch_id? In chassis description? In some obscure option for neutron?

I found zero information about that MAC address. Where it is used?

Revision history for this message
Sam Betts (sambetts) wrote :

That depends on two things the Ironic network driver implementation and the ML2 driver implementation, but in the default Ironic Neutron network driver, local_link_connection is passed to neutron ML2 drivers in the binding_profile to provide information on which switch the baremetal node is plugged into.

It is then down to the different ML2 drivers to define how they configure themselves and what information they need on top of the information provided by Ironic, to be able to bind the Neutron port successfully. We do not define in Ironic how it should be processed by the Neutron driver.

The basic structure of the local_link_connection is based on the LLDP packet you would receive from the switch (and we do have code to automatically populate that information if you support LLDP in your environment and your using inspection).

switch_id is an alias for the chassis_id TLV which is the MAC address the switch uses to identify itself, and port_id is the identifier of the port the baremetal is plugged into which might be different per vendor, e.g. Eth1/2 or something like that.
The switch_info is a freeform field which can be populated with any extra information required by your vendors ML2 driver to bind a baremetal node, for example the Cisco Nexus ML2 driver requires the mgnt IP address of the switch to be included in this field.

I think there are probably three deficits in documentation here, the first is Ironic developer documentation regarding what the local_link_connection field is and where it is used, the second is Neutron ML2 developer documentation around writing a driver for binding the baremetal VNIC type, and the third is deployer information explaining that you need to look at your switch's ML2 driver to find out what information you need to supply on the Ironic port and what the format of the information should be in, to guarantee a successful binding with that ML2 driver.

Revision history for this message
George Shuklin (george-shuklin) wrote :

Oh, I see the source of confusion. Some of vendor drivers for ML2 (e.g. Brocade at https://github.com/openstack/networking-brocade) have conception of 'chassis id' and do not use LLDP.

All it need (https://github.com/openstack/networking-brocade/blob/master/etc/neutron/plugins/ml2/ml2_conf_brocade_fi_ni.ini) is 'switch_name' and 'port'. So 'MAC address' for switch_id in Ironic's ports is very confusing.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Ironic because there has been no activity for 60 days.]

Changed in ironic:
status: Incomplete → Expired
Revision history for this message
George Shuklin (george-shuklin) wrote :

I don't think so.

Changed in ironic:
status: Expired → New
Michael Turek (mjturek)
tags: added: docs
tags: added: networking
Changed in ironic:
status: New → Confirmed
importance: Undecided → Low
Vladyslav Drok (vdrok)
Changed in ironic:
status: Confirmed → Triaged
Revision history for this message
Julia Kreger (juliaashleykreger) wrote :

Moving to invalid, the switch_id field is ml2 plugin dependent and ironic's payload must match what the ml2 plugin expects. This means it could be a mac address, hostname, or other value. Current documentation states this is a vendor-specific identifier as well. As such, moving to invalid.

Changed in ironic:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.