-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update eqx init
to support Serverless re #244
#245
Update eqx init
to support Serverless re #244
#245
Conversation
Interesting to look at how its done in V4 - maybe if no RUs are specified, it should not touch the RUs? In general this looks great - I want to do some other merges/syncs with v2 branches before I merge this but it should be later today :fingerscrossed: |
eqx init
to address serverless account type allocations and adjustments resolves #244eqx init
to support Serverless; Resolves #244
let client,dName,cName = conn log sargs | ||
log.Information("Provisioning `Equinox.CosmosStore` Store at {mode:l} level for {rus:n0} RU/s", modeStr, rus) | ||
let mode = (CosmosInitInfo iargs).ProvisioningMode | ||
match mode with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arguably, this logging code could move up into CosmosInitInfo
- splitting parsing/logging from the doing, but in general in the tool, I don't follow the rules the templates do to the same degree
Confirmed the functionality of serverless provisioning for after the merges. One thought I did have around this when I was implementing the provisioning logic was that the aux container setup may also need the same updates to support serverless. I also didn't see right away if the aux container provisioning supported the shared Db RUs or not. |
Thanks for all the work and for validating; I'll merge it and cherry-pick it onto the The aux provisioning is driven by propulsion.tool in the propulsion repo. In general, if you're running a CFP somewhere with state in an aux container, you can be pretty sure there's continual usage (not sure how triggers run with Azure Functions driven off CFPs though) As a result, I'd say you want to stick with non-serverless allocation for aux containers, in general. The V3 API has a variety of scenarios for how one can consume from a Change Feed (i.e. its not hard wired to storing state in an aux container in the same way). |
eqx init
to support Serverless; Resolves #244eqx init
to support Serverless re #244
* Add configuration for init tool to support Cosmos DB Serverless accounts. * Update inline help text to include default value if not provided.
* Add configuration for init tool to support Cosmos DB Serverless accounts. * Update inline help text to include default value if not provided.
(☝️ Second is the relevant commit on |
resolves #244