[Question] Can we standardize some lifecycle terminology?

[johnbelamaric]

We have some various workflows defined here: https://kpt.dev/book/02-concepts/02-workflows

During our discussions, we often talk about "render time" and "apply time" and "run time" as different points in the lifecycle during which config mutations may happen. Can we standardize on some terminology for these and document it in a workflow? Perhaps we already have and I have missed that guide? I think that would help us be sure we all are speaking about the same thing during our discussions. For a start, some thoughts (some of these need more work):

• Authoring Time - The entire phase of initial package creation to its first publication, as well as continuing modifications and publication of new versions.
• Customization Time (Adaptation? Tailoring? Brian used a word today that I can't recall but seemed pretty good...) - A hybrid producer / consumer time when the user (platform team, typically) is adapting an off-the-shelf package to their particular operational use case and injecting things like organizational policies. This may be considered another type of authoring.
• Input Time - Gathering, preparing, and parsing the inputs to the function pipeline.
• Render Time - During the execution of the function rendering pipeline.
• Apply Time - After render, just before actually writing to the API server.
• Post Apply Time - After the write to the API server, before storage (e.g., validating and mutating webhooks).
• Run Time - After storage by the API server.

We may want to differentiate iterative human / controller interactions with config - like the authoring phase - from the simpler pipeline -> apply phases. Nephio automation controllers, for example, could live in the authoring/customization/input times. Maybe there's another intermediate stage I am missing.

Here's a diagram that attempts to capture a "typical" package lifecycle when using Porch. Please correct / add / comment via this drawing link.

[yuwenma]

+100. This can also help users understand what we are talking about and be more involved.

[johnbelamaric]

I added a drawing above. We need to identify what options are available at each stage to modify config, and identify why any particular mutation should live in any particular stage of this process.

[johnbelamaric]

cc @droot @mortent @justinsb @bgrant0607

[bgrant0607]

Good start.

We might need to break down Authoring Time into Initial Authoring and specific kinds of subsequent edits. Note that functions can run on packages imperatively at this point.

"Customization time" is too general. Anything that changes a value compared to an upstream or base is customization as we've been using that term since 2017 or so.

I don't remember what term I used in the discussion you referenced, but "Adaptation" sounds good to me for taking an off-the-shelf blueprint and making it ready for consumption within a more specific context.

We might want more specific terms for the case that a platform team takes a component configuration, analogous to a public helm chart, and adapts it for their organization, and the case that an application team takes a generic application blueprint, analogous to OneChart, and adapts it for their application. Actually a platform team might first adapt a public OneChart-like blueprint, which application teams would then adapt for their specific applications. The results of those adaptations would be a multi-environment, potentially multi-cluster blueprint that would be further specialized into deployments for the specific deployment targets.

Is "Post Apply Time" just Admission Time?

[johnbelamaric]

"Adaptation" sounds good to me

+1 ok

We might want more specific terms for the case that a platform team takes a component configuration

Possibly. The chains can be arbitrarily long though, so I am not sure. I guess "adaptation" can be the general term for transforming a catalog (abstract) blueprint into another catalog blueprint. Then we can add adjectives: org adaptation, app team adaptation, etc. for different links in the chain.

Is "Post Apply Time" just Admission Time?

Yeah, I can't think of any other change post-apply. The closest I can think of would be something like Cork, but that's really runtime.

[apelisse]

I was going to comment that "post apply time" should be called "admission time", I see I'm not alone.

Not being super familiar with how pipeline rendering is supposed to work (I'm not entirely sure this is completely settled yet to be honest?), the "render time" description could be more descriptive.

These could possibly be organized into categories (associated by actions taken):

• Authoring time in general, includes:
  • Authoring Time
  • Customization time
• Pipeline processing, includes:
  • Input Time
  • Render Time
• Apply time, includes:
  • Apply Time
  • Admission time (sorry, renaming this ;-)
• Runtime

[selfmanagingresource]

One thing to note with the above @apelisse is that pipeline processing is more or less part of the atuhoring process. Think Turbo Tax. You are either editing forms/resource views - this is what you are calling authoring time - every time you hit next - TurboTax is doing something under the hood to re-render the source of truth underneath and update forms you will be editing next. However that rendering is happening as part of the e2e authoring but before the apply time. Maybe we should just called it the rendering phase and make it part of rendering?

[apelisse]

OK, That comes from the fact that I'm not sure how the rendering is supposed to happen in kpt :-)

Does that help:

• Authoring time in general, includes:
  • Authoring Time
  • Customization time
  • Pipeline processing, includes:
  • Input Time
  • Render Time
• Apply time, includes:
  • Apply Time
  • Admission time (sorry, renaming this ;-)
• Runtime