`Flagd` serves flagd service with random port even if default port `8013` was set

[kimsehwan96]

I setmanagementPort and port in FeatureFlagSource like below, but only managementPort was correctly set and port was not.

FeatureFlagSource

apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
  name: feature-flag-source
spec:
  sources:
    - source: http://foo.bar.com
      provider: http
      interval: 5
  port: 8888
  debugLogging: true
  defaultSyncProvider: http
  evaluator: json
  managementPort: 9999

Flagd

apiVersion: core.openfeature.dev/v1beta1
kind: Flagd
metadata:
  name: flagd
spec:
  replicas: 1
  ...
  featureFlagSource: feature-flag-source
  ingress:
  ...

Operator creates flagd pods but only managementPort was properly set not the port

│ 2024-10-04T05:00:34.767Z    info    cmd/start.go:107    flagd version: v0.11.1 (9ac329f9206360e532d615904f977309b0af71a5), built at: 2024-07-08    {"component": "start"}
│ 2024-10-04T05:00:34.768Z    debug    telemetry/builder.go:68    skipping trace provider setup as collector target is not set. Traces will use NoopTracerProvider provider and propagator will use no-Op TextMapPr
│ 2024-10-04T05:00:34.768Z    info    flag-sync/sync_service.go:54    starting flag sync service on port 8015    {"component": "FlagSyncService"}
│ 2024-10-04T05:00:34.768Z    debug    builder/syncbuilder.go:95    using remote sync-provider for: http://xxx.svc.cluster.local:8080/core/v1/flagd    {"component": "sync"}
│ 2024-10-04T05:00:34.768Z    info    flag-evaluation/connect_service.go:247    metrics and probes listening at 9999    {"component": "service"}
│ 2024-10-04T05:00:34.768Z    info    ofrep/ofrep_service.go:56    ofrep service listening at 8016    {"component": "OFREPService"}
│ 2024-10-04T05:00:34.769Z    info    flag-evaluation/connect_service.go:227    Flag IResolver listening at :38293    {"component": "service"}
│ 2024-10-04T05:00:34.778Z    debug    http/http_sync.go:71    polling http://foo.bar.com every 5 seconds    {"component": "sync", "sync": "remote"}

I set the flagd port with 8888 in FeatureFlagSource but as you can see in above logs, IResolver was not served with 8888 port.

So we need to add --port argument and its configuration in flagd pod.

open-feature-operator/common/flagdinjector/flagdinjector.go

Lines 389 to 410 in 64cdc25

	func (fi *FlagdContainerInjector) generateBasicFlagdContainer(flagSourceConfig *api.FeatureFlagSourceSpec) corev1.Container {
	return corev1.Container{
	Name: "flagd",
	Image: fmt.Sprintf("%s:%s", fi.Image, fi.Tag),
	Args: []string{
	"start",
	"--management-port",
	fmt.Sprintf("%d", flagSourceConfig.ManagementPort),
	},
	ImagePullPolicy: common.FlagdImagePullPolicy,
	VolumeMounts: []corev1.VolumeMount{},
	Env: []corev1.EnvVar{},
	Ports: []corev1.ContainerPort{
	{
	Name: "management",
	ContainerPort: flagSourceConfig.ManagementPort,
	},
	},
	SecurityContext: getSecurityContext(),
	Resources: fi.FlagdResourceRequirements,
	}
	}

[kimsehwan96]

I think it caused by wrong environment variable in flagd pod.

It was operator created flagd pod spec.

apiVersion: v1
kind: Pod
metadata:
  name: flagd
...
spec:
  containers:
    - name: flagd
      image: ghcr.io/open-feature/flagd:v0.11.1
      args:
        - start
        - --management-port
        - "8014"
        ...
      env:
        - name: _MANAGEMENT_PORT
          value: "8014"
        - name: _PORT
          value: "8013"
        - name: _EVALUATOR
          value: json
        - name: _LOG_FORMAT
        - name: _RESOLVER
          value: rpc

Is it right environment variable name with _ prefix? (_PORT, _MANAGEMNET_PORT)

My helm chart version is 0.7.2

[beeme1mr]

The prefix should be "FLAGD". Here's a list of valid environment variables.

[toddbaert]

Ya this is a bug - not sure how it got overlooked.

The env-vars are more useful for the sidecar-style deployment - since they are injected both into the flagd container (sidecar) and the application container to keep them in sync. There might be a reason to ensure they are set properly here but I'm not sure it really matters.

I think the important thing is to apply all the configs from the FeatureFlagSourceSpec to the startup args here.