Nephio is a Kubernetes-based automation platform for deploying and managing highly distributed, interconnected workloads such as 5G Network Functions, and the underlying infrastructure on which those workloads depend.
Apache License 2.0
104
stars
53
forks
source link
[Question] Can we standardize some lifecycle terminology? #708
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.
Original issue comments:
Comment user: https://github.com/yuwenma
Comment created at: 2022-07-30T02:45:38Z
Comment last updated at: 2022-07-30T02:45:38Z
Comment body: +100. This can also help users understand what we are talking about and be more involved.
Comment user: https://github.com/johnbelamaric
Comment created at: 2022-08-07T18:40:39Z
Comment last updated at: 2022-08-07T18:40:39Z
Comment body: 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.
Comment user: https://github.com/johnbelamaric
Comment created at: 2022-08-07T18:41:58Z
Comment last updated at: 2022-08-07T18:41:58Z
Comment body: cc @droot @mortent @justinsb @bgrant0607
Comment user: https://github.com/bgrant0607
Comment created at: 2022-08-09T00:20:34Z
Comment last updated at: 2022-08-09T00:20:34Z
Comment body: 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?
Comment user: https://github.com/johnbelamaric
Comment created at: 2022-08-18T21:55:38Z
Comment last updated at: 2022-08-18T21:55:57Z
Comment body: > "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.
Comment user: https://github.com/apelisse
Comment created at: 2022-08-18T23:56:08Z
Comment last updated at: 2022-08-18T23:56:08Z
Comment body: 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
Comment user: https://github.com/selfmanagingresource
Comment created at: 2022-08-24T04:44:48Z
Comment last updated at: 2022-08-24T04:44:48Z
Comment body: 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?
Comment user: https://github.com/apelisse
Comment created at: 2022-08-24T16:39:29Z
Comment last updated at: 2022-08-24T16:39:56Z
Comment body: OK, That comes from the fact that I'm not sure how the rendering is supposed to happen in kpt :-)
Original issue URL: https://github.com/kptdev/kpt/issues/3422 Original issue user: https://github.com/johnbelamaric Original issue created at: 2022-07-29T18:45:44Z Original issue last updated at: 2022-11-16T02:43:20Z Original issue body: 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):
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.
Original issue comments: Comment user: https://github.com/yuwenma Comment created at: 2022-07-30T02:45:38Z Comment last updated at: 2022-07-30T02:45:38Z Comment body: +100. This can also help users understand what we are talking about and be more involved.
Comment user: https://github.com/johnbelamaric Comment created at: 2022-08-07T18:40:39Z Comment last updated at: 2022-08-07T18:40:39Z Comment body: 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.
Comment user: https://github.com/johnbelamaric Comment created at: 2022-08-07T18:41:58Z Comment last updated at: 2022-08-07T18:41:58Z Comment body: cc @droot @mortent @justinsb @bgrant0607
Comment user: https://github.com/bgrant0607 Comment created at: 2022-08-09T00:20:34Z Comment last updated at: 2022-08-09T00:20:34Z Comment body: 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?
Comment user: https://github.com/johnbelamaric Comment created at: 2022-08-18T21:55:38Z Comment last updated at: 2022-08-18T21:55:57Z Comment body: > "Adaptation" sounds good to me
+1 ok
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.
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.
Comment user: https://github.com/apelisse Comment created at: 2022-08-18T23:56:08Z Comment last updated at: 2022-08-18T23:56:08Z Comment body: 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):
Comment user: https://github.com/selfmanagingresource Comment created at: 2022-08-24T04:44:48Z Comment last updated at: 2022-08-24T04:44:48Z Comment body: 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?
Comment user: https://github.com/apelisse Comment created at: 2022-08-24T16:39:29Z Comment last updated at: 2022-08-24T16:39:56Z Comment body: OK, That comes from the fact that I'm not sure how the rendering is supposed to happen in kpt :-)
Does that help: