Wildcards don't work for namespaces

[kaxil]

What steps did you take and what happened:
[A clear and concise description of what the bug is, and what commands you ran.)
Tried to create a backup for all namespaces that matches *-helm regex

velero backup create wp-airflow-helm --include-namespaces "*-helm"

What did you expect to happen:
Backup created for just that specific namespaces that matched regex

The output of the following commands will help us better understand what's going on:
(Pasting long output into a GitHub gist or other pastebin is fine.)

• kubectl logs deployment/velero -n velero
• velero backup describe <backupname> or kubectl get backup/<backupname> -n velero -o yaml:

> velero backup describe wp-airflow-helm2
Name:         wp-airflow-helm2
Namespace:    velero
Labels:       velero.io/storage-location=default
Annotations:  <none>

Phase:  PartiallyFailed (run `velero backup logs wp-airflow-helm2` for more information)

Errors:    1
Warnings:  0

Namespaces:
  Included:  *-helm
  Excluded:  <none>

Resources:
  Included:        *
  Excluded:        <none>
  Cluster-scoped:  auto

Label selector:  <none>

Storage Location:  default

Snapshot PVs:  auto

TTL:  720h0m0s

Hooks:  <none>

Backup Format Version:  1

Started:    2019-09-12 20:10:25 +0100 BST
Completed:  2019-09-12 20:10:26 +0100 BST

Expiration:  2019-10-12 20:10:25 +0100 BST

Persistent Volumes: <none included>

• velero backup logs <backupname>:

time="2019-09-12T19:10:26Z" level=error msg="Error getting namespace" backup=velero/wp-airflow-helm2 error="namespaces \"*-helm\" not found" error.file="/go/src/github.com/heptio/velero/pkg/backup/resource_backupper.go:186" error.function="github.com/heptio/velero/pkg/backup.(*defaultResourceBackupper).backupResource" group=v1 logSource="pkg/backup/resource_backupper.go:186" namespace="*-helm" resource=namespaces

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Velero version (use velero version): v1.1.0
• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.6", GitCommit:"96fac5cd13a5dc064f7d9f4f23030a6aeface6cc", GitTreeState:"clean", BuildDate:"2019-08-19T11:13:49Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.7-gke.8", GitCommit:"7d3d6f113e933ed1b44b78dff4baf649258415e5", GitTreeState:"clean", BuildDate:"2019-06-19T16:37:16Z", GoVersion:"go1.11.5b4", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes installer & version:
• Cloud provider or hardware configuration: GKE
• OS (e.g. from /etc/os-release): MacOS

[skriss]

Around https://github.com/heptio/velero/blob/master/pkg/backup/resource_backupper.go#L164, we're assuming that the namespace includes/excludes are "resolved" namespaces, which obviously doesn't hold with wildcards. We'd need to add some logic here to first get a full list of namespaces from the cluster, then check each one to see if it should be included, and then proceed with backing up those namespaces.

[codegold79]

Here is a note from @sseago:

We use includes/excludes to get a list of namespaces. Excludes with wildcards work because the ShouldInclude test returns false for namespaces that match that wild card. However, the list we start with is the includes list. There is no expansion of wild cards, so it looks like Velero is looking for the literal namespace "kube-*". backup.getNamespacesToList will need to be modified to get a namespace list for the cluster and expand wild cards from this. See the following lines:
https://github.com/vmware-tanzu/velero/blob/main/pkg/backup/item_collector.go#L453-L457
Restore will probably need a similar change.

Source: #4250 (review)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aslafy-z]

Un-stale please.

[izorster]

Yes, please, unstale/fix

[radnov]

Are there any plans for fixing this?

[ChadRehmKineticData]

Does anyone know if this issue has been resolved or are there plans to fix?

[marcusnh]

Also experiencing the same error. is there a fix?

[davidblum]

Just ran into this. Any update on the potential of this work being completed?

[sseago]

@davidblum Current status is that it's not being worked on. Velero 1.13 scope is largely defined at this point, but if there is enough interest, it could possibly be considered for Velero 1.14.

[ctrought]

+1 for this, in addition it would be great to have a namespaceSelector to select namespaces using label selectors.

[Missxiaoguo]

I am interested in this feature too! It would be very useful in the scale case.

Since #4250 has allowed specifying wildcards in the included namespaces, it's kind of werid that it's permitted now but nothing gets backup except for namespaces themselves.

[reasonerjt]

I had the impression that velero handles namespace quite differently comparing to regular resources, so the solution may not be as straightforward as we thought.

@blackpiglet
Please investigate and we can decide if we wanna put it in v1.15 later.

[blackpiglet]

It's not easy to implement this request.
First, we should consider the format, for example, do we want to support only one regex like "include-namespace-" for the --include-namespaces and --exclude-namespaces parameters, or multiple regex are supported like "include-namespace-1-,include-namespace-2-*".

Second, if we allow mixing the regex and regular namespace in --include-namespaces and --exclude-namespaces parameters, we need to add some additional logic to tell whether it's a regex or a regular namespace because Velero has logic to make the regular namespaces passed-in exists in the cluster before doing the backup.

Third, if we support regex in both --include-namespaces and --exclude-namespaces, it would be hard to detect whether there is a conflict between them.

I'm not against implementing it, but it needs more effort than it looks. We should ensure there is no break change and it doesn't impact the following resource collecting.

[reasonerjt]

Let me keep it in ice-box