Skip to content
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.

FLPATH-377: workflow log #368

Merged
merged 1 commit into from
May 26, 2023

Conversation

RichardW98
Copy link
Contributor

@RichardW98 RichardW98 commented May 23, 2023

What this PR does / why we need it:
display custom log in ui
Which issue(s) this PR fixes
Fixes #FLPATH-377

Change type

  • New feature
  • Bug fix
  • Unit tests
  • Integration tests
  • CI
  • Documentation
  • Auto-generated SDK code

Impacted services

  • Workflow Service
  • Notification Service

Checklist

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.

@openshift-ci openshift-ci bot requested review from eloycoto and lshannon May 23, 2023 20:07
@RichardW98 RichardW98 changed the title workflow log FLPATH-377: workflow log May 23, 2023
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented May 23, 2023

@RichardW98: This pull request references FLPATH-377 which is a valid jira issue.

In response to this:

What this PR does / why we need it:
display custom log in ui
Which issue(s) this PR fixes
Fixes #FLPATH-377

Change type

  • New feature
  • Bug fix
  • Unit tests
  • Integration tests
  • CI
  • Documentation
  • Auto-generated SDK code

Impacted services

  • Workflow Service
  • Notification Service

Checklist

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@RichardW98 RichardW98 requested a review from wKich May 23, 2023 20:08
@RichardW98 RichardW98 force-pushed the FLPATH-377-log branch 3 times, most recently from 519a106 to db31d86 Compare May 24, 2023 02:33

public enum LogType {

TEXT(""), INFO("\u001B[32m"), WARNING("\u001B[33m"), ERROR("\u001B[34m"), END("\u001B[39m");
Copy link
Collaborator

Choose a reason for hiding this comment

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

It seems to me that we are mixing few things here. We have log levels (info, warn, err) and not log levels text and end. I think we should split

private String log;

public void addLog(String nextLog) {
log = log + "\n" + nextLog;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do we want to keep logs in single line?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will remove \n


@Override
public String toString() {
return logType.getCode() + logText + (logType.getCode().isEmpty() ? "" : LogType.END.getCode());
Copy link
Collaborator

Choose a reason for hiding this comment

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

do we care about timestamp? How do we know what was the order of logs?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the current order is the sequence of calling addLog(), which will append the new log to end. but yes we need to support timestamp

@eloycoto
Copy link
Collaborator

I do not really like the implementation TBH. As a user experience, I think that it's not great. For me, the implementation should be something.

this.log.error()
this.log.info()

And execute context should be inherent inside the class, and the log should log the workflow.ID as wid='context.get(workflowid)' In this way, a user can retrieve all the logs related to a workflow based on a simple query in any 3-party tool (Loki, ElasticSearch, etc..)

Dancing the context with multiple functions is not the best, and a function like addTaskLog is not great for user experience.

But the code lgtm.

@RichardW98
Copy link
Contributor Author

agree. from user experience, we should simplify the code to get context property. I will fix it in next PR.

@RichardW98
Copy link
Contributor Author

Copy link
Collaborator

@masayag masayag left a comment

Choose a reason for hiding this comment

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

Generally speaking, would we like to consider alternative storage to store the data in the DB?


public enum LogType {

TEXT(""), INFO("\u001B[32m"), WARNING("\u001B[33m"), ERROR("\u001B[34m"), END("\u001B[39m");
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is the usage of the code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

to set log level and its ansi code for color


import lombok.Getter;

public enum LogType {
Copy link
Collaborator

Choose a reason for hiding this comment

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

LogLevel seems like a common name for this, but I may not get the role of this enum, however, END doesn't fall into that category.
perhaps LogEntryType ?

Copy link
Contributor Author

@RichardW98 RichardW98 May 24, 2023

Choose a reason for hiding this comment

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

I will rename to loglevel to comply with standards

@@ -0,0 +1,11 @@
package com.redhat.parodos.workflow.log;
Copy link
Collaborator

Choose a reason for hiding this comment

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

seems it should go under
com.redhat.parodos.workflow.log.service package
but perhaps this is okay for the parodos-model-api

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok I will move to log.service and log.dto


import java.util.UUID;

public interface WorkFlowLogService {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Pls add javadoc. This interface may be in use by workflow developers, It will be useful to have it documented (although the API itself is clear enough)


public interface WorkFlowLogService {

String getLog(UUID workflowExecutionId, String taskName);
Copy link
Collaborator

Choose a reason for hiding this comment

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

seems like the majorify uses workFlowExecutionId (capital F)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, naming convention is workFlow***

}

@Override
public void writeLog(UUID mainWorkflowExecutionId, String taskName, WorkFlowTaskLog workFlowTaskLog) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

is it a must to have the main workflow execution id? what about complex workflow where a workunit is a type of workflow: Can logs be added to it as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the main workflow execution id here is used to find the workFlowTaskExecution which attached to it. The log is stored on task level which has real execute logic

private WorkFlowTaskExecution getWorkFlowTaskExecution(UUID mainWorkflowExecutionId, String taskName) {
WorkFlowTaskDefinition workFlowTaskDefinition = Optional
.ofNullable(workFlowTaskDefinitionRepository.findFirstByName(taskName))
.orElseThrow(() -> new ResourceNotFoundException("task is not found!"));
Copy link
Collaborator

Choose a reason for hiding this comment

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

Pls extend ResourceType and use

ResourceNotFoundException(ResourceType.WORKFLOW_TASK, IDType.NAME, taskName)

WorkFlowExecution workFlowExecution = Optional
.ofNullable(workFlowRepository.findFirstByMainWorkFlowExecutionIdAndWorkFlowDefinitionId(
mainWorkflowExecutionId, workFlowTaskDefinition.getWorkFlowDefinition().getId()))
.orElseThrow(() -> new ResourceNotFoundException("workflow execution is not found!"));
Copy link
Collaborator

Choose a reason for hiding this comment

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

here as well:

new ResourceNotFoundException(ResourceType.WORKFLOW_EXECUTION, workFlowExecutionId)

workFlowExecution.getId(), workFlowTaskDefinition.getId()))
.filter(workFlowTaskExecutions -> !workFlowTaskExecutions.isEmpty())
.map(workFlowTaskExecutions -> workFlowTaskExecutions.get(0))
.orElseThrow(() -> new ResourceNotFoundException("task execution is not found!"));
Copy link
Collaborator

Choose a reason for hiding this comment

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

and here.

@ApiResponse(responseCode = "401", description = "Unauthorized", content = @Content),
@ApiResponse(responseCode = "403", description = "Forbidden", content = @Content) })
@GetMapping("/{workFlowExecutionId}/{taskName}/log")
public ResponseEntity<String> getLog(@PathVariable UUID workFlowExecutionId, @PathVariable String taskName) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

pls add tests to WorkFlowControllerTest

@eloycoto
Copy link
Collaborator

agree. from user experience, we should simplify the code to get context property. I will fix it in next PR.

TBH, keep creating Jira tickets while we keep accumulating tech debt it's a bad idea IMHO.

@RichardW98
Copy link
Contributor Author

agree. from user experience, we should simplify the code to get context property. I will fix it in next PR.

TBH, keep creating Jira tickets while we keep accumulating tech debt it's a bad idea IMHO.

ok I will fix the related workcontext properties in this pr 😄 . and leave the rest in next one

@RichardW98 RichardW98 force-pushed the FLPATH-377-log branch 5 times, most recently from 88a115b to 17925c4 Compare May 24, 2023 22:00
Copy link
Collaborator

@pkliczewski pkliczewski left a comment

Choose a reason for hiding this comment

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

/lgtm

@RichardW98 RichardW98 force-pushed the FLPATH-377-log branch 4 times, most recently from aee0596 to 8666c50 Compare May 25, 2023 18:21
Copy link
Collaborator

@pkliczewski pkliczewski left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm label May 26, 2023
@openshift-ci
Copy link

openshift-ci bot commented May 26, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anludke

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit bdbdd31 into parodos-dev:main May 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants