Closed horis233 closed 3 years ago
The package name generated in the bundle.Dockerfile and bundle/metadata/annotations.yaml are the same as the projectName in the PROJECT file.
This is by design since your PROJECT config should contain the name of your operator/package. Is the name of your package different from the name of your operator project?
We are going to be adding (back) an --operator-name
flag (or similarly named) to generate
subcommands, but the primary use case is for generating bundles outside of an operator project (i.e. when PROJECT
is not available). Your PROJECT
file really should contain projectName: <project and package name>
to avoid ambiguity in other parts of the project.
/language go /triage support /assign
@estroz In absence of such a flag, it becomes extremely difficult to create multiple bundles with different package names. This will be a common use-case for operators which have different package names for (upstream) community & Red Hat certified.
Also, if there was an option to just change the package name and not the CSV names, it would be helpful. Right now, the generated CSV file in the bundle default to the PROJECT name. This is required as most of the certified operators just change the package name (and not the CSV name) to differentiate from any existing community operators.
In that case, this is a duplicate of #3998 and is being worked on.
On further consideration, this isn't an exact duplicate of #3998, since that issue is asking for a --package-name
flag so generate bundle
can be run outside of a project. That flag would allow you to do part of what you want, since changing the package name would also change the CSV name (which is derived from project name).
@kumarrprashant2005 can you explain why changing your CSV name to align with package name is not desirable?
@estroz Say if I have a certified operator already out there which has the CSV name which is different from package name (which I presume would be common as the recommendation was to just add the certified suffix to the package name), then this creates problems for upgrade. Once I migrate to the newer SDK, the CSV name would be different if I set the PROJECT to include the certified suffix. This new CSV can't "replace" my older CSV because they have different names now. So, an ability to set these the package name via an option with the generate command would be extremely helpful.
CSV name is meant to be unique, and whether the package name is used in the CSV name doesn't really matter. For example:
I have one CSV for package foo
:
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
name: foo.v1.0.0
I create a new CSV for package foo
with a higher version, then replace the old one:
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
name: foo.v1.0.1
spec:
replaces: foo.v1.0.0
I also create a new CSV for package bar
with a higher version and CSV name ~ package name, then replace the old foo
one:
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
name: bar.v1.0.1
spec:
replaces: foo.v1.0.0
As long as foo.v1.0.1
and bar.v1.0.1
are supplied to different indexes alongside foo.v1.0.0
, the index will build fine. Does that clarify the situation, or are my assumptions about what you're asking off the mark? @kevinrizza @dinhxuanvu can you weigh in here?
What Eric said is correct. The CSV name must be unique and using packagename.version
schema is a popular choice to name the CSV that we've seen so far.
@estroz @dinhxuanvu Thanks a lot for your clarification. I was not aware that you could replace a foo.v1.0.0 with a bar.v1.1.0 This eases some of the trouble while creating CSVs.
The problem with the separate bundles with separate package names still stand and an option to create one would help anyone with these problems.
I could technically create a separate bundle (with a different package name) with a combination of input-dir, output-dir flags & updating the package name by hand (in the Dockerfile & annotations). From this point onwards I can just use the --manifests instead of --overwrite option to just update the manifests (and not the bundle.Dockerfile & annotations). But this process is tedious and error prone and is difficult to maintain. If the operator-sdk just provided an option out of the box, then it would greatly help us.
I'm pretty sure this is taken care of by #4074. Feel free to re-open if not.
Bug Report
I can't set package name when using
operator-sdk generate bundle
to generate bundle files.What did you do?
When I use the
make bundle-manifests
command generated by the operator-sdk, I found I can't set the package name for my operator.The package name generated in the
bundle.Dockerfile
andbundle/metadata/annotations.yaml
are the same as theprojectName
in thePROJECT
file.What did you expect to see?
I expect
operator-sdk generate bundle
can provide a tag for setting the package name as theopm
commandopm alpha bundle generate
What did you see instead? Under which circumstances?
I have to manually update the package name after the bundle files are created.
Environment
Operator type:
go Operator
Kubernetes cluster type:
Openshift
$ operator-sdk version
operator-sdk version: "v1.0.1", commit: "4169b318b578156ed56530f373d328276d040a1b", kubernetes version: "v1.18.2", go version: "go1.15.2 darwin/amd64", GOOS: "darwin", GOARCH: "amd64"
$ go version
(if language is Go)go version go1.15.2 darwin/amd64
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-13T16:12:48Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.3+47c0e71", GitCommit:"47c0e71", GitTreeState:"clean", BuildDate:"2020-09-17T23:10:07Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Possible Solution
Additional context