PR for SRVCOM-4301: CQA + DITA readiness for "About OpenShift Serverless" assemblies and modules#108835
Open
kaldesai wants to merge 6 commits intoopenshift:serverless-docs-mainfrom
Open
PR for SRVCOM-4301: CQA + DITA readiness for "About OpenShift Serverless" assemblies and modules#108835kaldesai wants to merge 6 commits intoopenshift:serverless-docs-mainfrom
kaldesai wants to merge 6 commits intoopenshift:serverless-docs-mainfrom
Conversation
|
@kaldesai: This pull request references SRVCOM-4301 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
Author
|
/label serverless |
openshift-ci
bot
added
serverless
openshift-ci
bot
added
size/L
openshift-ci
bot
added
size/XXL
|
@kaldesai: This pull request references SRVCOM-4301 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kaldesai: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Contributor
shreyasiddhartha
left a comment
shreyasiddhartha
left a comment
There was a problem hiding this comment.
Great work, Kalyani! Only a few nits otherwise LGTM. :)
Peer review done.
| * {ocp-product-title} | ||
| * {dedicated-product-title} | ||
| ==== | ||
| The following section on defining cluster size requirements applies to {ocp-product-title} and {dedicated-product-title}. |
Contributor
There was a problem hiding this comment.
Don't know if this sentence should still go here. There's nothing to follow in here.
| = About Knative Serving | ||
|
|
||
| [role="_abstract"] | ||
| Knative Serving builds on Kubernetes to support deploying and serving of applications and functions as serverless containers. Serving simplifies the application deployment, dynamically scales based on in incoming traffic and supports custom rollout strategies with traffic splitting. |
Contributor
There was a problem hiding this comment.
Suggested change
| Knative Serving builds on Kubernetes to support deploying and serving of applications and functions as serverless containers. Serving simplifies the application deployment, dynamically scales based on in incoming traffic and supports custom rollout strategies with traffic splitting. | |
| Knative Serving builds on Kubernetes to support deploying and serving of applications and functions as serverless containers. Serving simplifies the application deployment, dynamically scales based on in incoming traffic, and supports custom rollout strategies with traffic splitting. |
|
|
||
| Knative Eventing supports the following use cases: | ||
|
|
||
| Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events. |
Contributor
There was a problem hiding this comment.
Suggested change
| Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events. | |
| Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST and use binding to decouple the destination configuration from your application that produces events. |
|
|
||
| Service:: The `service.serving.knative.dev` custom resource definition (CRD) manages the lifecycle of your workload and ensures that the application runs and remains reachable through the network. It creates a route, a configuration, and a new revision for each change to a user-created service, or custom resource. Developers interact with Knative primarily by modifying services. | ||
|
|
||
| Revision:: The `revision.serving.knative.dev` custom resource definition (CRD) represents a point-in-time snapshot of the code and configuration for each modification to the workload. Revisions are immutable objects, and you can retain them if needed. |
Contributor
There was a problem hiding this comment.
Suggested change
| Revision:: The `revision.serving.knative.dev` custom resource definition (CRD) represents a point-in-time snapshot of the code and configuration for each modification to the workload. Revisions are immutable objects, and you can retain them if needed. | |
| Revision:: The `revision.serving.knative.dev` custom resource definition (CRD) represents a point-in-time snapshot of the code and configuration for each modification to the workload. Revisions are immutable objects and you can retain them, if needed. |
| = Event state timeout | ||
|
|
||
| [role="_abstract"] | ||
| You can use the `Event` state to wait for one or more events, run a set of actions, and then continue execution. If the Event state serves as the starting state, the workflow creates a new instance. |
Contributor
There was a problem hiding this comment.
Suggested change
| You can use the `Event` state to wait for one or more events, run a set of actions, and then continue execution. If the Event state serves as the starting state, the workflow creates a new instance. | |
| You can use the `Event` state to wait for one or more events, run a set of actions, and then continue execution. If the `Event` state serves as the starting state, the workflow creates a new instance. |
|
|
||
| When using the relative endpoints, you must specify the host as a property. The format of the host property is `kogito.sw.functions.<function_name>`.host. In this example, `kogito.sw.functions.multiplyAllByAndSum.host` is the host property key. You can override the default port (80) if needed by specifying the `kogito.sw.functions.multiplyAllAndSum.port` property. | ||
|
|
||
| This endpoint expects as body a JSON object whose field `numbers` is an array of integers, multiplies each item in the array by `multiplier` and returns the sum of all the multiplied items. |
Contributor
There was a problem hiding this comment.
Suggested change
| This endpoint expects as body a JSON object whose field `numbers` is an array of integers, multiplies each item in the array by `multiplier` and returns the sum of all the multiplied items. | |
| This endpoint expects as body a JSON object whose field `numbers` is an array of integers, multiplies each item in the array by `multiplier`, and returns the sum of all the multiplied items. |
| [role="_abstract"] | ||
| You can use the `sysout` function for logging, as shown in the following example: | ||
|
|
||
| .Example of `sysout` function definition |
Contributor
There was a problem hiding this comment.
Suggested change
| .Example of `sysout` function definition |
Remove the heading
|
|
||
| In the `state` definition, you can call the same `sysout` function as shown in the following example: | ||
|
|
||
| .Example of a `sysout` function reference within a state |
Contributor
There was a problem hiding this comment.
Suggested change
| .Example of a `sysout` function reference within a state |
| OpenShift Serverless Logic defines several timeouts configurations that you can use to configure maximum times for the workflow execution in different scenarios. You can configure how long a workflow can wait for an event to arrive when it is in a given state or the maximum execution time for the workflow. | ||
|
|
||
| Regardless of where it is defined, a timeout must be configured as an amount of time or duration, which starts when the referred workflow element becomes active. Timeouts use the `ISO 8601 data and time standard` to specify a duration of time and follow the format `PnDTnHnMn.nS`, with days considered to be exactly 24 hours. For example, `PT15M` configures 15 minutes, and `P2DT3H4M` defines 2 days, 3 hours, and 4 minutes. | ||
| Regardless of where it is defined, you must configure a timeout as an amount of time or duration, which starts when the referred workflow element becomes active. Timeouts use the `ISO 8601 data and time standard` to specify a duration of time and follow the format `PnDTnHnMn.nS`, with days considered to be exactly 24 hours. For example, `PT15M` configures 15 minutes, and `P2DT3H4M` defines 2 days, 3 hours, and 4 minutes. |
Contributor
There was a problem hiding this comment.
Suggested change
| Regardless of where it is defined, you must configure a timeout as an amount of time or duration, which starts when the referred workflow element becomes active. Timeouts use the `ISO 8601 data and time standard` to specify a duration of time and follow the format `PnDTnHnMn.nS`, with days considered to be exactly 24 hours. For example, `PT15M` configures 15 minutes, and `P2DT3H4M` defines 2 days, 3 hours, and 4 minutes. | |
| Regardless of where it is defined, you must configure a timeout as an amount of time or duration which starts when the referred workflow element becomes active. Timeouts use the `ISO 8601 data and time standard` to specify a duration of time and follow the format `PnDTnHnMn.nS`, with days considered to be exactly 24 hours. For example, `PT15M` configures 15 minutes, and `P2DT3H4M` defines 2 days, 3 hours, and 4 minutes. |
| == Knative Serving resources | ||
|
|
||
| Service:: The `service.serving.knative.dev` CRD automatically manages the life cycle of your workload to ensure that the application is deployed and reachable through the network. It creates a route, a configuration, and a new revision for each change to a user created service, or custom resource. Most developer interactions in Knative are carried out by modifying services. | ||
| Knative Serving helps developers create, deploy, and manage cloud-native applications. It provides Kubernetes custom resource definitions (CRDs) that define and control serverless workloads on an {ocp-product-title} cluster. Developers use these CRDs to create custom resources (CRs) as building blocks for complex use cases, such as rapidly deploying serverless containers or automatically scaling pods. |
Contributor
There was a problem hiding this comment.
Suggested change
| Knative Serving helps developers create, deploy, and manage cloud-native applications. It provides Kubernetes custom resource definitions (CRDs) that define and control serverless workloads on an {ocp-product-title} cluster. Developers use these CRDs to create custom resources (CRs) as building blocks for complex use cases, such as rapidly deploying serverless containers or automatically scaling pods. | |
| Knative Serving helps developers create, deploy, and manage cloud-native applications. It provides Kubernetes custom resource definitions (CRDs) that define and control serverless workloads on an {ocp-product-title} cluster. Developers use these CRDs to create custom resources (CRs) as building blocks for complex use cases such as rapidly deploying serverless containers or automatically scaling pods. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You can cherry-pick for the following branches:
serverless-docs-1.37serverless-docs-1.38serverless-docs-1.36Note for the peer & merge reviewer:
Changes:
This PR prepares the "About OpenShift Serverless" section for Phase 0 DITA migration by applying Vale (AsciiDoc DITA) rules and cleaning up the existing content.
Tracking JIRA: https://redhat.atlassian.net/browse/SRVCOM-4301
Reviews: