Skip to content
This repository has been archived by the owner on Oct 9, 2023. It is now read-only.

Added execution config changes #378

Merged
merged 12 commits into from
Mar 25, 2022

Conversation

pmahindrakar-oss
Copy link
Contributor

@pmahindrakar-oss pmahindrakar-oss commented Mar 23, 2022

Signed-off-by: Prafulla Mahindrakar [email protected]

TL;DR

Testing Done

Using only the values.yaml changes

      flyteadmin:
        roleNameKey: "iam.amazonaws.com/role"
        profilerPort: 10254
        metricsScope: "flyte:"
        labels:
          "FlyteLabelKey" : "FlyteLabelValue"
        annotations:
          "FlyteAnnotationKey" : "FlyteAnnotationValue"
        metadataStoragePrefix:
          - "metadata"
          - "admin"
        eventVersion: 2
        testing:
          host: http://flyteadmin

Launched pod

 kubectl get pods  -n flytesnacks-development f5e21f3c6ec3048d8b80-n0-0 -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
    flyteannotationkey: FlyteAnnotationValue
  creationTimestamp: "2022-03-24T14:57:29Z"
  labels:
    domain: development
    execution-id: f5e21f3c6ec3048d8b80
    flytelabelkey: FlyteLabelValue
    interruptible: "false"
    node-id: n0
    project: flytesnacks
    shard-key: "15"
    task-name: core-flyte-basics-lp-greet
    workflow-name: core-flyte-basics-lp-go-greet

With overriden project domain attributes for WORKFLOW_EXECUTION_CONFIG

lytectl get workflow-execution-config -p flytesnacks -d development
{
  "project": "flytesnacks",
  "domain": "development",
  "max_parallelism": 10,
  "security_context": {
    "run_as": {
      "k8s_service_account": "default"
    }
  },
  "raw_output_data_config": {
    "output_location_prefix": "cliOutputLocationPrefix"
  },
  "labels": {
    "values": {
      "cliLabelKey": "cliLabelValue"
    }
  },
  "annotations": {
    "values": {
      "cliAnnotationKeyNew": "cliAnnotationValue"
    }
  }
}%
kubectl get pods  -n flytesnacks-development fe1c87252016c4cf6942-n0-0 -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cliAnnotationKeyNew: cliAnnotationValue
    cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
  creationTimestamp: "2022-03-24T14:58:37Z"
  labels:
    cliLabelKey: cliLabelValue
    domain: development
    execution-id: fe1c87252016c4cf6942
    interruptible: "false"
    node-id: n0
    project: flytesnacks
    shard-key: "8"
    task-name: core-flyte-basics-lp-greet
    workflow-name: core-flyte-basics-lp-go-greet

Worflow level attributes have a bug and hence couldn't be tested and also the current changes don't use workflow level execution config.

Type

  • Bug Fix
  • Feature
  • Plugin

Are all requirements met?

  • Code completed
  • Smoke tested
  • Unit tests added
  • Code documentation added
  • Any pending items have an associated Issue

Complete description

How did you fix the bug, make the feature etc. Link to any design docs etc

Tracking Issue

flyteorg/flyte#2070

Follow-up issue

NA

Comment on lines 41 to 45
Labels: map[string]string{"defaultFlyteLabelKey": "defaultFlyteLabelValue"},
Annotations: map[string]string{"defaultFlyteAnnotationKey": "defaultFlyteAnnotationValue"},
OutputLocationPrefix: "defaultFlyteOutputLocationPrefix",
K8SServiceAccount: "default",
AssumableIamRole: "default",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are we ok with these defaults @katrogan

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, besides setting the K8SServiceAccount are the rest of these actually useful for a flyte execution? maybe we can omit the rest

@codecov
Copy link

codecov bot commented Mar 23, 2022

Codecov Report

Merging #378 (ccffd3d) into master (cc40d26) will increase coverage by 0.23%.
The diff coverage is 82.19%.

❗ Current head ccffd3d differs from pull request most recent head 3e18bf8. Consider uploading reports for the commit 3e18bf8 to get more accurate results

@@            Coverage Diff             @@
##           master     #378      +/-   ##
==========================================
+ Coverage   60.39%   60.62%   +0.23%     
==========================================
  Files         150      150              
  Lines       10708    10739      +31     
