Update Recipe registration to separate API

[vishwahiremat]

Overview

Update handling of registering and unregistering recipes/dev recipes to ensure users can add and remove recipes from the environment after it is created. This includes manipulating the dev recipes available on the environment.

Objectives

User scenarios

• Allow operators to register recipes to an environment.
• Allow operators to unregister a recipe on an environment.

  Goals

• Users should be able to seamlessly register and unregister all recipes (user-provided and dev recipes) available on an environment.

  Design Requirements

  Requirements

• CLI commands should follow the existing patterns we use for other resource types.
  • If possible, the CLI commands should not change
  • The commands should be idempotent.
• Dev recipes and user recipes should look similar to the developer. To the operator, outside of understanding what ‘reserved recipe names’ are, they should also look similar.

  Dependencies

  CoreRP: Required to update the environment with the set of recipes available on the environment. CLI: Required to get user input of recipe and to display success/failure of register/unregister

Design

High-level design

• User calls CLI to register/unregister a specific recipe.
• CLI calls CoreRP with the details provided by the user.
• CoreRP attempts to update the environment by adding/removing the recipe from the list of recipes on the environment and responds with a success/failure as applicable.
• CLI posts the success/failure of the call to the command line.

Detail design

Breaking down step 2 in the high-level design:

• CLI calls /{rootScope}/providers/Applications.Core/environments/{environmentName}/registerRecipe or /{rootScope}/providers/Applications.Core/environments/{environmentName} /unregisterRecipe as applicable.

Breaking down step 4 in the high-level design:

• Name conflicts with other user-defined recipes should result in a message that the recipe was updated.
• Unregistering a recipe that doesn’t exist should result in a message that the recipe doesn’t exist.

As a side note, devRecipes will have a tag on them to specify that they are devRecipes to enable users to see that when listing available recipes on an environment.

Advantages:

This design works to move recipes to be as close to a resource as possible (e.g more similar to how environments, etc. are handled) with a create/delete/get action. It also removes means the CLI no longer handles name conflicts for recipes or checks for the existence of a recipe – the server can now handle that.

Disadvantages:

It adds additional custom actions to our API spec. Unfortunately, these look a little off as we have to define them as POST methods and make the API itself be descriptive of it being a PUT/DELETE. This might also mean that it is a little ‘heavier’ as we have additional code to handle new routes (generated clients, etc.)

AB#6771

[kachawla]

@vishwahiremat I'm a bit confused with the mention of dev recipes here, we do not intend to continue with the current direction of dev recipes. Was this issue copied pasted from the design doc reviewed by Sneha? In that case did we incorporate feedback from the design discussion in this?

[vishwahiremat]

@vishwahiremat I'm a bit confused with the mention of dev recipes here, we do not intend to continue with the current direction of dev recipes. Was this issue copied pasted from the design doc reviewed by Sneha? In that case did we incorporate feedback from the design discussion in this?

@kachawla , thats correct it was copied from the design doc reviewed by Sneha, the tasks created are based on feedback from the design discussion. But I believe with the introduction of recipe packs we will not be following the current design/tasks?

[kachawla]

@vishwahiremat I'm a bit confused with the mention of dev recipes here, we do not intend to continue with the current direction of dev recipes. Was this issue copied pasted from the design doc reviewed by Sneha? In that case did we incorporate feedback from the design discussion in this?

@kachawla , thats correct it was copied from the design doc reviewed by Sneha, the tasks created are based on feedback from the design discussion. But I believe with the introduction of recipe packs we will not be following the current design/tasks?

Recipe packs and dev recipes are orthogonal and were completely skipped in this review. Main discussion and outcome of this design review was to implement server side APIs for recipe management. Was that not captured in the meeting notes?

[vishwahiremat]

@vishwahiremat I'm a bit confused with the mention of dev recipes here, we do not intend to continue with the current direction of dev recipes. Was this issue copied pasted from the design doc reviewed by Sneha? In that case did we incorporate feedback from the design discussion in this?

@kachawla , thats correct it was copied from the design doc reviewed by Sneha, the tasks created are based on feedback from the design discussion. But I believe with the introduction of recipe packs we will not be following the current design/tasks?

Recipe packs and dev recipes are orthogonal and were completely skipped in this review. Main discussion and outcome of this design review was to implement server side APIs for recipe management. Was that not captured in the meeting notes?

you are right, i was confused with registering dev recipes. We wanted to create tasks out of the development plan so I copied the design doc here briefly, will updated it with detailed design from the doc. Thanks

[AaronCrawfis]

Notes from 6/13

Goals of this work item unclear. We should identity why the proposed work in this issue is important. Concurrency can be handled via etags

[kachawla]

This was reviewed in the team wide design review in Feb, everyone aligned on the goals, here is the doc that was reviewed https://microsoft.sharepoint.com/:w:/t/radiuscoreteam/EaR7DEQTD-BIn4Gy5xBnpmkBRXflyGtJOr_MvShN_j4IuQ?e=5IhlE0. I'm assuming it needs to re-reviewed if folks have different opinion now from what was agreed upon in previous review?