Patch different values for Domain part in FQDN & HostName

ginugeorge
Minnow

Posts: 28

Patch different values for Domain part in FQDN & HostName Sept 5, 2023 11:11:37 GMT

Quote

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 ?

mraineri
Administrator

Posts: 1,062

Patch different values for Domain part in FQDN & HostName Sept 5, 2023 13:20:20 GMT

Quote

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.

ginugeorge
Minnow

Posts: 28

Patch different values for Domain part in FQDN & HostName Sept 12, 2023 5:05:09 GMT

Quote

Post by ginugeorge on Sept 12, 2023 5:05:09 GMT

Sept 5, 2023 13:20:20 GMT mraineri said:

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.

ginugeorge
Minnow

Posts: 28

Patch different values for Domain part in FQDN & HostName Dec 7, 2023 9:11:19 GMT

Quote

Post by ginugeorge on Dec 7, 2023 9:11:19 GMT

mraineri

There are 3 possible outcomes that can be considered as mentioned below :

1. When user provides different values for Host Name Part in FQDN attribute(for e.g. usersupport) and HostName attribute (adminsupport), we can throw 400 Bad Request stating both attributes need to be configurable without creating any conflicts. This is the simplest approach.

2. HostName attribute is given more priority over the FQDN attribute. In this case, the updated values will be different from what the user provided in the request body.

3. FQDN attribute is given more priority over the HostName attribute. In this case, the updated values will be different from what the user provided in the request body.

Please let us know if you have any update on this. Thanks in Advance.

Last Edit: Dec 7, 2023 10:10:30 GMT by ginugeorge

jautor
Administrator

Posts: 505

Patch different values for Domain part in FQDN & HostName Dec 8, 2023 18:26:27 GMT

Quote

Post by jautor on Dec 8, 2023 18:26:27 GMT

Dec 7, 2023 9:11:19 GMT ginugeorge said:

1. When user provides different values for Host Name Part in FQDN attribute(for e.g. usersupport) and HostName attribute (adminsupport), we can throw 400 Bad Request stating both attributes need to be configurable without creating any conflicts. This is the simplest approach.

Yes, if the PATCH request includes both properties, and they are in conflict with each other, 400 would be the appropriate response. And we have the Base message `PropertyValueConflict` to provide error details to the client.

The issue we need to tackle (and are asking for feedback on the recommendation language) is what happens if the PATCH includes only one of those, and the value conflicts with the unchanged other property. My suggested text would recommend that a PATCH on FQDN that conflicts with the existing value of HostName could update the HostName value (as it's obvious?), assuming the client just didn't include it. But I would reject a change to HostName that conflicts with FQDN - because the service can't assume the correct value.

The alternative (and perhaps the safer one) would be to recommend that both properties should be updated together...

Jeff