Add support for host specialization with unencrypted payload

[manikantanallagatla]

Issue describing the changes in this PR

Current assign endpoint takes a encrypted payload for specializing. This is not memory efficient. Adding new API for taking the specialization unencrypted. This will be usedul in ATOL as well

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• [] I have added all required tests (Unit tests, E2E tests)

[Copilot]

Pull Request Overview

This PR adds a new host API endpoint for assigning without encrypted payload to improve memory efficiency. The change introduces a new unencrypted assignment endpoint alongside the existing encrypted one, which will be useful for ATOL scenarios.

Key Changes

• Added a new assignment endpoint that accepts unencrypted payload
• Refactored existing assignment logic into a shared private method
• Created a new model to wrap the unencrypted assignment context

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
StartupContextProvider.cs	Added new overload method to handle unencrypted HostAssignmentContext
FunctionsWorkerContainerAssignmentContext.cs	New model class to wrap assignment context for the new API
InstanceController.cs	Added new assignment endpoint and refactored shared logic into private method

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[jviau]

Instead of adding a new endpoint entirely, can we update EncryptedHostAssignmentContext as follows:

1. rename to HostAssignmentRequest
2. add properties as follows:

public class HostAssignmentRequest
{
    [JsonProperty("encryptedContext")]
    public string EncryptedContext { get; set; }

    [JsonProperty("context")]
    public HostAssignmentContext Context { get; set; }
}

Now callers can choose to supply encrypted or not based on what JSON payload they send. The implementation will then check which of the two properties is not-null and use that.

[manikantanallagatla]

Instead of adding a new endpoint entirely, can we update EncryptedHostAssignmentContext as follows:

1. rename to HostAssignmentRequest
2. add properties as follows:

public class HostAssignmentRequest
{
    [JsonProperty("encryptedContext")]
    public string EncryptedContext { get; set; }

    [JsonProperty("context")]
    public HostAssignmentContext Context { get; set; }
}

Now callers can choose to supply encrypted or not based on what JSON payload they send. The implementation will then check which of the two properties is not-null and use that.

Hi, Thats a valid suggestion. But, that will break backward compatibility and makes it very difficult to deploy. We would need to change current flow of assignment in Antares outside ATOL. We would have to check which hostversion is supporting which endpoint and send object accordingly.

With new endpoint, we can remove old endpoint once we move to endpoint entirely.

In legion as well, we have seperate endppints for encrypted and unencypted payload to make it easier for maintenance

[jviau]

@manikantanallagatla can you expand more on how my proposal limits maintenance? I am not quite understanding your point.

But, that will break backward compatibility and makes it very difficult to deploy.

How so? One API will serve both formats of JSON. The existing encrypted, or the new unencrypted. The caller can send either of the two formats.

{
  "encryptedContext": "< some encrypted string >"
}

or

{
  "context": {
    "siteName": "MySiteName", // and the rest of the object
   }
}

With new endpoint, we can remove old endpoint once we move to endpoint entirely.

And with my proposal we can remove the support for encryptedContext in the JSON payload. But it is highly unlikely we would remove that, as it would be a breaking change.

What this boils down to, is ATOL can call admin/instance/assign with an unencrypted payload. I don't see any benefit from making it explicitly a different endpoint.

[manikantanallagatla]

Instead of adding a new endpoint entirely, can we update EncryptedHostAssignmentContext as follows:

1. rename to HostAssignmentRequest
2. add properties as follows:

public class HostAssignmentRequest
{
    [JsonProperty("encryptedContext")]
    public string EncryptedContext { get; set; }

    [JsonProperty("context")]
    public HostAssignmentContext Context { get; set; }
}

Now callers can choose to supply encrypted or not based on what JSON payload they send. The implementation will then check which of the two properties is not-null and use that.

Hi, Thats a valid suggestion. But, that will break backward compatibility and makes it very difficult to deploy. We would need to change current flow of assignment in Antares outside ATOL. We would have to check which hostversion is supporting which endpoint and send object accordingly.

With new endpoint, we can remove old endpoint once we move to endpoint entirely.

In legion as well, we have seperate endppints for encrypted and unencypted payload to make it easier for maintenance

Oh got it. There is a HostAssignmentContext inside HostAssignmentRequest. I missed that. Apologies.

We can make it a single request with this. I will give it a try. Thanks @jviau

[jviau]

@manikantanallagatla I see you re-requested my review, but I don't see the changes we discussed. There are still 2 separate APIs and encrypted/unencrypted models are not combined into the same top-level type. Are these changes still coming?

[vivekjilla]

@jviau just for my curiosity, why do we want to hack into existing api and break the request model object structure from current flow and combining multiple properties where only one is used at any given time, instead of keeping the cleaner segregation with different APIs and their models, and not breaking/modifying the current API on the way.

@manikantanallagatla let's ensure any changes here are aligned by everyone and thought through, because I think we might be making some changes on Legion Platform side or Go Server code to call these APIs while maintaining backward compatibility. Might have to change all those if we have to retrofit new behavior into existing API without breaking the current flows.

[manikantanallagatla]

@jviau , I merged the APIs into 1 API and requested review. Then when I discussed with Bala, we wanted two separate APIs so that it is cleaner. So, I again reverted that commit of merging into 1 API. Anyways I will start a thread in teams to have a conclusion on 1 API vs 2 APIs.

[jviau]

@jviau just for my curiosity, why do we want to hack into existing api and break the request model object structure from current flow and combining multiple properties where only one is used at any given time, instead of keeping the cleaner segregation with different APIs and their models, and not breaking/modifying the current API on the way.

I don't see this as a hack at all. It doesn't break anything. We are effectively turning the existing JSON payload into a "One-Of" structure. It is either the encrypted payload or the unencrypted payload, and the existing API will determine what assign flow to use based on the shape of the JSON input. We can add validation in the API handler to assert only one can be set at a time. I do not think having an assign and assign2 API is cleaner in any ways. I think my approach is much cleaner. Because again, the API will not break for existing callers.

Existing callers. This is the same as today, and it will be the same after my suggested changes. There is no change for these callers.

POST "admin/instance/assign"

{
    "encryptedContext": "< encrypted context >"
}

NEW callers wanting unencrypted assign:

POST "admin/instance/assign"

{
    "context":  {
        // unencrypted host assignment context
    }
}

Additional scenario which will result in an HTTP 400. Callers will not be allowed to provide both encrypted and unencrypted context.

POST "admin/instance/assign"

{
    "encryptedContext": "< encrypted context >",
    "context":  {
        // unencrypted host assignment context
    }
}