Add create router version feature

[deadlycoconuts]

Context

When updating a router with a new configuration, Turing API is currently only able to create a new router version and then deploy it automatically as a single atomic step. This may not be ideal for users who simply intend to create new versions without deploying them, since there isn't an endpoint that support such an operation.

This PR thus introduces a new API endpoint method for Turing API to create a new router version without deploying it automatically, and includes updates to Turing UI and Turing SDK to support this new functionality.

Features

• New endpoint to support the creation of new router versions without deploying them automatically (POST operation with the existing /projects/{project_id}/routers/{router_id}/versions endpoint)

• Introduction of new buttons at the 'Edit Router` diff and confirmation page to reflect the new option to create new router versions without deploying them
  
  

• Introduction of a new SDK method to create new router versions without deploying them

new_router_config = RouterConfig(
    routes=routes,
    rules=rules,
    default_route_id="test",
    experiment_engine=experiment_config,
    resource_request=resource_request,
    timeout="100ms",
    log_config=log_config,
    enricher=None,
    ensembler=None
)

turing.router.config.router_version.RouterVersion.create(new_router_config, my_router_id)

Main Modifications

• api/turing/api/router_versions_api.go - Addition of a new request handler for the new API endpoint method
• api/api/* - Changes to the OpenAPI specs from the addition of the new API endpoint method
• ui/src/router/edit/components/VersionComparisonView.js - Addition of new buttons and onclick handlers to the diff page
• ui/src/router/edit/EditRouterView.js - Addition of additional effects and API calls upon submission
• ui/src/router/components/form/components/VersionCreationSummary.js - Creation of a new confirmation page for router version creation
• sdk/turing/router/router.py - Addition of a method to the Router SDK class to support router version creation
• sdk/turing/session.py - Addition of a support method to support router version creation
• sdk/turing/generated/api/router_api.py - Changes to OpenAPI autogenerated classes from addition of the new API endpoint method

Tiny Fixes

• sdk/requirements.txt - Pinning of cloudpickle==1.2.2 to the requirements list to ensure compatibility with the Mlflow dependency of the pyfunc ensembler service engine

[romanwozniak]

Minor feedback: can we use the secondary color from the elastic EUI color schema (it was removed in the newer version of EUI, but it can be replaced with a similar color) for the Save button, instead of this mustard-yellow color?

Also, what do you all think about simplifying the button labels to Save and Deploy (from the proposed Create without Deploying and Create and Deploy) and instead, add the explanation about the action consequences into the confirmation pop-up window?

[deadlycoconuts]

Minor feedback: can we use the secondary color from the elastic EUI color schema (it was removed in the newer version of EUI, but it can be replaced with a similar color) for the Save button, instead of this mustard-yellow color?

Ahah, I thought yellow looked interesting 😅 The secondary colour is actually green, which also happens to be the same colour as the 'Deployed' symbol, which may be a little confusing:

vs

There's also text which doesn't look too bad:

Otherwise success (successor to the secondary colour), accent, ghost all have a similar shade to the button below, which I think fades a little too much into the background:

Also, what do you all think about simplifying the button labels to Save and Deploy (from the proposed Create without Deploying and Create and Deploy) and instead, add the explanation about the action consequences into the confirmation pop-up window?
I think that sounds like a good idea, it frees up space and makes the UI look more minimalist.

[romanwozniak]

You can also consider somethinbg like this:

Or, use the different shades of blue for Save and Deploy buttons:

[krithika369]

Ahah, I thought yellow looked interesting 😅 The secondary colour is actually green, which also happens to be the same colour as the 'Deployed' symbol, which may be a little confusing:

I agree with this. But the gray color alternative is also the same as "undeployed". :)

Of all the options being discussed, my personal preference is different shades of blue for Save vs Deploy:

[deadlycoconuts]

Alright, lemme get those colours up :D

[krithika369]

Also, what do you all think about simplifying the button labels to Save and Deploy (from the proposed Create without Deploying and Create and Deploy) and instead, add the explanation about the action consequences into the confirmation pop-up window?

Sounds great! The original specs say "Update", "Update and Deploy". I think "Save" and "Deploy" is concise and still conveys the intention.

@deadlycoconuts I haven't reviewed the MR yet but I'd like to confirm - this change is only for the "Edit Router" workflow, right? (The "Create" on the buttons got me wondering.)

[deadlycoconuts]

@deadlycoconuts I haven't reviewed the MR yet but I'd like to confirm - this change is only for the "Edit Router" workflow, right? (The "Create" on the buttons got me wondering.)

Ahah yes, I essentially just added an extra button in the existing "Edit Router" user workflow (to... fork the existing workflow? if that's the right way to say it?). And oh I used "Create" because they were supposed to hint at "Create (Version) and Deploy" and "Create (Version) without Deploying" 😅

[deadlycoconuts]

Would this colour scheme be okay? It's one that uses the default colour palette for the buttons; there doesn't seem to be a way to easily get the lighter-shade blue (because it isn't in the default palette) and I think we'll have to manually pass CSS properties in order to do that:

^ Furthermore the 'Previous' button now corresponds with the 'Cancel' button from the previous page.

Edit: On second thought, we can just leave the customised values for this button without changing the palette (since this alternate colour isn't really used elsewhere):

[romanwozniak]

Would this colour scheme be okay? It's one that uses the default colour palette for the buttons; there doesn't seem to be a way to easily get the lighter-shade blue (because it isn't in the default palette) and I think we'll have to manually pass CSS properties in order to do that: ^ Furthermore the 'Previous' button now corresponds with the 'Cancel' button from the previous page.

Edit: On second thought, we can just leave the customised values for this button without changing the palette (since this alternate colour isn't really used elsewhere):

I like the first option more, especially the part, that 'Previous' is EuiLinkButton

[krithika369]

Thanks for the comprehensive PR and updating the SDK as well. As a side note, we also need to think about updating the user docs (which are currently duplicated in the internal repo for Confluence but we have public docs in this repo too) when the UI implementation changes.

[romanwozniak]

My motivation for using ?deploy=true|false flag was primarily defined by my understanding of the Edit Router call to be in fact:

• Create New Router Version
• (if deploy=true) Then Promote this New Version to serve Router's traffic

So, in this context adding this ?deploy flag makes sense (to me). However, as @krithika369 mentioned before, if you see this call as Edit router configuration with the new version, then this deploy flag is confusing.

In the longer term, it doesn't really matter because after the API controllers are refactored, then most of the business logic will be moved out from the controllers and there will be less of code duplication.

Currently these multiple conditional checks

if toDeploy {
  // ...
}

are not contributing to the code readability, so maybe we should separate these two operations altogether. So in addition to existing
PUT /proejects/{project_id}/routers/{router_id}
We can just add
POST /projects/{project_id}/routers/{router_id}/versions which will create a new version without promoting it.

wdyt @krithika369

P.S. @deadlycoconuts sorry for the miscommunication from my end

[deadlycoconuts]

Pulled this back out from the recycle bin given the latest proposed changes.

[deadlycoconuts]

Okay thanks everyone for the clarification! I've just reverted the changes made to this PR to make it align with the latest proposal to keep the 2 endpoints for the 2 functionalities separate:

• PUT /projects/{project_id}/routers/{router_id}
• POST /projects/{project_id}/routers/{router_id}/versions

Lemme know if there's anything you'd like to add, @romanwozniak and @krithika369

[deadlycoconuts]

Thanks @krithika369 for all the responses and suggestions. I've refactored the CreateOrUpdateRouterRequest to move BuildExperimentEngineConfig and BuildRouterVersion to the request.RouterConfig struct. There aren't many changes beyond that (except for the some refactoring of the unit tests).

I'll be merging this branch if nothing goes wrong with the CI pipeline! 🚀