General cleanup

.golangci.yaml

@@ -1,5 +1,5 @@
 # Our default golangci-lint configuration
-# If these linters fail then it should fail the build.
+# If these linters fail, then it should fail the build.
 run:
   timeout: 5m
 linters:

README.md

@@ -23,8 +23,8 @@ It effectively deals with the issues mentioned by creating special versions just
 
 This section describes how to create a working environment for developing _Dynamic Environment_.
 While it's not mandatory to follow these instructions or use the same tools, it's highly recommended
-to keep the versions and some install procedures (e.g, _Istio_ installation into kubernetes) to make
-sure everything passes the tests correctly.
+to keep the versions and some installation procedures (e.g., _Istio_ installation into kubernetes)
+to make sure everything passes the tests correctly.
 
 ### Tool Versions
 
@@ -50,7 +50,7 @@ asdf install
 You should now have the right versions of the tools installed. As long as you installed _asdf_
 correctly, and you're running from within the repository root you'll be using the right versions.
 
-Here are other tools, that while not required, can make life easier:
+Here are other tools that while not required, can make life easier:
 
 * `kubectl`: Make sure it's a version that matches our cluster version according to the [version
   skew policy][skew] (if you don't want to mess with multiple versions, and you're using minikube
@@ -80,15 +80,15 @@ similar to the _CI_ as possible).
 We will use [minikube][] as our development cluster. Feel free to use whichever cluster suits you
 best, but try to preserve the kubernetes version.
 
-After installing minikube we need to start a new
+After installing minikube, we need to start a new
 cluster. You can play a little with the _memory_ and the _cpus_ but since we're going to run
 resources on it, it's better to give it more resources than the default:
 
 ```shell
 minikube start --kubernetes-version v1.26.3 --memory 8g --cpus 4
 ```
 
-For the rest of the command make sure your _kubectl_ is operating on the minikube context:
+For the rest of the commands, make sure your _kubectl_ is operating on the minikube context:
 
 ```shell
 kubectx -c # should return 'minikube'
@@ -122,7 +122,7 @@ It's better to stop minikube when you're done working for the day_.
 Some tests should run against a dedicated cluster. It is recommended that you'll have a
 default named _Kind_ cluster for testing.
 
-A prerequisite for running _Kind_ is a docker service. Make sure you have one installed (e.g,
+A prerequisite for running _Kind_ is a docker service. Make sure you have one installed (e.g.,
 _Rancher Desktop_). Assuming you followed the instructions above you should have the right version
 of _Kind_ installed.
 
@@ -140,7 +140,7 @@ Install required dependencies and controller docker image:
 
 `
 
-**From now on make sure your k8s context points to the test cluster.**
+**From now on, make sure your k8s context points to the test cluster.**
 
 Deploy the controller to the cluster (this step should be repeated every time you update the
 controller code):
@@ -149,7 +149,7 @@ controller code):
 ./e2e-testing/scripts/setup.sh deploy
 ````
 
-If you want to clean up the test cluster you can run one of the following commands:
+If you want to clean up the test cluster, you can run one of the following commands:
 
 ```shell
 # Undeploy the controller and dependencies
@@ -204,7 +204,7 @@ sure you follow the rules for creating tests:
 
 * Your first test manifest should create a new namespace (preferably named like your test directory)
   and all test resources (deployments, destination rules, virtual services, etc.) should be deployed
-  to that namespace. If required create more than one namespace. This will prevent collisions
+  to that namespace. If required, create more than one namespace. This will prevent collisions
   between test cases.
 * Every namespace added (per the previous step) should contain an _Istio_ namespace:
     ```yaml
@@ -237,7 +237,7 @@ kuttl test --start-kind=false -n default --timeout 20 ./e2e-testing/kuttl --test
 
 While we run default linters during our _test_ stage, it's advisable to occasionally run other
 linters. These should not break the build (and not included in our configuration) and might contain
-a lot of false positives, however you should occasionally run them to manually search for errors:
+a lot of false positives, however, you should occasionally run them to manually search for errors:
 
 ```shell
 # get a list of linters (at the end of the output there are some convenient presets)

api/v1alpha1/dynamicenv_types.go

@@ -46,7 +46,7 @@ const (
 	Ready      GlobalReadyStatus = "ready"
 	Processing GlobalReadyStatus = "processing"
 
-	// Whether it's consumer or subset.
+	// Whether it's a consumer or subset.
 	SUBSET   SubsetOrConsumer = iota
 	CONSUMER SubsetOrConsumer = iota
 )
@@ -179,8 +179,8 @@ type DynamicEnvSpec struct {
 	Subsets []Subset `json:"subsets"`
 
 	// Consumers are like subsets but for deployments that do not open a service but connect to external resources for
-	// their work (e.g, offline workers). They are equivalent to subsets in the sense that they launch overriding
-	// deployments with custom image and/or settings. However, since they are only consumers no virtual service or
+	// their work (e.g., offline workers). They are equivalent to subsets in the sense that they launch overriding
+	// deployments with custom image and/or settings. However, since they are only consumers, no virtual service or
 	// destination route will be pointing to them.
 	Consumers []Subset `json:"consumers,omitempty"`
 }
@@ -207,7 +207,7 @@ type StringMatch struct {
 	Regex  string `json:"regex,omitempty"`
 }
 
-// Subsets defines how to generate subsets from existing Deployments
+// Subsets define how to generate subsets from existing Deployments
 type Subset struct {
 	// Deployment name (without namespace)
 	Name string `json:"name"`
@@ -237,7 +237,7 @@ type Subset struct {
 // and the relevant overrides
 type ContainerOverrides struct {
 	// Container name to override in multiple containers' environment. If not
-	// specified we will use the first container.
+	//  specified, we will use the first container.
 	ContainerName string `json:"containerName"`
 
 	// Docker image name overridden to the desired subset
@@ -257,9 +257,9 @@ type ContainerOverrides struct {
 
 // DynamicEnvStatus defines the observed state of DynamicEnv
 type DynamicEnvStatus struct {
-	// Represents the latest available observations of a deployment's current state.
-	Conditions      []Condition               `json:"conditions,omitempty"`
-	SubsetsStatus   map[string]SubsetStatus   `json:"subsetsStatus"`
+	// A detailed status of each subset
+	SubsetsStatus map[string]SubsetStatus `json:"subsetsStatus"`
+	// A detailed status of each consumer
 	ConsumersStatus map[string]ConsumerStatus `json:"consumersStatus,omitempty"`
 	State           GlobalReadyStatus         `json:"state,omitempty"`
 	// desired subsets and consumers count
@@ -277,7 +277,7 @@ type DynamicEnvList struct {
 	Items           []DynamicEnv `json:"items"`
 }
 
-// SubsetStatus Contains aggregation of all resources status connected to set subset.
+// SubsetStatus Contains aggregation of all resource status connected to set subset.
 type SubsetStatus struct {
 	// Status of the deployment that belongs to the subset
 	Deployment ResourceStatus `json:"deployment,omitempty"`
@@ -327,7 +327,8 @@ func (rs ResourceStatus) IsEqual(other ResourceStatus) bool {
 
 // StatusError shows an error we want to display in the status with the last time it happened. This
 // *does not* have to be the only time it happened. The idea is that a list of errors should only
-// contain single occurrence of an error (just the last).
+//
+//	contain a single occurrence of an error (just the last).
 type StatusError struct {
 	// The error message
 	Error string `json:"error"`
@@ -336,7 +337,7 @@ type StatusError struct {
 }
 
 // SubsetMessages contains a list of messages (errors) that occurred during Reconcile loop. At the
-// end of each loop these messages should be synced to the matching subset status.
+// end of each loop, these messages should be synced to the matching subset status.
 type SubsetMessages struct {
 	Deployment      []string
 	DestinationRule []string

api/v1alpha1/dynamicenv_webhook.go

@@ -122,7 +122,7 @@ func (de *DynamicEnv) validateIstioMatchAnyOf() error {
 	return nil
 }
 
-// Validates certain aspects of the subset. Should be used both on create and update.
+// Validates certain aspects of the subset. Should be used both on creation and update.
 func (de *DynamicEnv) validateSubsetsProperties() error {
 	subsets := append(de.Spec.Subsets, de.Spec.Consumers...)
 	for _, s := range subsets {
@@ -164,7 +164,7 @@ func (de *DynamicEnv) validateIstioMatchImmutable(old runtime.Object) error {
 }
 
 // validatePartialUpdateSubsets verifies that update only occurs within a subset. The name/namespace
-// of the subsets should not be updated (e.g. should not delete or create new subsets).
+// of the subsets should not be updated (e.g., should not delete or create new subsets).
 func (de *DynamicEnv) validatePartialUpdateSubsets(old runtime.Object) error {
 	oldSubsets := append(old.(*DynamicEnv).Spec.Subsets, old.(*DynamicEnv).Spec.Consumers...)
 	newSubsets := append(de.Spec.Subsets, de.Spec.Consumers...)

api/v1alpha1/groupversion_info.go

@@ -25,7 +25,7 @@ import (
 )
 
 var (
-	// GroupVersion is group version used to register these objects
+	// GroupVersion is a group version used to register these objects
 	GroupVersion = schema.GroupVersion{Group: "riskified.com", Version: "v1alpha1"}
 
 	// SchemeBuilder is used to add go types to the GroupVersionKind scheme