Umbrella issue for Ghost package

[yuwenma]

feature requests

• support recommend labels. the app name need to come from the package, need to find an approach to not using apply-replacement to assign from Kptfile meta name to function config SetLabels value.
• the ghost helm charts contain two secrets. One for ghost-app, referred by Deployment spec.template.spec.containers[].env[].valueFrom.secretKeyRef, and spec.template.metadata.annotations[].checksum/secrets. checksum/secrets is a helm feature for auto roll deployment. The other is for mariadb, referred by StatefulSet spec.template.spec.containers[].env[].valueFrom.secretKeyRef. Our ghost pkg does not have secret controller yet. This feature is discussed in Figure out how to handle secrets #3125
• ConfigMap is used to provide the Statefulset volume, holding an INI file.
• design a mechanism to auto generate function config from function name. This should much simplify the user experience to write a functionCofig from scratch.
• Better leverage the spec definition in function config struct.

friction issues

• set-labels should not transform local-config manifests.
  • version: v0.1.5
  • expected: skip KRM resources with config.kubernetes.io/local-config: "true" label .
  • Another solution: add an option includeLocalConfig in SetLabels function config.
• set-namespace
  • set-namespace:v0.4.1` does not accept resources of same GVKNN (different file path). v0.3.4 works well.
  • latest set-namespace with origin gives too many warnings for raw manifests. This is annoying.
  • set-namespace misses fields like podAffinityTerm.namespaces[]. We need to iterate the core/v1 resources to make sure all namespaces are covered.

[yuwenma]

User experience compared to Helm:

• helm users are more easy to get started. They only edit values.yaml file (with enough comment, they can even only rely on the values.yaml to know the entire charts). While in kpt, configurations are on KRM resource level, especially since we recommend using configPath over configMap, users cannot merely read a Kptfile. And when editing a KRM resource, they may need to edit Kind, both field name and field value. It's harder to figure out which fields are the users' responsibilities to change.
• Enabling or disabling a group of resources in helm is easy (e.g. make the inline if condition to be false can skip a network policy, or disable metrics, disable ingress). How shall we let users disable a group of KRM resource (e.g. networkPolicy, ingress)