==========================================
+ Hits         6467     6511      +44     
+ Misses       3543     3528      -15     
- Partials      698      700       +2     
Flag Coverage Δ
unittests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/rpc/adminservice/base.go 3.88% <ø> (+0.17%) ⬆️
pkg/runtime/application_config_provider.go 12.50% <ø> (ø)
pkg/repositories/database.go 46.72% <50.00%> (+8.34%) ⬆️
pkg/manager/impl/execution_manager.go 73.97% <87.23%> (+0.75%) ⬆️
pkg/manager/impl/util/shared.go 67.11% <100.00%> (+2.88%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc40d26...3e18bf8. Read the comment docs.

// WorkflowExecutionConfigInterface is used as common interface for capturing the common behavior catering to the needs
// of fetching the WorkflowExecutionConfig across LaunchPlanSpec, ExecutionCreateRequest
// MatchableResource_WORKFLOW_EXECUTION_CONFIG and ApplicationConfig
type WorkflowExecutionConfigInterface interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

why does this need to be an interface?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It becomes very convenient now to use the same merge function

mergeIntoExecConfig(workflowExecConfig *admin.WorkflowExecutionConfig, spec WorkflowExecutionConfigInterface)

for launchplan spec, executionCreateRequest, matchable resorce and application config.
Without these we will have to define individual functions for each of these object types.

Abstracting this common functionality across all these make it easier to manage the code.
Let me know if you think otherwise

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, maybe one day flyteorg/flyte#2242 will simplify this!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that would help simplify a lot. I couldn't find a way to do this with current protobuf and faced the same issue with another service we wrote where we had to duplicate the message fields .

Comment on lines 41 to 45
Labels: map[string]string{"defaultFlyteLabelKey": "defaultFlyteLabelValue"},
Annotations: map[string]string{"defaultFlyteAnnotationKey": "defaultFlyteAnnotationValue"},
OutputLocationPrefix: "defaultFlyteOutputLocationPrefix",
K8SServiceAccount: "default",
AssumableIamRole: "default",
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, besides setting the K8SServiceAccount are the rest of these actually useful for a flyte execution? maybe we can omit the rest

Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
@pmahindrakar-oss pmahindrakar-oss force-pushed the pmahindrakar/2070-Project-Domain-Setting branch from 4ad214e to c5ea342 Compare March 24, 2022 10:02
Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
@pmahindrakar-oss
Copy link
Contributor Author

@katrogan i have added default values only for k8ServiceAccount for now . Please have a look at the description along with the mentioned bug for workflow attribute

Copy link
Contributor

@katrogan katrogan left a comment

Choose a reason for hiding this comment

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

mind updating the PR title before merging?

go.mod Outdated Show resolved Hide resolved
// WorkflowExecutionConfigInterface is used as common interface for capturing the common behavior catering to the needs
// of fetching the WorkflowExecutionConfig across LaunchPlanSpec, ExecutionCreateRequest
// MatchableResource_WORKFLOW_EXECUTION_CONFIG and ApplicationConfig
type WorkflowExecutionConfigInterface interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

I see, maybe one day flyteorg/flyte#2242 will simplify this!

if workflowExecConfig.GetSecurityContext() == nil && spec.GetSecurityContext() != nil {
workflowExecConfig.SecurityContext = spec.GetSecurityContext()
}
// Launchplan spec has label, annotation and rawOutputDataConfig initialized with empty values.
Copy link
Contributor

Choose a reason for hiding this comment

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

ah, is this from flytekit serialization? thank you for documenting this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that right

        labels=entity.labels or _common_models.Labels({}),
        annotations=entity.annotations or _common_models.Annotations({}),
        auth_role=entity._auth_role or _common_models.AuthRole(),
        raw_output_data_config=entity.raw_output_data_config or _common_models.RawOutputDataConfig(""),

https://github.com/flyteorg/flytekit/blob/b08e2b6d4cd42f6dc9be86bcec3044b3138e329c/flytekit/tools/translator.py#L224


workflowExecConfig := &admin.WorkflowExecutionConfig{}
// merge the request spec into workflowExecConfig
mergeIntoExecConfig(workflowExecConfig, request.Spec)
Copy link
Contributor

Choose a reason for hiding this comment

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

why this call instead of initializing the workflowExecConfig struct inline with value from the request.Spec?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Two reasons

  • It allows us to not make changes in merge aswell getExecutionConfig whenever a new field is introduced.
  • Since we now want old behavior where if any field is set in request spec then return that execution config immediately instead of checking for other overrides.

So i have kept the function with its return value checked. Let me know what you think

pkg/manager/impl/util/shared.go Outdated Show resolved Hide resolved
workflowExecConfig.Annotations = spec.GetAnnotations()
}
}

