|
|
Post by jiaqingzintel on Feb 19, 2022 8:46:39 GMT
In old VLanNetworkInterface schema, a VLAN can be createing by POSTing /redfish/v1/Managers/{ManagerId}/EthernetInterfaces/{EthernetInterfaceId}/VLANs with request body below
{
"VLANEnable": true,
"VLANId": 2
}
Since redfish schema release 2021.2, VLanNetworkInterface is deprecated and it is suggested to use EthernetInterface for showing VLANs. But I cannot figure out what is the proper way to create a VLAN interface.
The schema only says the VLAN.VLANEnable and VLAN.VLANId properties of EthernetInterface are required on create, but it cannot represent which physical interface the VLAN belongs to if the request is POST /redfish/v1/Managers/{ManagerId}/EthernetInterfaces. While POST /redfish/v1/Managers/{ManagerId}/EthernetInterfaces/{EthernetInterfaceId} can tell the physical interface, it seems to be not following the RESTful API design.
From my personal view, maybe we can add a CreateVLAN Action to each physical interface for creating the VLAN interface? The request body can be the same as what it is in old VLanNetworkInterface schema.
|
|
|
|
Post by mraineri on Feb 24, 2022 18:00:18 GMT
This is an area we're still discussing internally and don't have a complete answer for at the moment. We're working on other related EthernetInterface complexities as part of a WIP bundle we've published (https://www.dmtf.org/sites/default/files/standards/documents/DSP-IS0022_.0.5WIP.zip).
In the meantime, you can continue to use VLanNetworkInterface if it suites your needs; just because something is deprecated doesn't mean it cannot be used. However, one of the main issues we noticed with VLanNetworkInterface is that it simply contained the VLAN Id and nothing else; our understanding is when you make a VLAN, you also have IP address assignments with it, which won't be the same as the IP address assigned to the interface hosting the VLAN.
|
|
|
|
Post by jiaqingzintel on Feb 28, 2022 16:30:06 GMT
This is an area we're still discussing internally and don't have a complete answer for at the moment. We're working on other related EthernetInterface complexities as part of a WIP bundle we've published (https://www.dmtf.org/sites/default/files/standards/documents/DSP-IS0022_.0.5WIP.zip). In the meantime, you can continue to use VLanNetworkInterface if it suites your needs; just because something is deprecated doesn't mean it cannot be used. However, one of the main issues we noticed with VLanNetworkInterface is that it simply contained the VLAN Id and nothing else; our understanding is when you make a VLAN, you also have IP address assignments with it, which won't be the same as the IP address assigned to the interface hosting the VLAN. Right, a limitation I encountered is that using VLanNetworkInterface only cannot assign IP address for the VLAN interface. Is it okay to use both schema for VLAN interfaces? That is using VLanNetworkInterface to create/delete VLANs and expose the VLAN interfaces as EthernetInterface for managing the IP and other options. |
|
|
|
Post by mraineri on Feb 28, 2022 19:08:34 GMT
If you mean essentially replacing the new "VLanNetworkInterface" in the collection as an "EthernetInterface", then no, that's not allowed.
|
|
|
|
Post by jiaqingzintel on Mar 8, 2022 3:18:46 GMT
If you mean essentially replacing the new "VLanNetworkInterface" in the collection as an "EthernetInterface", then no, that's not allowed. I mean, for example, if there is a /redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1, then create a new VLAN by posting /redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1/VLANs with { "VLANEnable": true, "VLANId": 2 } There should be a /redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1/VLANs/2 in VLanNetworkInterface schema, right? I'd like to ask if also showing this VLAN with extra information like IP address at /redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1_VLAN2 in EthernetInterface schema is acceptable? |
|
|
|
Post by mraineri on Mar 8, 2022 13:51:35 GMT
Yes, when you post that VLAN object to "/redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1/VLANs", it will create a new resource in that collection that follows the VLanNetworkInterface schema.
You could technically have an EthernetInterface resource at "/redfish/v1/Managers/Manager0/EthernetInterfaces/Interface1_VLAN2" to track the IP address and other interface information for that VLAN. I assume this would be a new resource created at the same time as the new VLAN resource? One thing I'd be cautious about with this approach is it doesn't follow normal resource behavior in Redfish, so it can be confusing for clients.
|
|
|
|
Post by jiaqingzintel on May 25, 2022 18:52:39 GMT
One more question, is there any way to represent the assiciation between VLAN and Physcial interfaces like the deprecated VLANs preoperty? I saw there is a "NetworkDeviceFunctions" property for this purpose, but it cannot be used for the Manager's network.
|
|
|
|
Post by mraineri on May 25, 2022 19:03:25 GMT
Not at this time, but I certainly see the need to represent that sort of information. We'll definitely need to cover that when we address other modeling extensions for dynamically creating VLANs.
|
|
|
|
Post by jiaqingzintel on Feb 22, 2023 9:05:06 GMT
I saw there is a new property Links.RelatedInterfaces in EthernetInterface 1.9.0, is this intended being used to represent the relationship with VLAN/bonding interface with the physical one.
For example, posting the following content to create a VLAN on eth0
{
Links: {
RelatedInterfaces: [{ @odata.id: /redfish/v1/Managers/bmc/EthernetInterfaces/eth0 }],
},
VLAN: {
VLANEnable: true,
VLANId: 1234
}
}
If above is okay, should this newly-created VLAN interface show in the RelatedInterfaces of its physical interface?
|
|
|
|
Post by mraineri on Feb 22, 2023 13:39:07 GMT
That is the correct way of performing the POST operation. With the semantics in the property description, you should not have eth0 use RelatedInterfaces to point to its VLAN. However, I think it would be useful for eth0 to point to the VLAN in some manner to show interfaces that eth0 is providing. I can raise that for discussion.
|
|
