|
Post by ginugeorge on Sept 5, 2023 11:11:37 GMT
We are aware about the fact that FQDN consists of the hostname and domain name as mentioned below :
"A fully-qualified domain name (FQDN) is a complete domain name that specifies the exact location of a computer or a host on the internet. It consists of the hostname and domain name."
As per the Manager Ethernet Interfaces Schema, we have two attributes namely FQDN and HostName.
Suppose if we trigger a PATCH with the below request body,
{
"FQDN": "usersupport.google.com",
} we know that HostName will be updated to the value "usersupport" and FQDN will be updated to the value "usersupport.google.com"
Suppose if we trigger a PATCH with the below request body,
{
"HostName": "adminsupport",
}
we know that HostName will be updated to the value "adminsupport" and FQDN will be updated to the value "adminsupport.google.com" Consider, we trigger a PATCH with the below request body(i.e. provide different values for Domain part in FQDN(usersupport) and HostName(adminsupport))
{
"FQDN": "usersupport.google.com",
"HostName": "adminsupport"
}
What should be the values of HostName and FQDN be updated to ? Which attribute will have priority over the other ? Does the user needs to pass same values for Domain part in FQDN and HostName ?
|
|
|
Post by mraineri on Sept 5, 2023 13:20:20 GMT
Good question... We had a similar problem with DateTime and DateTimeLocalOffset in Manager, and we had to add the following statement to DateTimeLocalOffset:
> If both DateTime and DateTimeLocalOffset are provided in modification requests, services shall apply DateTimeLocalOffset after DateTime is applied.
I suspect we'll need to add something similar here. I'll raise this to others.
|
|
|
Post by ginugeorge on Sept 12, 2023 5:05:09 GMT
Good question... We had a similar problem with DateTime and DateTimeLocalOffset in Manager, and we had to add the following statement to DateTimeLocalOffset: > If both DateTime and DateTimeLocalOffset are provided in modification requests, services shall apply DateTimeLocalOffset after DateTime is applied. I suspect we'll need to add something similar here. I'll raise this to others. Please let us know if you have any update on this. Thanks in Advance.
|
|