The "wait-for" idea is really nice, but I don't think it's a requirement for "one-off, scheduled and continuous jobs support".

Maybe we could start implementing everything else, and let users handle the order of deployments? They could even start two deployments in parallel (e.g. toolhunt-api and toolhunt-flower), if they want to do so.

Having a "deployment plan" is only needed to implement an endpoint that deploys all components of a tool (the all endpoint discussed in T362066). But I think that could be implemented in a second step, so that we can have some early adopters of the component API and see what are their needs and use cases.

Just my 2c :)

In T362075#9726251, @fnegri wrote:

The "wait-for" idea is really nice, but I don't think it's a requirement for "one-off, scheduled and continuous jobs support".

Maybe we could start implementing everything else, and let users handle the order of deployments? They could even start two deployments in parallel (e.g. toolhunt-api and toolhunt-flower), if they want to do so.

Having a "deployment plan" is only needed to implement an endpoint that deploys all components of a tool (the all endpoint discussed in T362066). But I think that could be implemented in a second step, so that we can have some early adopters of the component API and see what are their needs and use cases.

Just my 2c :)

I would have started with that too, but the thing is that the DAG resolution is already done, imo the complicated part of this task is the state extraction from k8s, so there's no extra work needed for the DAG resolution.

You would still need the pipeline-like feature for build+deploy of a single component, so we don't avoid the need for a pipeline either.

So though I agree that it's not a requirement, it's related enough and simple enough to be able to be done at the same time.

I have a thing against reuse-from. It is not immediately clear what it means by just looking at it. depends-on is a more descriptive name if I understand the supposed meaning of reuse-from correctly. In contrast reuse-from sounds like we are somehow reusing the configuration of a particular component in another. Obviously this is not already set in stone but it's important to point it out

In T362075#9806795, @Raymond_Ndibe wrote:

I have a thing against reuse-from. It is not immediately clear what it means by just looking at it. depends-on is a more descriptive name if I understand the supposed meaning of reuse-from correctly. In contrast reuse-from sounds like we are somehow reusing the configuration of a particular component in another. Obviously this is not already set in stone but it's important to point it out

An earlier version os this yaml used depends-on, but it confusingly meant two distinct things depending on context:

1. a build-time dependency on another component's image (i.e use of another compenent's image as opposed to building from source)
2. a run-time dependency on another component (e.g. don't run a db-dependent job before having run the db-migration)

To disambiguate this and make the terms more descriptive, depends-on was split into reuse-from to indicate case 1) and wait-for to indicate case 2). reuse-from mirrors the FROM directive in Dockerfile. I would not go back to depends-on because I think it's actually less descriptive, but maybe we can consider other alternatives such as use-image or image-from or inherit-image, if you think that would be more descriptive.

Maybe just use: <other-component>?

I like use-image, image-from or reuse-image. Basically, anything with the word image in it to clarify that the image is "reused", not the config.

I like use-image, image-from or reuse-image. Basically, anything with the word image in it to clarify that the image is "reused", not the config.

I suggest using build instead of image, as it's not really an image you are configuring, just the build (the fact that it builds a container image is dependent on the runtime, that might change eventually, for example mircoVMs or whatever 👾).

Hmm, we might not be the best folks to decide which term is more descriptive/unambiguous because we're too deep in the soup. 🙈 Could we somehow run a quick poll?

To me an image is a "thing" while a build is a "process", which feels more fuzzy/unclear in terms what goes into it.

Having tinkered a bit with microVMs, one of the more convenient ways to create one is by extracting the rootfs from a container image and combining it with a kernel... 😈

I like where this is going :)

In T362075#10619167, @So9q wrote:

I like where this is going :)

Thanks! :) that's very nice to hear!