IPv6 Address Wrapping Issue in CatalogSource Resource

[dhirajlakhane30]

Bug Report

There is an issue in the Operator-SDK regarding how IPv6 addresses are handled in the CatalogSource resource. Specifically, the address field in the CatalogSourceStatus struct is not properly wrapped in square brackets [] when dealing with IPv6 addresses. This leads to potential connection issues when the CatalogSource is deployed with an IPv6 address, as the address format is not compliant with the expected format <[IPv6 address]>:.

What did you do?

When i tried to run the bundle (which is pushed to quay.io) on my ipv6 k8s/ocp cluster, it is creating operator group, subscription,
catalogsource etc. but when I describe the catalog source there I can see the issue with ipv6 address.

same bundle when I tried to run on ipv4 cluster, it I running very smoothly.

when i explored the operator-sdk source code ( https://github.com/operator-framework/operator-sdk ) , here in the internal/olm/operator/registry/operator_installer.go file you can see the chunk of code to get the catalog source matching the existence subscription. at line 140
cs := &v1alpha1.CatalogSource{}
if err := o.cfg.Client.Get(ctx, catsrcKey, cs); err != nil {
return nil, fmt.Errorf("error getting catalog source matching the existing subscription: %w", err)
}

this v1alpha1.CatalogSource{} is imported as "github.com/operator-framework/api/pkg/operators/v1alpha1"
( https://github.com/operator-framework/api/tree/master/pkg/operators/v1alpha1 )
in the catalogsource_types.go file,
In the function:

func (s *RegistryServiceStatus) Address() string {
return fmt.Sprintf("%s.%s.svc:%s", s.ServiceName, s.ServiceNamespace, s.Port)
}

Currently, the Address() function formats the address string without taking into account the specific formatting required for IPv6 addresses (i.e., wrapping the IPv6 address in square brackets []). This can cause errors in systems that expect the correct IPv6 address format.

What did you expect to see?

When an IPv6 address is used, it must be wrapped in square brackets to distinguish it from the port number.

Current behavior: fd00:abcd::1:5000

Expected behavior: [fd00:abcd::1]:5000

Environment

Operator type:

/language go

Kubernetes cluster type:

$ operator-sdk version

operator-sdk version: "v1.33.0"

$ go version (if language is Go)

go version go1.21.0 linux/amd64

$ kubectl version

Client Version: v1.30.4
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.4

$ oc version

Client Version: 4.12.42
Kustomize Version: v4.5.7
Server Version: 4.16.10
Kubernetes Version: v1.29.7+4510e9c

Possible Solution

#Proposed Solution:
Modify the Address() function in catalogsource_types.go to detect if the service's address is an IPv6 address, and wrap it in square brackets accordingly. Here's a potential fix:

func (s *RegistryServiceStatus) Address() string {
if strings.Contains(s.ServiceName, ":") {
// It's an IPv6 address, wrap it in brackets
return fmt.Sprintf("[%s.%s.svc]:%s", s.ServiceName, s.ServiceNamespace, s.Port)
}
return fmt.Sprintf("%s.%s.svc:%s", s.ServiceName, s.ServiceNamespace, s.Port)
}

Additional context

I have added screenshots which shows description of catalogsource for both ipv4 and ipv6.

[openshift-bot]

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

[openshift-bot]

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

[KeenonLee]

Hi @dhirajlakhane30

Thanks for reporting this issue.

I understand that you are encountering a problem when using an IPv6 address in the ServiceName. Typically, in Kubernetes and OpenShift, ServiceName should be a DNS name, such as nginx.default.svc, rather than a raw IP address. This ensures proper service discovery and scalability.
I recommend using DNS names for ServiceName wherever possible, as this will help avoid issues related to specific IP address formatting.

Let me know if you need further clarification!

Best regards,

[dhirajlakhane30]

Hi @dhirajlakhane30

Thanks for reporting this issue.

I understand that you are encountering a problem when using an IPv6 address in the ServiceName. Typically, in Kubernetes and OpenShift, ServiceName should be a DNS name, such as nginx.default.svc, rather than a raw IP address. This ensures proper service discovery and scalability. I recommend using DNS names for ServiceName wherever possible, as this will help avoid issues related to specific IP address formatting.

Let me know if you need further clarification!

Best regards,

Hi @KeenonLee

it is not related that weather I'm using DNS name or giving raw ip address. Typically when you run some operator bundle , in catalogSource file, automatically it will pick ip address.

you can see this below given behaviour,
Current behavior: fd00:abcd::1:5000

Expected behavior: [fd00:abcd::1]:5000

and when you see the go file

catalogsource_types.go file,
In the function:

func (s *RegistryServiceStatus) Address() string {
return fmt.Sprintf("%s.%s.svc:%s", s.ServiceName, s.ServiceNamespace, s.Port)
}

location of catalogsource_types.go file ( github.com/operator-framework/api/pkg/operators/v1alpha1 )

[KeenonLee]

Hi @dhirajlakhane30
Thanks for reporting this issue.
I understand that you are encountering a problem when using an IPv6 address in the ServiceName. Typically, in Kubernetes and OpenShift, ServiceName should be a DNS name, such as nginx.default.svc, rather than a raw IP address. This ensures proper service discovery and scalability. I recommend using DNS names for ServiceName wherever possible, as this will help avoid issues related to specific IP address formatting.
Let me know if you need further clarification!
Best regards,

Hi @KeenonLee

it is not related that weather I'm using DNS name or giving raw ip address. Typically when you run some operator bundle , in catalogSource file, automatically it will pick ip address.

you can see this below given behaviour, Current behavior: fd00:abcd::1:5000

Expected behavior: [fd00:abcd::1]:5000

and when you see the go file

catalogsource_types.go file, In the function:

func (s *RegistryServiceStatus) Address() string { return fmt.Sprintf("%s.%s.svc:%s", s.ServiceName, s.ServiceNamespace, s.Port) }

location of catalogsource_types.go file ( github.com/operator-framework/api/pkg/operators/v1alpha1 )

Hi @dhirajlakhane30 In the standard URL format, when both the IPv6 address and port number are present, the IPv6 address must be enclosed in square brackets because the colon : in the IPv6 address would conflict with the port separator :. Therefore, without square brackets, it is not possible to directly represent both the IPv6 address and port number.

For example, it should be: [2001:db8::1]:8080,
and not 2001:db8::1:8080, as this format does not follow the standard URL format.

So please try

Spec:
  Address: [fd00:54d2:8ed1:1:b4be:5e61:9748:8b6]:50051

[dhirajlakhane30]

Hi @dhirajlakhane30
Thanks for reporting this issue.
I understand that you are encountering a problem when using an IPv6 address in the ServiceName. Typically, in Kubernetes and OpenShift, ServiceName should be a DNS name, such as nginx.default.svc, rather than a raw IP address. This ensures proper service discovery and scalability. I recommend using DNS names for ServiceName wherever possible, as this will help avoid issues related to specific IP address formatting.
Let me know if you need further clarification!
Best regards,

Hi @KeenonLee
it is not related that weather I'm using DNS name or giving raw ip address. Typically when you run some operator bundle , in catalogSource file, automatically it will pick ip address.
you can see this below given behaviour, Current behavior: fd00:abcd::1:5000
Expected behavior: [fd00:abcd::1]:5000
and when you see the go file
catalogsource_types.go file, In the function:
func (s *RegistryServiceStatus) Address() string { return fmt.Sprintf("%s.%s.svc:%s", s.ServiceName, s.ServiceNamespace, s.Port) }
location of catalogsource_types.go file ( github.com/operator-framework/api/pkg/operators/v1alpha1 )

Hi @dhirajlakhane30 In the standard URL format, when both the IPv6 address and port number are present, the IPv6 address must be enclosed in square brackets because the colon : in the IPv6 address would conflict with the port separator :. Therefore, without square brackets, it is not possible to directly represent both the IPv6 address and port number.

For example, it should be: [2001:db8::1]:8080, and not 2001:db8::1:8080, as this format does not follow the standard URL format.

Hi @KeenonLee Exactly!!! this is what I was trying to tell. when I install the operator bundle on single stack ipv6, the catalogSource file get generated with ipv6 mismatch and that's the bug.