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

add missing read for K8S config file from conn in deferred KubernetesPodOperator #29498

Merged
merged 7 commits into from
Apr 22, 2023

Conversation

hussein-awala
Copy link
Member

closes: #29488


The async execute method of KubernetesPodOperator doesn't check if the config_path is provided in the connection extra, this PR fixes this by extracting the config path in order to read it and convert it to dictionary.

@boring-cyborg boring-cyborg bot added provider:cncf-kubernetes Kubernetes provider related issues area:providers labels Feb 12, 2023
@hussein-awala hussein-awala changed the title [WIP] add missing read for K8S config file from conn in deferred KubernetesPodOperator add missing read for K8S config file from conn in deferred KubernetesPodOperator Feb 13, 2023
@@ -565,7 +565,16 @@ def execute_async(self, context: Context):

def convert_config_file_to_dict(self):
"""Converts passed config_file to dict format."""
config_file = self.config_file if self.config_file else os.environ.get(KUBE_CONFIG_ENV_VAR)
config_file = None
Copy link
Contributor

Choose a reason for hiding this comment

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

thanks @hussein-awala for proposing this fix.

why the async need the function convert_config_file_to_dictand not the sync ?

Look like the async was implemented not fully following this pattern -> #20578

your PR fix the problems for the extra config_path , there is a risk that another is missing or new in the future would need "manual" fix like this

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure about the initial reason to convert the file into dictionary before creating the trigger, it may be to avoid copying the config file to the triggerer, where the pod is created on the worker using the sync hook and the waiting task is running on the triggerer and it uses the async hook.

here is a risk that another is missing or new in the future would need "manual" fix like this

With this fix, we cover all options currently available to provide the configuration file, and yes, if we add a new one in the future, we must add it on the sync hook and in this method.

@VladaZakharova can you please explain what was the motivation to convert the config file to a dictionary before creating the trigger?

Copy link
Contributor

@VladaZakharova VladaZakharova Feb 14, 2023

Choose a reason for hiding this comment

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

Hi Team!
This was implemented to that config file was converted to dict to be passed to trigger and then hook to establish connection.

Copy link
Contributor

Choose a reason for hiding this comment

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

what do you mean by lighten the credential management ?

the hook is not re instantiate at every run of the trigger ?

Copy link
Contributor

Choose a reason for hiding this comment

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

We needed a way to pass config file to the trigger to create a client for kubernetes, but using file system to communicate with trigger was not a good solution. So then we added a possibility to pass all config file parameters as a dict.

Copy link
Member Author

Choose a reason for hiding this comment

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

To respect the pattern mentioned by @raphaelauv, I will try loading the config file in the async hook, this should work where the triggerer is initiated once.

Copy link
Contributor

Choose a reason for hiding this comment

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

Please mind that all FS operations are blocking side effects. It's violating asyncio contract and can cause additional error logs informing about blocking code.

@potiuk potiuk requested a review from dstandish February 20, 2023 09:32
@potiuk
Copy link
Member

potiuk commented Feb 20, 2023

@hussein-awala I guess you will be still changing the config access pattern on that one ? Do I understand correctly?

@hussein-awala
Copy link
Member Author

I guess you will be still changing the config access pattern on that one ? Do I understand correctly?

Yes, I'm testing loading the config file in the triggerer instead of loading it in the worker and pass it as a dict.

I convert the PR to draft until I finish testing

@hussein-awala hussein-awala marked this pull request as draft February 20, 2023 09:56
@VladaZakharova
Copy link
Contributor

VladaZakharova commented Feb 20, 2023

Hi!
May i ask in which format you will pass the config file to trigger? So it will be just a file passed as a parameter to trigger? Or how?

@hussein-awala
Copy link
Member Author

Hi! May i ask in which format you will pass the config file to trigger? So it will be just a file passed as a parameter to trigger? Or how?

@VladaZakharova - Yes, I pass the file path and let the triggerer loads it. Can you check my last commit?

BTW, I am not sure if loading the config file from the env var KUBECONFIG is a good idea or not, because it's difficult to decide when we need to load it and when we don't.

@raphaelauv
Copy link
Contributor

Loading the config file from the env KUBECONFIG is deprecated in latest provider version

@hussein-awala hussein-awala marked this pull request as ready for review February 22, 2023 00:55
Copy link
Contributor

@raphaelauv raphaelauv left a comment

Choose a reason for hiding this comment

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

LGTM

@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale Stale PRs per the .github/workflows/stale.yml policy file label Apr 11, 2023
@raphaelauv
Copy link
Contributor

@hussein-awala the PR have conflicts , could you rebase on main , thank you 👍

@github-actions github-actions bot removed the stale Stale PRs per the .github/workflows/stale.yml policy file label Apr 14, 2023
@hussein-awala hussein-awala force-pushed the fix/deferrable_k8s_pod_op branch 4 times, most recently from 839b3c1 to 59d76b8 Compare April 14, 2023 23:40
@hussein-awala hussein-awala force-pushed the fix/deferrable_k8s_pod_op branch from 59d76b8 to 24885c6 Compare April 15, 2023 00:28
Comment on lines 566 to 573
def convert_config_file_to_dict(self):
"""Converts passed config_file to dict format."""
config_file = self.config_file if self.config_file else os.environ.get(KUBE_CONFIG_ENV_VAR)
if config_file:
with open(config_file) as f:
self._config_dict = yaml.safe_load(f)
else:
self._config_dict = None
Copy link
Contributor

Choose a reason for hiding this comment

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

is removing this function considered a breaking change?

Copy link
Member Author

Choose a reason for hiding this comment

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

In my opinion, this method is used as a private method since it only updates some attributes in the class instances without returning any value. However, it's possible that someone could extend the operator class and use it. Should we deprecate it and remove it in the next major release, or should we add a breaking change note?

Copy link
Contributor

Choose a reason for hiding this comment

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

So lets deprecate first. Just to be on the safe side.

@hussein-awala hussein-awala force-pushed the fix/deferrable_k8s_pod_op branch from 1a87f6e to 5bc37f2 Compare April 18, 2023 00:07
@potiuk
Copy link
Member

potiuk commented Apr 22, 2023

LGTM. @eladkal ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:providers provider:cncf-kubernetes Kubernetes provider related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

KPO - deferrable - Invalid kube-config file. Expected key contexts in kube-config
6 participants