namespace attribute question

[argoproj-labs]

namespace attribute question

[bobh66]

I will also mention that Hera adds the UUID short suffix to avoid name collisions when the core name field is the same for multiple workflows.

Yes - this was another thing I was going to ask you about. I understand the reasoning but it does introduce other issues when the object changes the value of an input parameter. From one perspective I want the name of the object to match what I gave it, so I can find it later. Also in the future it might be nice to be able to "load" an existing Workflow/CronWorkflow and perform operations on it (for example suspend/resume an existing CronWorkflow) and that can't be done when the object manipulates the name field when it gets created. Definitely a topic for further discussion :-)

This made me think of this example; any chance you've seen it?

Yes - I'm actually doing quite a bit with that example already, like restoring the name back to what I want it to be :-)

If it's OK with you I'll push a PR with what I'm thinking and we can review it. It's 3rd in line behind the label support changes and the CronWorkflow name change.

Thanks!

[flaviuvadan]

First - I want to make sure I say THANK YOU for this project. It is exactly what I needed to accomplish what I'm working on at the moment, and hopefully I can help wherever needed.

❤️ I cannot express how much this statement means to me. Thank you @bobh66! That's very kind of you.

I'm curious why the Workflow and CronWorkflow objects take a name attribute as part of object creation but the namespace is passed in as a parameter to the create()/submit() methods?

The reasoning behind passing in a name is to provide the opportunity for custom workflow names. At @dynotx, for instance, numerous workflows are submitted with contextual names (internal company vocabulary) so it's easy to find the workflow in the UI. I will also mention that Hera adds the UUID short suffix to avoid name collisions when the core name field is the same for multiple workflows.

The intent of having namespace on the service is to maintain some separation between the concepts associated with a "workflow" (Argo) and the underlying engine of Argo (Kubernetes). The workflow definitions are the ones that define the job to execute (the what) and the service influences the behavior of the underling execution engine (the where and how).

Is the expectation that the same workflow/cronworkflow object instance could be created in different namespaces by the same code?

I would not say it's much of an expectation, to be honest. Hera exposes the namespace on the service since it cannot assume everyone runs workflows in the default namespace, for instance. I also just realized that I am not fully confident that this makes sense actually... can the same workflow be submitted to different namespaces if it's instantiated with the same name? Does the workflow controller support that? I do not know 🙂

Would it make sense to pass the namespace in to the object creation and store it in metadata along with the name, and then have the submit()/create() methods accept an optional namespace that defaults to None, and if no namespace is passed in then it defaults to the object's namespace attribute?

I think it would be nice but I have a concern. The workflow objects do not have full feature parity with the Argo Workflow representation yet - Hera goes by what the community wants and needs, and it started off with no assumptions as to whether things like, say, security contexts are needed, environment variables, etc. Hera was designed mostly for scientific workflows and the scientific community at first, which needs a very simple set of control knobs. As Hera advances towards feature parity, it just needs to be careful with the balance of what it exposes on a workflow, and what it exposes on a service object. Personally, I find it more intuitive to maintain K8S related things on the service, such as the namespace, and workflow related characteristics on the workflow, such as the name.

I'm just thinking that it might be "cleaner" to construct the object all at once and not have to worry about passing in a namespace when it's time to create/submit.

This made me think of this example; any chance you've seen it? I added an example of how to construct internal wrappers for tasks and services with this specific case in mind 🙂 some users might want to add some custom behavior/fields on tasks/workflows/services, and the example showcases just that! Can add the auth logic, some business context, GPU specs, etc!

Let me know what you think about the above!

[flaviuvadan]

If it's OK with you I'll push a PR with what I'm thinking and we can review it. It's 3rd in line behind the label support changes and the CronWorkflow name change.

Of course! Let's have the discussion on the PR. And thank you!

[flaviuvadan]

Yes - this was another thing I was going to ask you about. I understand the reasoning but it does introduce other issues when the object changes the value of an input parameter. From one perspective I want the name of the object to match what I gave it, so I can find it later. Also in the future it might be nice to be able to "load" an existing Workflow/CronWorkflow and perform operations on it (for example suspend/resume an existing CronWorkflow) and that can't be done when the object manipulates the name field when it gets created. Definitely a topic for further discussion :-)

This is certainly something that I am open to changing. If the community finds it more useful to be able to create names as desired, and append non-conflicting suffixes themselves, then of course we can make the change! To be perfectly honest, this suffix came more from the internal use of Hera at Dyno rather than it being asked by the community. So, again, if this is the desired functionality, we can definitely change it in a MAJOR version update 🙂

[flaviuvadan]

Addressed by #71