search

nephio-project / nephio

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

Applying configuration changes to instance and instance sets #7

Open gvbalaji opened 1 year ago

gvbalaji commented 1 year ago

We could apply configuration changes such as capacity, cpu, memory labels etc at the following granularities

While supporting both these scenarios we will run into a few ambiguous situations. For example consider an Instance Set (InstanceSet-X) of UPFs that contains three UPF instances: UPF-A, UPF-B and UPF-C On day 1 a memory change was applied to InstanceSet-X to change the memory for all instances to 4 GB On Day 2 a memory change was applied to only the instance UPF-B to have 8 GB of memory. On day 3 a memory change was again applied to InstanceSet-X to change the memory for all instances to 6 GB

Now after the day-3 change what should be the memory setting of UPF-B ? Should it be 8GB or 6 GB? Should we resolve this automatically using 3 way git merge by assuming the user intent? Should we explicitly ask the user about their intent while applying changes to Instance Sets?

Here is one possible way to resolve ambiguity.

We could let the user apply the configuration changes to either an "Instance" or an "Instance Set". When the user specifies the Instance Set we can let the user specify an exclude filter specifying the list of instances for which the configuration should not be applied. We will always apply changes for the resulting instances ( the entire instance set when exclude filter is empty). This way it is always deterministic and no surprises to the user as we are not assuming their intent since they are expressing it explicitly.

johnbelamaric commented 1 year ago

In R1 terminology, this is getting at how to prioritize changes when using a PackageVariant or PackageVariantSet. There are three places that changes can be made:

a. In the upstream package b. In the PackageVariant(Set) resource via a mutation using the function pipeline or injection c. In the downstream package revision after fan out

The question comes in this flow:

  1. user deploy a package via a PackageVariant(Set)
  2. user modifies the resulting PackageRevision and publishes it
  3. user modifies the upstream package, and then changes the PV(S) to refer to the new revision of that upstream
  4. PV generates a new PackageRevision based on the updated upstream package, but the changes in the upstream package my conflict with the change made in 2)

Which should we honor, in this case? Is there a way the user should be able to control that? If so, it probably would be some policy field in PV. But if it's that, then since PVS creates PVs, how can we be selective about the ones it applies to? Should we allow that?