operator-framework/operator-sdk

Documentation uses deprecated examples of defining namespace scope in manager options

NymanRobin opened this issue · 3 comments

While reading the operator-scope section, I noticed that the documentation contains a mix of current and deprecated method for defining the namespace to watch in the manager options.

When introducing the manager watch options it correctly defines it according to the current standard

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
    Scheme:             scheme,
    MetricsBindAddress: metricsAddr,
    Port:               9443,
    LeaderElection:     enableLeaderElection,
    LeaderElectionID:   "f1c5ece8.example.com",
    Cache: cache.Options{
      DefaultNamespaces: map[string]cache.Config{"operator-namespace": cache.Config{}},
    },
})

However, further down in the document when giving a code examples it gives the old and deprecated syntax of giving the Namespace option directly.

watchNamespace, err := getWatchNamespace()
if err != nil {
    setupLog.Error(err, "unable to get WatchNamespace, " +
       "the manager will watch and manage resources in all namespaces")
}

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
    Scheme:             scheme,
    MetricsBindAddress: metricsAddr,
    Port:               9443,
    LeaderElection:     enableLeaderElection,
    LeaderElectionID:   "f1c5ece8.example.com",
    Namespace:          watchNamespace, // namespaced-scope when the value is not an empty string
})

Noticed that the tutorial also uses examples with the deprecated Namespace variable when introducing the Manager.

I think it would make sense to unify the documentation and only use the new style of giving the Namespace

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@acornett21 Hi, I was just browsing issues with help wanted and saw this one. From looking at the linked PR, it seems like this issue has been resolved. If that's the case, perhaps I'm wondering if this issue could be closed? Thanks!