CR design best practice: one vs. many objects

General Discussions
1

Looking for general advice/opinion on using a single CR object with lists of child “objects” vs. using multiple CR objects, one for the parent and one for each child. Concrete example below is a sketch of a log forwarder that has multiple outputs (places logs can be sent to) and multiple pipelines that gather logs from some set of pods and forward them to some set of outputs.

# Approach 1: single-object
#
# Pro:
# - More compact, easier to set up once and forget about it.
#
# Con:
# - Adding an output or pipeline requires a strategic 'kubectl patch'
# - Removing and outputs/pipelines requires overwriting the list with 'kubectl patch'
#   This is unsafe - 2 users can't concurrently get the list then apply a modified list
#   without risk of over-writing each other.
---
kind: Forwarder
metadata: { name: my-log-forwarder }
spec:
  global: global-config...
  outputs:
    - name: users
      type: syslog
      url: syslog-udp://sky.net
    - name: developers
      type: fluent
      url: http://fixme.org
  pipelines:
    - select: { partition: bigshots }
      outputRefs: [important]
    - select: { environment: dev }
      outputRefs: [debuggers]
...

# Approach 2: multi-object
#
# Pro:
# -Can safely add/remove Outputs and Pipelines with kubectl apply/delete
#
# Con:
# - More verbose, requires multiple files or a multi-doc file.
# - (Is there significant extra overhead to the multi-object approach? I don't know...)
---
---
kind: Forwarder
metadata: { name: my-log-forwarder }
spec:
  global: global-config...
---
kind: Output
metadata: { name: users }
spec:
  forwarder: my-log-forwarder
  type: syslog
  url: syslog-udp://sky.net
---
kind: Output
metadata: { name: developers }
spec:
  forwarder: my-log-forwarder
  type: fluent
  url: http://fixme.org
---
kind: Pipeline
    - select: { partition: bigshots }
      outputRefs: [important]
    - select: { environment: dev }
      outputRefs: [debuggers]