This Bug Report affects these Traffic Control components:
Current behavior:
When creating a server with multiple profiles, a user can add a profile from a CDN that does not match up with the server's CDN. This was not allowed previously. This occurs when the profile name is not first in the list.
Expected behavior:
Should not create the server and return:
HTTP/1.1 400 Bad Request
{
"alerts": [
{
"text": "CDN id '1' for profile 'BIND_ALL' does not match Server CDN '2'",
"level": "error"
}
]
}
Steps to reproduce:
Run the latest code on Ciab or CiaBDev and make a POST request to /api/4.0/servers with multiple profiles and use a profile that does not match your server's CDN. In the example below MID_TIER_ATS_CACHE is in CDN with id 2 and BIND_ALL is in CDN with id 1.
E.g.
{
"cachegroupId": 8,
"cdnId": 2,
"domainName": "test.net",
"hostName": "test-01",
"interfaces": [
{
"ipAddresses": [
{
"address": "0.0.0.1",
"gateway": "0.0.0.1",
"serviceAddress": true
}
],
"name": "eth0"
}
],
"physLocationId": 2,
"statusId": 3,
"typeId": 11,
"profileNames": ["MID_TIER_ATS_CACHE", "BIND_ALL"]
}
If you perform the same request where the profile from a different CDN is the first on the list, it will fail, this should be the expected behavior regardless of profile order.
This Bug Report affects these Traffic Control components:
Current behavior:
When creating a server with multiple profiles, a user can add a profile from a CDN that does not match up with the server's CDN. This was not allowed previously. This occurs when the profile name is not first in the list.
Expected behavior:
Should not create the server and return:
Steps to reproduce:
Run the latest code on Ciab or CiaBDev and make a
POSTrequest to/api/4.0/serverswith multiple profiles and use a profile that does not match your server's CDN. In the example belowMID_TIER_ATS_CACHEis in CDN with id 2 andBIND_ALLis in CDN with id 1.E.g.
{ "cachegroupId": 8, "cdnId": 2, "domainName": "test.net", "hostName": "test-01", "interfaces": [ { "ipAddresses": [ { "address": "0.0.0.1", "gateway": "0.0.0.1", "serviceAddress": true } ], "name": "eth0" } ], "physLocationId": 2, "statusId": 3, "typeId": 11, "profileNames": ["MID_TIER_ATS_CACHE", "BIND_ALL"] }If you perform the same request where the profile from a different CDN is the first on the list, it will fail, this should be the expected behavior regardless of profile order.