You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feature: support for availability zone multi-instance app service plans #12
Is your feature request related to a problem? Please describe.
Feature:
add support for multi-instanced app service plans.
Problem:
I had deployed the aznamingtool container to a shared app service plan that is configured across 3 availabilty zones.
Using a terraform module to make various name requests to the aznamingtools rest api to generate names, the app UI would lock up and eventually not responds.
After looking into the adminlogs I had noticed that the adminlogmessages.json and generatednames.json files would sometimes corrupt in the azure file share.
I had configured the webapp with session affinity which helped but still saw the issue with adminlogmessages and generatednames logs conflicts and stating the "title":"ERROR","message":"The process cannot access the file \u0027/app/settings/adminlogmessages.json\u0027 because it is being used by another process.".
Describe the solution you'd like
rest API endpoint to generate a collection of names.
Support for availability zones app service plans.
Alternate data store for config and logs (not sure its im about out of my depth on application architecture).
Describe alternatives you've considered
current workaround was to deploy the application on a seperate app service plan.
when deployed on teh az app service plan, i had enabled session affinity within the webapp which helped but the rapid api calls to generate names hitting various instances caused the updates to the json files to corrupt.
Thank you for your feedback! The tool was originally designed to be 100% self-contained, meaning there was no dependency on any external systems to run and use the features. Because of that design, it doesn't really lend itself to accommodate a multi-instance deployment at this time. As documented, the site uses JSON files to store the configuration, which presents an issue when multiple actions are attempting to update the configuration at one time (as in the case of a multi-instance deployment).
We would like to add this capability, however, we will need to evaluate the best way to implement, while retaining our "zero dependency" design. We will add this feature request to our backlog and consider it for future versions.
Activity
BryanSoltis commentedon Aug 28, 2023
Hello NoogSta,
Thank you for your feedback! The tool was originally designed to be 100% self-contained, meaning there was no dependency on any external systems to run and use the features. Because of that design, it doesn't really lend itself to accommodate a multi-instance deployment at this time. As documented, the site uses JSON files to store the configuration, which presents an issue when multiple actions are attempting to update the configuration at one time (as in the case of a multi-instance deployment).
We would like to add this capability, however, we will need to evaluate the best way to implement, while retaining our "zero dependency" design. We will add this feature request to our backlog and consider it for future versions.
Thank you!
test: Add comprehensive unit tests for StorageMigrationService
Merge pull request #12 from BryanSoltis/dev