Skip to content
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.

Sign up for GitHub

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

docs: fix formatting of list #613

Merged
merged 2 commits into from
Nov 11, 2024
Merged

docs: fix formatting of list #613

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2991383
docs: fix formatting of list
npepinpe Nov 11, 2024
3e1acfd
fix: use non-numbered sub list
ChrisKujawa Nov 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions chaos-days/blog/2024-10-24-Camunda-Exporter-MVP/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,12 +45,12 @@ The plan for this project looks something like this:
We plan to:

1. Harmonize the existing indices stored in Elasticsearch/Opensearch
2. Space: Reduce the unnecessary data duplication
2. Move importer and archiver logic into a new Camunda exporter
3. Performance: This should allow us to reduce one additional hop (as we don't need to use ES/OS as a queue)
4. Maintenance: Indices and business logic is maintained in one place
5. Scalability: With this approach, we can scale with partitions, as Camunda Exporters are executed for each partition separately (soon partition scaling will be introduced)
6. Complexity: The Camunda Exporter will be built-in and shipped with Zeebe/Camunda 8. No additional pod/application is needed.
2. Space: Reduce the unnecessary data duplication
3. Move importer and archiver logic into a new Camunda exporter
4. Performance: This should allow us to reduce one additional hop (as we don't need to use ES/OS as a queue)
5. Maintenance: Indices and business logic is maintained in one place
6. Scalability: With this approach, we can scale with partitions, as Camunda Exporters are executed for each partition separately (soon partition scaling will be introduced)
7. Complexity: The Camunda Exporter will be built-in and shipped with Zeebe/Camunda 8. No additional pod/application is needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ Actually, this is not how I intended the indention :D

ChrisKujawa marked this conversation as resolved.
Show resolved Hide resolved

Note: Optimize is right now out of scope (due to time), but will later be part of this as well.

Expand Down