// Produces execution-time attributes for workflow execution.
// Defaults to overridable execution values set in the execution create request, then looks at the launch plan values
// (if any) before defaulting to values set in the matchable resource db and further if matchable resources don't
// exist then defaults to one set in application configuration
func (m *ExecutionManager) getExecutionConfig(ctx context.Context, request *admin.ExecutionCreateRequest,
Copy link
Contributor

Choose a reason for hiding this comment

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

what if a user specifies some fields in the execution config in the request spec, but not all?

I think we should then treat that execution config as finalized, and the omitted fields as intentionally excluded.

currently, we keep proceeding with the fallbacks regardless of whether the request spec is populated, or barring that, if the launch plan is then populated. i'm not sure this is right, what do you think? if one of these levels has any non-empty values then should we treat that execution config as the final execution config we apply?

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 wanted this to look like how we do override for go variables and scopes actually define what that level defines the value for that variable
https://go.dev/play/p/jdkv14fHY8N

But we don't have a way to tell protobuf fields that they are set but those are explicitly being set to nil or empty.
i have seen where some libraries provide a behavior of tristate

i.e set (having value/ having no value) / unset(uninitialized)
Something like this tristateBoolean having isUndef https://docs.oracle.com/cd/E26098_01/apirefs.1112/e17493/oracle/ide/util/TriStateBoolean.html#isUndef__

That way it easier to distinguish what the user wanted to do.

Also I think in the current state that issue comes even for maxParallelism = 0 in execution create request and launch plan spec having the same value and it will fall back to other overrides though the user intended to set maxParallelism = 0 in execution create Request

Having a tristate behavior solves such cases and make it easier to reason across overrides and avoid using custom logic IMO.

To keep logic similar to previous one , i am adding a isChanged bool flag in merge function which is checked after the merge from execution create request and launchplan spec and if it gets set then we return that config object.

Let me know what you think.

Copy link
Contributor

Choose a reason for hiding this comment

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

re: the tri-state, we do something funky with one-ofs for notification overrides to permit a user to explicitly disable notifications as opposed to interpreting the optional field as omitted. we could consider updating the execution config in the proto definitions to have some kind of bool flag for "is set" so that even an empty execution config is considered explicitly set

isChanged looks good for now too!

pkg/manager/impl/util/shared_test.go Outdated Show resolved Hide resolved

// Optional: security context override to apply this execution.
// iam_role references the fully qualified name of Identity & Access Management role to impersonate.
AssumableIamRole string `json:"assumableIamRole"`
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: add comments to pflag?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are not using this as pflag config and none of the other fields in this config can be passed from command line.
If we want that behavior then i would need to add a pflag generator and add pflag annotation to all.
Let me know if we need that now or in any future PR's

Copy link
Contributor

Choose a reason for hiding this comment

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

ah okay, nevermind then

Signed-off-by: Prafulla Mahindrakar <[email protected]>
Signed-off-by: Prafulla Mahindrakar <[email protected]>
@pmahindrakar-oss pmahindrakar-oss changed the title WIP : Added execution config changes Added execution config changes Mar 25, 2022
@pmahindrakar-oss pmahindrakar-oss merged commit 56de4b1 into master Mar 25, 2022
@pmahindrakar-oss pmahindrakar-oss deleted the pmahindrakar/2070-Project-Domain-Setting branch March 25, 2022 14:37
eapolinario pushed a commit that referenced this pull request Sep 6, 2023
* Added execution config changes

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* lint fixes

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* using executionConfig data during launch

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* resolve conflicts

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* Removed defaults for labels and annotations

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* added more coverage

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* added more coverage

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* Updating idl and lint fixes

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* Adde missing go.sum

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* feedback changes to return immediately if any field is set while overriding

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* using released flyteidl

Signed-off-by: Prafulla Mahindrakar <[email protected]>

* using released flyteidl

Signed-off-by: Prafulla Mahindrakar <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants