OSDOCS-16491: adds feature gates MicroShift

Author: ShaunaDiaz

_topic_maps/_topic_map_ms.yml

@@ -135,6 +135,8 @@ Topics:
   File: microshift-node-access-kubeconfig
 - Name: About the Generic Device Plugin
   File: microshift-gdp
+- Name: Using feature gates to develop solutions
+  File: microshift-feature-gates
 - Name: Configuring MicroShift authentication and security
   Dir: microshift_auth_security
   Topics:

microshift_configuring/microshift-feature-gates.adoc

@@ -0,0 +1,14 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-feature-gates"]
+= Using feature gates to develop solutions for your applications
+include::_attributes/attributes-microshift.adoc[]
+:context: microshift-feature-gates
+
+toc::[]
+
+[role="_abstract"]
+Use feature gates to test new Kubernetes features for potential use in your {microshift-short} deployments.
+
+include::modules/microshift-feature-gates-con.adoc[leveloffset=+1]
+
+include::modules/microshift-feature-gates-using.adoc[leveloffset=+1]

microshift_configuring/microshift-using-config-yaml.adoc

@@ -6,6 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 Use the {microshift-short} YAML file to customize your preferences, settings, and parameters.
 
 :FeatureName: The Generic Device Plugin for {microshift-short}

modules/microshift-config-nodeport-limits.adoc

@@ -6,6 +6,7 @@
 [id="microshift-nodeport-range-limits_{context}"]
 = Extending the port range for NodePort services
 
+[role="_abstract"]
 The `serviceNodePortRange` setting extends the port range available to NodePort services. This option is useful when specific standard ports under the `30000-32767` range need to be exposed. For example, if your device needs to expose the `1883/tcp` MQ Telemetry Transport (MQTT) port on the network because client devices cannot use a different port.
 
 [IMPORTANT]

modules/microshift-config-parameters-table.adoc

@@ -6,6 +6,7 @@
 [id="microshift-config-parameters-table_{context}"]
 = Parameters and values for the {microshift-short} config.yaml file
 
+[role="_abstract"]
 The following table explains {microshift-short} configuration YAML parameters and valid values for each:
 
 .{microshift-short} `config.yaml` parameters

modules/microshift-config-yaml-custom.adoc

@@ -6,6 +6,7 @@
 [id="microshift-yaml-custom_{context}"]
 = Using custom settings
 
+[role="_abstract"]
 To create custom configurations, make a copy of the `config.yaml.default` file that is given in the `/etc/microshift/` directory, renaming it `config.yaml`. Keep this file in the `/etc/microshift/` directory, and then you can change supported settings that override the defaults before starting or restarting {microshift-short}.
 
 If you have just a few changes to make to the default settings, consider using configuration drop-in snippets as an alternative method.
@@ -22,4 +23,4 @@ Applications and other optional services used with your {microshift-short} node
 [TIP]
 ====
 If you add all of the configurations you need at the same time, you can minimize system restarts.
-====
+====

modules/microshift-feature-gates-con.adoc

@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// microshift_configuring/microshift-feature-gates.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-feature-gates-con_{context}"]
+= Understanding feature gates for {microshift-short}
+
+[role="_abstract"]
+As an application developer for edge computing environments, you can now experiment with upcoming Kubernetes features to evaluate their potential benefits for specific use cases.
+
+By using feature gates, you can test various enhancements that might improve performance in your resource-constrained edge environments. For example, you can try advanced CPU management, enhanced scheduling features, or experimental storage options.
+
+[WARNING]
+====
+When you trial new features using feature gates, your {microshift-short} can become unstable or lose data. Enable feature gates only in non-production environments.
+====
+
+When planning to use feature gates for development, consider the following details:
+
+* After you specify feature gates, you cannot update {microshift-short}.
+* If you are configuration is not valid, {microshift-short} can fail to start.
+* The Kubernetes components you enable handle feature gate validation.
+* Feature gates are disabled by default in {microshift-short}. After you enable feature gates, you cannot disable them.

modules/microshift-feature-gates-using.adoc

@@ -0,0 +1,66 @@
+// Module included in the following assemblies:
+//
+// microshift_configuring/microshift-feature-gates.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="microshift-feature-gates-using_{context}"]
+= Using feature gates for {microshift-short}
+
+[role="_abstract"]
+To use feature gates in your development environment, you must specify them in the `config.yaml` file or create a configuration snippet file. You must also configure the feature set you want to work with.
+
+[IMPORTANT]
+====
+* A `config.yaml` configuration file takes precedence over built-in settings. The `config.yaml` file is read every time the {microshift-short} service starts.
+* Configuration snippet YAMLs take precedence over both built-in settings and the `config.yaml` configuration file.
+* After you enable feature gates, you cannot disable them.
+====
+
+.Prerequisites
+
+* You installed {microshift-short}.
+* You installed the `oc-first`.
+* You have `sudo` privileges on the {microshift-short} host.
+
+.Procedure
+
+. Apply features gates in one of the two following ways:
+
+.. Update the {microshift-short} `config.yaml` configuration file by making a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory. Name it `config.yaml` and keep it in the source directory.
+
+.. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the `/etc/microshift/config.d/` configuration directory. For example, `/etc/microshift/config.d/10-fg.yaml`.
+
+. Replace the default values in the `xyz` section of the {microshift-short} YAML with your valid values, or create a configuration snippet file with the sections you need.
++
+.Feature gates configuration with example values
+[source,yaml]
+----
+# ...
+apiServer:
+  featureGates:
+    featureSet: TechPreviewNoUpgrade
+# ...
+apiServer:
+  featureGates:
+    featureSet: CustomNoUpgrade
+    customNoUpgrade:
+      enabled:
+      - "CPUManagerPolicyAlphaOptions"
+      - "MemoryQoS"
+      disabled:
+      - "SomeDefaultEnabledFeature"
+# ...
+----
+
+. Use the following configuration rules:
+.. You must set the `featureSet` field when configuring feature gates.
+.. When you use `customNoUpgrade` feature, you must set the `featureSet` to `CustomNoUpgrade`. The `customNoUpgrade` field is only valid when `featureSet: CustomNoUpgrade`.
+
+. Configure any settings required for the feature set you want to work with.
+
+. Restart {microshift-short} to apply the configuration changes by running the following command:
++
+[source,terminal]
+----
+$ sudo systemctl restart microshift
+----

modules/microshift-nw-advertise-address.adoc

@@ -6,6 +6,7 @@
 [id="microshift-yaml-advertiseAddress_{context}"]
 = Configuring the advertise address network flag
 
+[role="_abstract"]
 The `apiserver.advertiseAddress` flag specifies the IP address on which to advertise the API server to members of the node. This address must be reachable by the node. You can set a custom IP address here, but you must also add the IP address to a host interface. Customizing this parameter preempts {microshift-short} from adding a default IP address to the `br-ex` network interface.
 
 [IMPORTANT]