changelog-app[bot]
commented
7 months ago Generate changelog in changelog-dir>`changelog/@unreleased`</changelog-dir
What do the change types mean?
- `feature`: A new feature of the service. - `improvement`: An incremental improvement in the functionality or operation of the service. - `fix`: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way. - `break`: Has the potential to break consumers of this service's API, inclusive of both Palantir services and external consumers of the service's API (e.g. customer-written software or integrations). - `deprecation`: Advertises the intention to remove service functionality without any change to the operation of the service itself. - `manualTask`: Requires the possibility of manual intervention (running a script, eyeballing configuration, performing database surgery, ...) at the time of upgrade for it to succeed. - `migration`: A fully automatic upgrade migration task with no engineer input required. _Note: only one type should be chosen._How are new versions calculated?
- ❗The `break` and `manual task` changelog types will result in a major release! - 🐛 The `fix` changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease. - ✨ All others will result in a minor version release.Type
Description
jeremyk-91
General
Before this PR: The workload server was missing some configuration, because the path to create the server in prod and test is different (!!)
After this PR:
==COMMIT_MSG== The workload server now has runMode: ONE specified by default. ==COMMIT_MSG==
Priority: dev P0
Concerns / possible downsides (what feedback would you like?): The point marked (!!) is still true
Is documentation needed?: No
Compatibility
Antithesis workload server change
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: Nothing in particular
What was existing testing like? What have you done to improve it?: This is unfortunately still not ideal
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.): Containers start
Has the safety of all log arguments been decided correctly?: N/A
Will this change significantly affect our spending on metrics or logs?: No
How would I tell that this PR does not work in production? (monitors, etc.): Containers still fail
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?: Yeah, rollback
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Antithesis workload server change
Development Process
Where should we start reviewing?: Is small
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?: It's a +2
Please tag any other people who should be aware of this PR: @jeremyk-91 @sverma30 @raiju