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.

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

[YUNIKORN-2111] Update core application state description in design document #364

Closed
wants to merge 3 commits into from

Conversation

chenyulin0719
Copy link
Contributor

What is this PR for?

  1. Update to latest FSM chart (core application)
  2. Correct Reject/Failed state description. (The application state could move to Expired.)

What type of PR is it?

  • - Bug Fix
  • - Improvement
  • - Feature
  • - Documentation
  • - Hot Fix
  • - Refactoring

Todos

NA

What is the Jira issue?

https://issues.apache.org/jira/browse/YUNIKORN-2111

How should this be tested?

The FSM chart and statement for Failed/Rejected state should be updated.

Screenshots (if appropriate)

scheduler_object_states(en) scheduler_object_states(zh-cn)

Questions:

NA

@chenyulin0719
Copy link
Contributor Author

The 'New' state was represented by a red circle after creating the FSM graph. I can manually convert it to a black and white image if required.

@wilfred-s
Copy link
Contributor

As per the comment in the jira: this should not be part of the design docs. It should be part of the developer guide itself, one level up, at best. The document shows states inside for objects inside the code. That is it shows what is currently implemented, not what was deigned a long time ago. That is something important for a developer, sometimes admin, and will change over time.

@chenyulin0719
Copy link
Contributor Author

Hi @wilfred-s,

Just reviewed the document structure again.
If I move the 'Scheduler Object States' to one level up, it will be mixed up with the 'How to' document.
(The argument point here is should we mixup it up?)

In my opionion, we can keep current implementation in the design document.
As a new developer, checking the design document and understanding how things are currently implemented is quite straightforward for me. (If the design has been changed after 1.3.0, developer could check the old design by change the document version)

Or, we can discuss that should we create parent pages for below document types under developer guide?

  • 'How to' document
  • Current design and implementation
  • Historical design and implementation
image

@wilfred-s
Copy link
Contributor

wilfred-s commented Nov 29, 2023

I would place it after Translation document and before the Designs folder.

@chenyulin0719
Copy link
Contributor Author

Hi @wilfred-s,
Just moved to the developer_guide, thanks for the advice.
Scheduler Object States Page (en)
Scheduler Object States Page (zh-cn)

Copy link
Contributor

@wilfred-s wilfred-s left a comment

Choose a reason for hiding this comment

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

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants