Cli single flux step

charts/mccp/templates/clusters-service/configmap.yaml

@@ -59,3 +59,5 @@ data:
   MONITORING_METRICS_ENABLED: {{ .Values.monitoring.metrics.enabled | quote }}
   MONITORING_PROFILING_ENABLED: {{ .Values.monitoring.profiling.enabled | quote }}
   EXPLORER_ENABLED_FOR: {{ .Values.explorer.enabledFor | join "," | quote }}
+  EXPLORER_CLEANER_DISABLED: {{ .Values.explorer.cleaner.disabled | quote }}
+

cmd/clusters-service/app/options.go

@@ -59,7 +59,7 @@ type Options struct {
 	PipelineControllerAddress string
 	CollectorServiceAccount   collector.ImpersonateServiceAccount
 	MonitoringOptions         monitoring.Options
-	EnableObjectCleaner       bool
+	ExplorerCleanerDisabled   bool
 	ExplorerEnabledFor        []string
 }
 
@@ -285,10 +285,10 @@ func WithMonitoring(enabled bool, address string, metricsEnabled bool, profiling
 	}
 }
 
-// WithObjectCleaner enables the object cleaner
-func WithObjectCleaner(enabled bool) Option {
+// WithExplorerCleanerDisabled configure the object cleaner
+func WithExplorerCleanerDisabled(disabled bool) Option {
 	return func(o *Options) {
-		o.EnableObjectCleaner = enabled
+		o.ExplorerCleanerDisabled = disabled
 	}
 }
 

cmd/clusters-service/app/server.go

@@ -162,7 +162,7 @@ type Params struct {
 	MonitoringBindAddress             string                    `mapstructure:"monitoring-bind-address"`
 	MetricsEnabled                    bool                      `mapstructure:"monitoring-metrics-enabled"`
 	ProfilingEnabled                  bool                      `mapstructure:"monitoring-profiling-enabled"`
-	EnableObjectCleaner               bool                      `mapstructure:"enable-object-cleaner"`
+	ExplorerCleanerDisabled           bool                      `mapstructure:"explorer-cleaner-disabled"`
 	NoAuthUser                        string                    `mapstructure:"insecure-no-authentication-user"`
 	ExplorerEnabledFor                []string                  `mapstructure:"explorer-enabled-for"`
 }
@@ -577,7 +577,7 @@ func StartServer(ctx context.Context, p Params, logOptions flux_logger.Options)
 		WithPipelineControllerAddress(p.PipelineControllerAddress),
 		WithCollectorServiceAccount(p.CollectorServiceAccountName, p.CollectorServiceAccountNamespace),
 		WithMonitoring(p.MonitoringEnabled, p.MonitoringBindAddress, p.MetricsEnabled, p.ProfilingEnabled, log),
-		WithObjectCleaner(p.EnableObjectCleaner),
+		WithExplorerCleanerDisabled(p.ExplorerCleanerDisabled),
 		WithExplorerEnabledFor(p.ExplorerEnabledFor),
 	)
 }
@@ -698,7 +698,7 @@ func RunInProcessGateway(ctx context.Context, addr string, setters ...Option) er
 			SkipCollection:      false,
 			ObjectKinds:         configuration.SupportedObjectKinds,
 			ServiceAccount:      args.CollectorServiceAccount,
-			EnableObjectCleaner: args.EnableObjectCleaner,
+			EnableObjectCleaner: !args.ExplorerCleanerDisabled,
 			EnabledFor:          args.ExplorerEnabledFor,
 		})
 		if err != nil {

cmd/gitops/app/bootstrap/cmd.go

@@ -5,7 +5,7 @@
 	"os"
 
 	"github.com/spf13/cobra"
 	. "github.com/weaveworks/weave-gitops-enterprise/pkg/bootstrap"
 	"github.com/weaveworks/weave-gitops-enterprise/pkg/bootstrap/steps"
 	"github.com/weaveworks/weave-gitops/cmd/gitops/config"
 	"github.com/weaveworks/weave-gitops/pkg/logger"
@@ -129,9 +129,9 @@
 			return fmt.Errorf("cannot config bootstrap: %v", err)
 		}
 
 		err = Bootstrap(c)
 		if err != nil {
-			return fmt.Errorf("cannot execute bootstrap: %v", err)
+			return fmt.Errorf("cannot bootstrap: %v", err)
 		}
 		return nil
 	}

docs/cli/adr-config.md

@@ -0,0 +1,174 @@
+# Configuration resolution
+
+You want to use:
+
+- cmd.go is the entry point.
+- the command is configured -> config.go
+- the command is executed -> bootstrap.go
+
+Configuration is on the most important bits in terms of experience. We have different options 
+to address them.
+
+Configuration comes from the following sources:
+
+1. existing state 
+2. user introduced values via flags
+3. user introduced values via interactive questions
+4. default values
+
+With the principles of 
+1. the simplest experience possible for day-0 users.
+2. the safest environment possible for day-0 and day-1 users where state mutations comes as results of an 
+explicit demand of the user.
+
+We then analysis options and give recommendations. 
+
+## Validation scenarios.
+
+1. `Day-0-Likely`: A user that haven't bootstrapped yet and wants to bootstrap interactive: `flux bootstrap`
+   - ask - the common case where you have little knowledge
+2. `Day-0-UnLikely`:A user that havent bootstrapped yet and wants non-interactive or silent: `flux bootstrap -s`
+   - ignore: it is rare cause there is conflicting principle that is unlikely that you would get the journey completed without
+     several attempts as there are many flags to introduce. Non-interactive scenarios are more likely for day1 journeys.
+3. `Day-1-Likely`: a user that have bootstrapped and wants non-interactive (silent) mode
+    - no ask - use input: you dont have previous values and have signaled that you want to use flag values.
+    - no ask - use existing: you do have previous values and no new values.
+    - no ask - overwrite: you have already previous values and have signaled that you want to use flag values. 
+4. `Day-1-Likely`: a user that have bootstrapped but wants interactive
+    - ask suggest previous value: you have previous values no values introduced
+    - ask conflict: you have previous values and values introduced
+    - no ask - use values: you dont have previous values and values introduced
+
+## Option A: there is no default values configuration layer
+
+
+### How it looks like 
+
+1. Configuration <- empty
+2. Configuration <- discovered from `existing state`
+3. Configuration <- f(configuration, `user introduced values`)
+    - This would lead for conflicts if existing configuration value is different to user introduce value.
+    - We need `overwrite` semantics with conservative behaviour as follows:
+        - if flag `overwrite` exists -> user introduced values
+        - otherwise
+            - if non-interactive -> fail
+            - if interactive -> ask the user
+    - Values introduced as flag wont be asked as interactive 
+4. Configuration <- f(configuration, `interactive values`, `suggested value`): for those values required not yet with value from the previous layer we ask ineractive where the selected value 
+   by default is the default value. 
+   - Values not-introduced as flag will be asked as interactive session where the user will have a suggested value 
+   where `suggestedValue:=f(existing state value, default value)`:
+      - if existing state value is not empty -> existing state value
+      - otherwise default value
+
+Suggested Values is created during configuration as part of StepInput. The suggested value should ensure it is a safe option. 
+
+From 
+
+```go 
+type StepInput struct {
+	Name            string
+	Msg             string
+	StepInformation string
+	Type            string
+	DefaultValue    any
+	Value           any
+	Values          []string
+	Valuesfn        func(input []StepInput, c *Config) (interface{}, error)
+	Enabled         func(input []StepInput, c *Config) bool
+	Required        bool
+}
+```
+
+To 
+
+```go 
+type StepInput struct {
+	Name            string
+	Msg             string
+	StepInformation string
+	Type            string
+	SuggestedValue    any
+	Value           any
+	Values          []string
+	Valuesfn        func(input []StepInput, c *Config) (interface{}, error)
+	Enabled         func(input []StepInput, c *Config) bool
+	Required        bool
+}
+```
+
+#### Validation scenarios.
+
+1. `Day-0-Likely`: A user that haven't bootstrapped yet and wants to bootstrap interactive: `flux bootstrap`
+
+- existing state: no
+- user introduced values via flags: no
+- user introduced values via interactive questions: yes
+- default values: yes
+
+The user will be able to complete the configuration journey based on the interactive session
+
+2. `Day-1-Likely`: a user that have bootstrapped and wants to overwrite non-interactive:
+
+- existing state: yes
+- user introduced values via flags: no
+- user introduced values via interactive questions: yes
+- default values: yes
+
+The user will be able to overwrite the existing state cause during the interactive session the suggested value 
+will be the existing state values instead of the default.
+
+
+3. `Day-1-Likely `: a user that have bootstrapped and wants to overwrite interactive:
+
+- existing state: yes
+- user introduced values via flags: yes
+- user introduced values via interactive questions: yes
+- default values: yes
+
+The user will be able:
+    - overwrite via flags
+    - overwrite via interactive 
+
+
+### Analysis
+
+## Option B: there is default values configuration layer that is the first configuration layer
+
+### How it looks like
+
+1. Configuration <- empty
+2. Configuration <- f(configuration,default values)
+3. Configuration <- f(configuration,discovered from existing state)
+4. Configuration <- f(configuration,user introduced value)
+    - This would lead for conflicts if existing configuration value is different to user introduce value.
+    - We need `overwrite` semantics with conservative behaviour as follows:
+        - if flag `overwrite` exists -> user introduced values
+        - otherwise
+            - if non-interactive -> fail
+            - if interactive -> ask the user
+
+Interactive questions for those required but empty values:
+- not having defaults but required
+- not discovered from existing state
+- not introduced by user flags
+
+### Analysis
+
+Pro:
+- User does not need to introduce values for those wht
+Cons:
+
+## Option C: there is default values configuration layer that is the last configuration layer
+
+### How it looks like
+
+1. Configuration <- empty
+2. Configuration <- f(configuration,discovered from existing state)
+3. Configuration <- f(configuration,user introduced value)
+4. Configuration <- f(configuration,default values)
+
+### Analysis
+
+
+## Recommendation 

docs/cli/bootstrap.md

@@ -62,6 +62,9 @@ func selectWgeVersion(input []StepInput, c *Config) ([]StepOutput, error) {
 		}
 
 ```
+
+
+
 ## How can I add a new step?
 
 Follow these indications:
@@ -234,7 +237,7 @@ This will be addressed in the following [ticket](https://github.com/weaveworks/w
 
 ## Enable/Disable one or more input from step inputs
 
-Field [`Enabled`](https://github.com/weaveworks/weave-gitops-enterprise/blob/80667a419c286ee7d45178b639e36a2015533cb6/pkg/bootstrap/steps/ask_bootstrap_flux.go#L14) is added to the step input to allow/disallow this input from being processd
+Field [`Enabled`](https://github.com/weaveworks/weave-gitops-enterprise/blob/80667a419c286ee7d45178b639e36a2015533cb6/pkg/bootstrap/steps/ask_bootstrap_flux.go#L14) is added to the step input to allow/disallow this input from being processed
 
 This field should receive a function that takes the step input, config object and returns boolean value 
 

go.mod

@@ -427,5 +427,15 @@ replace (
 	k8s.io/client-go => k8s.io/client-go v0.27.7
 	k8s.io/component-base => k8s.io/component-base v0.26.3
 	k8s.io/component-helpers => k8s.io/component-helpers v0.26.3
+	k8s.io/controller-manager => k8s.io/controller-manager v0.26.3
+	k8s.io/csi-translation-lib => k8s.io/csi-translation-lib v0.26.3
+	k8s.io/dynamic-resource-allocation => k8s.io/dynamic-resource-allocation v0.26.3
+	k8s.io/kube-controller-manager => k8s.io/kube-controller-manager v0.26.3
+	k8s.io/kube-proxy => k8s.io/kube-proxy v0.26.3
+	k8s.io/kube-scheduler => k8s.io/kube-scheduler v0.26.3
 	k8s.io/kubectl => k8s.io/kubectl v0.26.3
+	k8s.io/legacy-cloud-providers => k8s.io/legacy-cloud-providers v0.26.3
+	k8s.io/mount-utils => k8s.io/mount-utils v0.26.3
+	k8s.io/sample-apiserver => k8s.io/sample-apiserver v0.26.3
+	k8s.io/cloud-provider => k8s.io/cloud-provider v0.26.3
 )

pkg/bootstrap/bootstrap.go

@@ -1,25 +1,33 @@
 package bootstrap
 
 import (
+	"fmt"
+
 	"github.com/weaveworks/weave-gitops-enterprise/pkg/bootstrap/steps"
 )
 
 // Bootstrap initiated by the command runs the WGE bootstrap workflow
 func Bootstrap(config steps.Config) error {
+
+	adminCredentials, err := steps.NewAskAdminCredsSecretStep(config.ClusterUserAuth)
+	if err != nil {
+		return fmt.Errorf("cannot create ask admin creds step: %v", err)
+	}
+
 	// TODO have a single workflow source of truth and documented in https://docs.gitops.weave.works/docs/0.33.0/enterprise/getting-started/install-enterprise/
 	var steps = []steps.BootstrapStep{
-		steps.VerifyFluxInstallation,
-		steps.NewAskBootstrapFluxStep(config),
-		steps.NewGitRepositoryConfig(config),
-		steps.NewBootstrapFlux(config),
-		steps.CheckEntitlementSecret,
-		steps.NewSelectWgeVersionStep(config),
-		steps.NewAskAdminCredsSecretStep(config),
-		steps.NewSelectDomainType(config),
-		steps.NewInstallWGEStep(config),
-		steps.NewInstallOIDCStep(config),
-		steps.NewOIDCConfigStep(config),
-		steps.CheckUIDomainStep,
+		//steps.VerifyFluxInstallation,
+		//steps.NewAskBootstrapFluxStep(config),
+		//steps.NewGitRepositoryConfig(config),
+		//steps.NewBootstrapFlux(config),
+		//steps.CheckEntitlementSecret,
+		//steps.NewSelectWgeVersionStep(config),
+		adminCredentials,
+		//steps.NewSelectDomainType(config),
+		//steps.NewInstallWGEStep(config),
+		//steps.NewInstallOIDCStep(config),
+		//steps.NewOIDCConfigStep(config),
+		//steps.CheckUIDomainStep,
 	}
 
 	for _, step := range steps {