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

Update ExecutionDetails to use new NodeExecution children endpoint #438

Closed
schottra opened this issue Jul 31, 2020 · 1 comment
Closed
Assignees
Labels
ui Admin console user interface
Milestone

Comments

@schottra
Copy link
Contributor

schottra commented Jul 31, 2020

Depends on flyteorg/flyteadmin#111

Now that Admin can return children of a NodeExecution directly, we can update the code for fetching them in flyteconsole, skipping the step which fetches the intermediate task execution if the NodeExecution follows the new format (presence of an is_parent field).

Children are organized using a new retry_group field, which should control how they are grouped in the NodeExecutions list.

@schottra schottra added task ui Admin console user interface labels Jul 31, 2020
@schottra schottra added this to the 0.8.0 milestone Jul 31, 2020
@schottra schottra self-assigned this Jul 31, 2020
@anandswaminathan anandswaminathan modified the milestones: 0.8.0, 0.9.0 Sep 30, 2020
@schottra
Copy link
Contributor Author

Implemented in flyteorg/flyteconsole#109
Available in flyteconsole v0.14.0

eapolinario pushed a commit to eapolinario/flyte that referenced this issue Dec 6, 2022
eapolinario pushed a commit to eapolinario/flyte that referenced this issue Aug 9, 2023
eapolinario pushed a commit to eapolinario/flyte that referenced this issue Apr 30, 2024
Before, updating some field (i.e. `Description`) of an `Archived` project causes the project state to
change to `Active`. This is caused by a bug in the `updateProjectsFunc` function used for the `update` command.

During project updates, `edited`, a default project created based on the given configs/flags,
comes with `admin.Project_ACTIVE` state by default if both `activate` and `archive` flags 
have not been set. 

Then a `copy` of the target project will be updated based on `edited` and then used for showing
the diff. In the current implementation, the state of the `copy` is set to be the same as `edited` 
projects state, which is `Project_ACTIVE` if no flags are set.

Also, after showing the diff, the `edited` is used for updating the project. Since it comes
with `Project_ACTIVE` state by default, the target project will be updated to have `Project_ACTIVE`
if both `activate` and `archive` flags are unset, regardless of the projects previous state.

On this PR, we make sure we set the correct state to both `copy` and `edited` by checking 
if  both `activate` and `archive` flags are set/unset. If one of the flags are set, we update target
project state (`copy`) based on the `edited` state since it will have the desired state. If both
flags are unset, we set the `edited` state to be the same as target (`copy`) state. This way, updating
`archived` projects will not change their state.

Signed-off-by: mcanueste <mcanueste@gmail.com>
eapolinario pushed a commit to eapolinario/flyte that referenced this issue Apr 30, 2024
Before, updating some field (i.e. `Description`) of an `Archived` project causes the project state to
change to `Active`. This is caused by a bug in the `updateProjectsFunc` function used for the `update` command.

During project updates, `edited`, a default project created based on the given configs/flags,
comes with `admin.Project_ACTIVE` state by default if both `activate` and `archive` flags 
have not been set. 

Then a `copy` of the target project will be updated based on `edited` and then used for showing
the diff. In the current implementation, the state of the `copy` is set to be the same as `edited` 
projects state, which is `Project_ACTIVE` if no flags are set.

Also, after showing the diff, the `edited` is used for updating the project. Since it comes
with `Project_ACTIVE` state by default, the target project will be updated to have `Project_ACTIVE`
if both `activate` and `archive` flags are unset, regardless of the projects previous state.

On this PR, we make sure we set the correct state to both `copy` and `edited` by checking 
if  both `activate` and `archive` flags are set/unset. If one of the flags are set, we update target
project state (`copy`) based on the `edited` state since it will have the desired state. If both
flags are unset, we set the `edited` state to be the same as target (`copy`) state. This way, updating
`archived` projects will not change their state.

Signed-off-by: mcanueste <mcanueste@gmail.com>
austin362667 pushed a commit to austin362667/flyte that referenced this issue May 7, 2024
Before, updating some field (i.e. `Description`) of an `Archived` project causes the project state to
change to `Active`. This is caused by a bug in the `updateProjectsFunc` function used for the `update` command.

During project updates, `edited`, a default project created based on the given configs/flags,
comes with `admin.Project_ACTIVE` state by default if both `activate` and `archive` flags 
have not been set. 

Then a `copy` of the target project will be updated based on `edited` and then used for showing
the diff. In the current implementation, the state of the `copy` is set to be the same as `edited` 
projects state, which is `Project_ACTIVE` if no flags are set.

Also, after showing the diff, the `edited` is used for updating the project. Since it comes
with `Project_ACTIVE` state by default, the target project will be updated to have `Project_ACTIVE`
if both `activate` and `archive` flags are unset, regardless of the projects previous state.

On this PR, we make sure we set the correct state to both `copy` and `edited` by checking 
if  both `activate` and `archive` flags are set/unset. If one of the flags are set, we update target
project state (`copy`) based on the `edited` state since it will have the desired state. If both
flags are unset, we set the `edited` state to be the same as target (`copy`) state. This way, updating
`archived` projects will not change their state.

Signed-off-by: mcanueste <mcanueste@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui Admin console user interface
Projects
None yet
Development

No branches or pull requests

2 participants