You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pkg/apis/configuration/v1/types.go
+35-35Lines changed: 35 additions & 35 deletions
Original file line number
Diff line number
Diff line change
@@ -116,7 +116,7 @@ type PolicyReference struct {
116
116
117
117
// Upstream defines an upstream.
118
118
typeUpstreamstruct {
119
-
//The name of the upstream. Must be a valid DNS label as defined in RFC 1035. For example, hello and upstream-123 are valid. The name must be unique among all upstreams of the resource.
119
+
//The name of the upstream. Must be a valid DNS label as defined in RFC 1035. For example, hello and upstream-123 are valid. The name must be unique among all upstreams of the resource.
120
120
Namestring`json:"name"`
121
121
// The name of a service. The service must belong to the same namespace as the resource. If the service doesn’t exist, NGINX will assume the service has zero endpoints and return a 502 response for requests for this upstream. For NGINX Plus only, services of type ExternalName are also supported (check the prerequisites ).
122
122
Servicestring`json:"service"`
@@ -164,7 +164,7 @@ type Upstream struct {
164
164
Queue*UpstreamQueue`json:"queue"`
165
165
// The SessionCookie field configures session persistence which allows requests from the same client to be passed to the same upstream server. The information about the designated upstream server is passed in a session cookie generated by NGINX Plus.
166
166
SessionCookie*SessionCookie`json:"sessionCookie"`
167
-
//Enables using the Cluster IP and port of the service instead of the default behavior of using the IP and port of the pods. When this field is enabled, the fields that configure NGINX behavior related to multiple upstream servers (like lb-method and next-upstream) will have no effect, as NGINX Ingress Controller will configure NGINX with only one upstream server that will match the service Cluster IP.
167
+
//Enables using the Cluster IP and port of the service instead of the default behavior of using the IP and port of the pods. When this field is enabled, the fields that configure NGINX behavior related to multiple upstream servers (like lb-method and next-upstream) will have no effect, as NGINX Ingress Controller will configure NGINX with only one upstream server that will match the service Cluster IP.
168
168
UseClusterIPbool`json:"use-cluster-ip"`
169
169
// Allows proxying requests with NTLM Authentication. See the ntlm directive. In order for NTLM authentication to work, it is necessary to enable keepalive connections to upstream servers using the keepalive field. Note: this feature is supported only in NGINX Plus.
170
170
NTLMbool`json:"ntlm"`
@@ -179,9 +179,9 @@ type Upstream struct {
179
179
// UpstreamBuffers defines Buffer Configuration for an Upstream.
180
180
typeUpstreamBuffersstruct {
181
181
// Configures the number of buffers. The default is set in the proxy-buffers ConfigMap key.
182
-
Numberint`json:"number"`
182
+
Numberint`json:"number"`
183
183
// Configures the size of a buffer. The default is set in the proxy-buffers ConfigMap key.
184
-
Sizestring`json:"size"`
184
+
Sizestring`json:"size"`
185
185
}
186
186
187
187
// UpstreamTLS defines a TLS configuration for an Upstream.
@@ -233,7 +233,7 @@ type HealthCheck struct {
233
233
// Header defines an HTTP Header.
234
234
typeHeaderstruct {
235
235
// The name of the header.
236
-
Namestring`json:"name"`
236
+
Namestring`json:"name"`
237
237
// The value of the header.
238
238
Valuestring`json:"value"`
239
239
}
@@ -304,7 +304,7 @@ type ActionRedirect struct {
304
304
typeActionReturnstruct {
305
305
// The status code of the response. The allowed values are: 2XX, 4XX or 5XX. The default is 200.
306
306
Codeint`json:"code"`
307
-
//The MIME type of the response. The default is text/plain.
307
+
//The MIME type of the response. The default is text/plain.
308
308
Typestring`json:"type"`
309
309
// The body of the response. Supports NGINX variables*. Variables must be enclosed in curly brackets. For example: Request is ${request_uri}\n.
310
310
Bodystring`json:"body"`
@@ -524,13 +524,13 @@ type UpstreamQueue struct {
524
524
// VirtualServerRouteStatus defines the status for the VirtualServerRoute resource.
525
525
typeVirtualServerRouteStatusstruct {
526
526
// Represents the current state of the resource. There are three possible values: Valid, Invalid and Warning. Valid indicates that the resource has been validated and accepted by the Ingress Controller. Invalid means the resource failed validation or NGINX
527
-
Statestring`json:"state"`
527
+
Statestring`json:"state"`
528
528
// The reason of the current state of the resource.
529
-
Reasonstring`json:"reason"`
529
+
Reasonstring`json:"reason"`
530
530
// The message of the current state of the resource. It can contain more detailed information about the reason.
531
-
Messagestring`json:"message"`
531
+
Messagestring`json:"message"`
532
532
// Defines how other resources reference this resource.
533
-
ReferencedBystring`json:"referencedBy"`
533
+
ReferencedBystring`json:"referencedBy"`
534
534
// Defines the IPs, hostnames and ports used to connect to this resource.
@@ -599,31 +599,31 @@ type TransportServer struct {
599
599
metav1.TypeMeta`json:",inline"`
600
600
metav1.ObjectMeta`json:"metadata,omitempty"`
601
601
// spec field of the TransportServer resource
602
-
SpecTransportServerSpec`json:"spec"`
602
+
SpecTransportServerSpec`json:"spec"`
603
603
// status field of the TransportServer resource
604
604
StatusTransportServerStatus`json:"status"`
605
605
}
606
606
607
607
// TransportServerSpec is the spec of the TransportServer resource.
608
608
typeTransportServerSpecstruct {
609
609
// Specifies which Ingress Controller must handle the VirtualServer resource.
610
-
IngressClassstring`json:"ingressClassName"`
610
+
IngressClassstring`json:"ingressClassName"`
611
611
// The TLS termination configuration.
612
-
TLS*TransportServerTLS`json:"tls"`
612
+
TLS*TransportServerTLS`json:"tls"`
613
613
// Sets a custom HTTP and/or HTTPS listener. Valid fields are listener.http and listener.https. Each field must reference the name of a valid listener defined in a GlobalConfiguration resource
614
-
ListenerTransportServerListener`json:"listener"`
614
+
ListenerTransportServerListener`json:"listener"`
615
615
// Sets a custom snippet in server context. Overrides the server-snippets ConfigMap key.
616
-
ServerSnippetsstring`json:"serverSnippets"`
616
+
ServerSnippetsstring`json:"serverSnippets"`
617
617
// Sets a custom snippet in the stream context. Overrides the stream-snippets ConfigMap key.
618
-
StreamSnippetsstring`json:"streamSnippets"`
618
+
StreamSnippetsstring`json:"streamSnippets"`
619
619
// The host (domain name) of the server. Must be a valid subdomain as defined in RFC 1123, such as my-app or hello.example.com. When using a wildcard domain like *.example.com the domain must be contained in double quotes. The host value needs to be unique among all Ingress and VirtualServer resources. See also Handling Host and Listener Collisions.
@@ -636,7 +636,7 @@ type TransportServerTLS struct {
636
636
// TransportServerListener defines a listener for a TransportServer.
637
637
typeTransportServerListenerstruct {
638
638
// The name of a listener defined in a GlobalConfiguration resource.
639
-
Namestring`json:"name"`
639
+
Namestring`json:"name"`
640
640
// The protocol of the listener.
641
641
Protocolstring`json:"protocol"`
642
642
}
@@ -724,9 +724,9 @@ type TransportServerAction struct {
724
724
// TransportServerStatus defines the status for the TransportServer resource.
725
725
typeTransportServerStatusstruct {
726
726
// Represents the current state of the resource. There are three possible values: Valid, Invalid and Warning. Valid indicates that the resource has been validated and accepted by the Ingress Controller. Invalid means the resource failed validation or
727
-
Statestring`json:"state"`
727
+
Statestring`json:"state"`
728
728
// The reason of the current state of the resource.
729
-
Reasonstring`json:"reason"`
729
+
Reasonstring`json:"reason"`
730
730
// The message of the current state of the resource. It can contain more detailed information about the reason.
731
731
Messagestring`json:"message"`
732
732
}
@@ -755,17 +755,17 @@ type Policy struct {
755
755
metav1.TypeMeta`json:",inline"`
756
756
metav1.ObjectMeta`json:"metadata,omitempty"`
757
757
// spec field of the Policy resource
758
-
SpecPolicySpec`json:"spec"`
758
+
SpecPolicySpec`json:"spec"`
759
759
// status field of the Policy resource
760
760
StatusPolicyStatus`json:"status"`
761
761
}
762
762
763
763
// PolicyStatus is the status of the policy resource
764
764
typePolicyStatusstruct {
765
765
// Represents the current state of the resource. There are three possible values: Valid, Invalid and Warning. Valid indicates that the resource has been validated and accepted by the Ingress Controller. Invalid means the resource failed validation or
766
-
Statestring`json:"state"`
766
+
Statestring`json:"state"`
767
767
// The reason of the current state of the resource.
768
-
Reasonstring`json:"reason"`
768
+
Reasonstring`json:"reason"`
769
769
// The message of the current state of the resource. It can contain more detailed information about the reason.
770
770
Messagestring`json:"message"`
771
771
}
@@ -990,18 +990,18 @@ type SecurityLog struct {
990
990
LogDeststring`json:"logDest"`
991
991
}
992
992
993
-
// The API Key policy configures NGINX to authorize requests which provide a valid API Key in a specified header or query param.
993
+
// The APIKey policy configures NGINX to authorize requests which provide a valid API Key in a specified header or query param.
994
994
typeAPIKeystruct {
995
995
// The location of the API Key. For example, $http_auth, $arg_apikey, $cookie_auth. Accepted variables are $http_, $arg_, $cookie_.
996
-
SuppliedIn*SuppliedIn`json:"suppliedIn"`
996
+
SuppliedIn*SuppliedIn`json:"suppliedIn"`
997
997
// The key to which the API key is applied. Can contain text, variables, or a combination of them. Accepted variables are $http_, $arg_, $cookie_.
998
-
ClientSecretstring`json:"clientSecret"`
998
+
ClientSecretstring`json:"clientSecret"`
999
999
}
1000
1000
1001
1001
// SuppliedIn defines the locations API Key should be supplied in.
1002
1002
typeSuppliedInstruct {
1003
1003
// The location of the API Key as a request header. For example, $http_auth. Accepted variables are $http_.
1004
1004
Header []string`json:"header"`
1005
1005
// The location of the API Key as a query param. For example, $arg_apikey. Accepted variables are $arg_.
0 commit comments