Allowing to promote to empty Stage

[aguschin]

If you promoted artifact version once, there is no way to get back to empty stage:

$ gto promote model prod
Created `model#prod-1` git tag
# now model in prod

Technically it's possible to allow to promote to special empty Stage:

$ gto promote model --empty-stage
Created `model#-2` git tag

I'm not sure about implemented this. User can have his own special stage called "none" or whatever. A con, to my mind is that having git tags like model#-2 seem a bit awkward. CLI commands now will look like this:

$ gto promote model --empty-stage
$ gto which model --empty-stage

I think we need this --empty-stage because otherwise you can misinterpret what happens, e.g.

$ gto promote model  # I may just forgot I need to put STAGE arg - I do this myself regularly
$ gto which model  # I may want to see all stages here: like "stage1 -> v1; stage2 -> v2; ..."

Pros, on the other hand:

• I can imagine some users would want to promote version back to this "empty" stage

[omesser]

@aguschin - do we have an initial default close set of stages (e.g. [development, integ-ready, prod-ready] or similar like in this drawing)?
If so - why not equate an empty stage (=no stage tags) with the first stage.
It makes sense if we're saying that stages=kanban-buckets. There are never "floating" tickets. you display unpromoted-model as in the first stage when querying, and so the is no "promoting to empty stage", just to another stage
wdyt?

[aguschin]

We don't have default set of Stages hardcoded. So by default any Stages are possible. Do you think we should provide some defaults?

If so - why not equate an empty stage (=no stage tags) with the first stage.

Makes sense, but wouldn't it create disrepancy? E.g. two artifacts are in first stage, but for one we have git tag art1#first-stage, for another don't). Also this is one more convention we're creating.

Just example from GH boards. When you add task to board, it doesn't have any Status assigned.

[aguschin]

@omesser suggest having a configuration: default_stage="none"

Also, a question to @dberenbaum @mnrozhkov. When you first start using GTO in empty repo and register the 1st model version (didn;t promote anything yet) - do you expect to see some pre-defined list of STages like in MLflow MR (or in GH board above)? Or it's fine to have a single column with default Stage? Or even no columns for Stages at all?

[dberenbaum]

Having stages shown in some way seems useful so that users are aware of them. Other than that, I don't have a strong opinion. Custom stages seem useful to me but are probably an advanced use case that don't necessarily need to be highlighted.

[omesser]

Writing this down from our discussion today:

"Makes sense, but wouldn't it create disrepancy? E.g. two artifacts are in first stage, but for one we have git tag art1#first-stage, for another don't). Also this is one more convention we're creating."

To be able to reverse a promotion operation (basic need) from "empty" to any other stage - there needs to be an ability to express all stages in tag names.
There will be some stage, to which gto would associate artifacts without promotion tags. but the promotion tag will also exist sometimes, if artifacts were promoted away-and-back. with the tag system I don't think there's a way to avoid that.
Whether this stage is represented by an empty string or not is a matter of tag readability/aesthetics and IMO empty string for stage name doesn't look nice or clear.

About default set of stages - pure product decision. I feel like seeing MR for the first time, not seeing any stages, makes it unclear the mechanism is there, and what promotion is. then on first promotion having to type free-text without a context - makes this obscure. Having the user see a pre-made stage ladder like ["development", "integration", "production"] will help to ground them towards the "kanban" mindset. Of course, it needs to be configurable, if we don't want it to be too "opinionated" and let the user create new stages when promoting and re-order stages (must if they create stages!)

[dberenbaum]

I am a proponent of custom stages because I think ML deployments can become quite complex progressive delivery use cases, but I'm not sure we need to do much about it now besides keep it in mind for the future. I agree that focusing on default stages that make the basic benefits obvious seems more helpful for initial release.

[aguschin]

Considering your feedback about pre-defined stages, I see two options to add them:

1. adding $ gto init command that should create gto.yaml config file with a set of pre-defined stages.
2. have them as a default in GTO internals. So if you don't have gto.yaml at all, you'll get those 2 or 3 stages.

The difference is what happens by default. In the 1st case, if you skip $ gto init, you don't have any pre-defined stages, and you can create any. Let's say you register a first version of your model, run $ gto show, and see no stages.

But, with the 2nd option I can't see how one allow using any names for envs. Something like allowedStages: any? compare that to allowedStages: ["dev", "prod"]. We may need a separate option like allowAnyStage: true.

[aguschin]

@omesser @dberenbaum WDYT?
I'm leaning towards the first one and implementing pre-requisites for it as part of #143

[aguschin]

1. adding $ gto init command that should create gto.yaml config file with a set of pre-defined stages.

Created an issue for this #229

Closing this issue since we changed Stages mechanics and this discussion is not relevant any more