[SVLS-9256] auto-mark dd env sticky on slot instrumentation#2340
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
🎉 All green!🧪 All tests passed 🔗 Commit SHA: cb356f8 | Docs | Datadog PR Page | Give us feedback! |
ava-silver
added
enhancement
34ec27c to
bab86f4
Compare
| this.instrumentSidecar(aasClient, config, resourceGroup, webApp, isContainer, existingEnvVars), | ||
| this.makeStickySlotEnvVars(aasClient, resourceGroup, webApp, config), |
There was a problem hiding this comment.
Will we ever want to instrument a web app and not make the slot env vars sticky? Is it worth moving this into instrumentSidecar / instrumentExtension
There was a problem hiding this comment.
No, but also the current functions of instrumentSidecar/instrumentExtension are for conceptually splitting out the logic needed to update the config/extension, rather than for splitting out the entire instrumentation process. we currently also have this same pattern for updating tags, so I'm inclined to say its fine here, especially since it makes parallelization much easier than putting the calls into the instrument* bodies
ea23e68 to
7556a51
Compare
0cf934c to
e832323
Compare
e832323 to
cb356f8
Compare
4 participants
What and why?
In Azure App Service, a slot swap swaps app settings between slots by default.
DD_ENVshould be a sticky slot setting so a slot keeps its own environment tag after a swap, instead of the production slot'sDD_ENVbleeding into staging.This makes
aas instrumentregisterDD_ENVas a sticky slot setting whenever a slot is instrumented with--env. Non-slot instrumentation is unaffected.How?
common.ts:StickySlotSettingsdescribes the sticky names a site needs (resourceGroup,webAppName,names).aggregateStickyBySitecollapses the per-resource sticky settings reported during instrumentation into one entry per site, unioning their names.slotConfigNamesis a single site-level resource shared by all of a site's slots, so it keys by web app name (App Service names are globally unique) and writes each site once -- avoiding the concurrent read-modify-writes (and Azure 409s) that would happen if multiple slots of the same app each wrote it.registerStickySlotSettingsperforms that single read-modify-write, appending any missing names viaupdateSlotConfigurationNames. It no-ops when the names are already sticky, logs the action, and honors dry-run.instrument.ts:processWebAppnow returns aProcessResult({success, sticky?}) instead of a bare boolean, reporting the sticky settings the resource needs on its parent site (justDD_ENV, and only for slots with--env).processSubscriptionaggregates those results and registers the sticky settings once per site after all resources are processed.Review checklist