cwielenb/CNCF-Dataset huggingface dataset:
Project: YugabyteDB (App Definition and Development / Database)
File: ysql-create-roles.md

Create a role with a password. You can do this with the statement. As an example, let us create a role `engineering` for an engineering team in an organization. ```plpgsql yugabyte=# CREATE ROLE engineering; ``` Roles that have `LOGIN` privileges are users. As an example, you can create a user `john` as follows: ```plpgsql yugabyte=# CREATE ROLE john LOGIN PASSWORD 'PasswdForJohn'; ``` Read about in the Authentication section. You can grant a role to another role (which can be a user), or revoke a role that has already been granted. Executing the `GRANT` and the `REVOKE` operations requires the `AUTHORIZE` privilege on the role being granted or revoked. As an example, you can grant the `engineering` role you created above to the user `john` as follows: ```plpgsql yugabyte=# GRANT engineering TO john; ``` Read more about . In YSQL, you can create a hierarchy of roles. The privileges of any role in the hierarchy flows downward. As an example, let us say that in the above example, you want to create a `developer` role that inherits all the privileges from the `engineering` role. You can achieve this as follows. First, create the `developer` role. ```plpgsql yugabyte=# CREATE ROLE developer; ``` Next, `GRANT` the `engineering` role to the `developer` role. ```plpgsql yugabyte=# GRANT engineering TO developer; ``` You can list all the roles by running the following statement: ```plpgsql yugabyte=# SELECT rolname, rolcanlogin, rolsuper, memberof FROM pg_roles; ``` You should see the following output: ``` rolname | rolcanlogin | rolsuper | memberof -+-+-+-- john | t | f | {engineering} developer | f | f | {engineering} engineering | f | f | {} yugabyte | t | t | {} (4 rows) ``` In the table above, note the following: The `yugabyte` role is the built-in superuser. The role `john` can log in, and hence is a user. Note that `john` is not a superuser. The roles `engineering` and `developer` cannot log in. Both `john` and `developer` inherit the role `engineering`. Roles can be revoked using the statement. In the above example, you can revoke the `engineering` role from the user `john` as follows: ```plpgsql yugabyte=# REVOKE engineering FROM john; ``` Listing all the roles now shows that `john` no longer inherits from the `engineering` role: ```plpgsql yugabyte=# SELECT rolname, rolcanlogin, rolsuperuser, memberof FROM pg_roles; ``` ``` rolname | rolcanlogin | rolsuper | memberof -+-+-+-- john | t | f | {} developer | f | f | {engineering} engineering | f | f | {} yugabyte | t | t | {} (4 rows) ``` Roles can be dropped with the statement. In the above example, you can drop the `developer` role with the following statement: ```plpgsql yugabyte=# DROP ROLE developer; ``` The `developer` role would no longer be present upon listing all the roles: ```plpgsql yugabyte=# SELECT rolname, rolcanlogin, rolsuper, memberof FROM pg_roles; ``` ``` rolname | rolcanlogin | rolsuper | memberof -+-+-+-- john | t | f | {} engineering | f | f | {} yugabyte | t | t | {} (3 rows) ```
Project: StarRocks (App Definition and Development / Database)
File: starts_with.md

displayed_sidebar: "English" This function returns 1 when a string starts with a specified prefix. Otherwise, it returns 0. When the argument is NULL, the result is NULL. ```Haskell BOOLEAN starts_with(VARCHAR str, VARCHAR prefix) ``` ```Plain Text mysql> select starts_with("hello world","hello"); +-+ |starts_with('hello world', 'hello') | +-+ | 1 | +-+ mysql> select starts_with("hello world","world"); +-+ |starts_with('hello world', 'world') | +-+ | 0 | +-+ ``` START_WITH
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno_completion_bash.md

Generate the autocompletion script for bash Generate the autocompletion script for the bash shell. This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager. To load completions in your current shell session: source <(kyverno completion bash) To load completions for every new session, execute once: kyverno completion bash > /etc/bash_completion.d/kyverno kyverno completion bash > $(brew --prefix)/etc/bash_completion.d/kyverno You will need to start a new shell for this setup to take effect. ``` kyverno completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Generate the autocompletion script for the specified shell
Project: TDengine (App Definition and Development / Database)
File: performance-related-questions.md

name: Performance-related Questions about: Any questions related to TDengine's performance. title: '' labels: performance assignees: '' Performance Issue Any questions related to TDengine's performance can be discussed here. Problem Description A clear and concise description of what the problem is. To Reproduce Steps to reproduce the behavior: Database parameters used: ```show databases``` Verbs used: Insert/Import/Select? Describe the total amount of data Observed performance vs. expected performance Screenshots If applicable, add screenshots to help explain your problem. Environment (please complete the following information): OS: [e.g. CentOS 7.0] Memory, CPU, current Disk Space TDengine Version [e.g. 1.6.1.7] Additional Context Add any other context about the problem here.
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: observability.md

id: observability title: Observability description: Adding Observability to Your Plugin This article briefly describes the observability options that are available to a Backstage integrator. See how to install Datadog Events in your app The backend supplies a central logging service, , as well as a plugin based logger, from `coreServices`. To add additional granularity to your logs, you can create children from the plugin based logger, using the `.child()` method and provide is with JSON data. For example, if you wanted to log items for a specific span in your plugin, you could do ```ts export function createRouter({ logger }) { const router = Router(); router.post('/task/:taskId/queue', (req, res) => { const { taskId } = req.params; const taskLogger = logger.child({ task: taskId }); taskLogger.log('Queueing this task.'); }); router.get('/task/:taskId/results', (req, res) => { const { taskId } = req.params; const taskLogger = logger.child({ task: taskId }); taskLogger.log('Getting the results of this task.'); }); } ``` You can also add additional metadata to all logs for your Backstage instance by overriding the `rootLogger` implementation, you can see an example in . The backend supplies a central root logger that plugins are expected to use for their logging needs. In the default production setup, it emits structured JSON logs on stdout, with a field `"service": "backstage"` and also tagged on a per-plugin basis. Plugins that want to more finely specify what part of their processes that emitted the log message should add a `"component"` field to do so. An example log line could look as follows: ```json { "service": "backstage", "type": "plugin", "plugin": "catalog", "component": "catalog-all-locations-refresh", "level": "info", "message": "Locations Refresh: Refreshing location bootstrap:bootstrap" } ``` The new backend is moving towards health checks being plugin-based, as such there is no current plugin for providing a health check route. You can add this yourself easily though, ```ts import { coreServices, createBackendModule, createBackendPlugin, } from '@backstage/backend-plugin-api'; const healthCheck = createBackendPlugin({ pluginId: 'healthcheck', register(env) { env.registerInit({ deps: { rootHttpRouter: coreServices.rootHttpRouter, }, init: async ({ rootHttpRouter }) => { // You can adjust the route name and response as you need. rootHttpRouter.use('/healthcheck', (req, res) => { res.json({ status: 'ok' }); }); }, }); }, }); ``` The example old backend in the Backstage repository a very basic health check endpoint on the `/healthcheck` route. You may add such a handler to your backend as well, and supply your own logic to it that fits your particular health checking needs.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: publish-all.md

Publish all exposed ports to random ports on the host interfaces. The default is false. When set to true, publish all exposed ports to the host interfaces. If the operator uses -P (or -p) then Podman makes the exposed port accessible on the host and the ports are available to any client that can reach the host. When using this option, Podman binds any exposed port to a random port on the host within an ephemeral port range defined by /proc/sys/net/ipv4/ip_local_port_range. To find the mapping between the host ports and the exposed ports, use podman port.
Project: Vald (App Definition and Development / Database)
File: about-vald.md

This document gives an overview of what is Vald and what you can do with Vald. <!-- copied from README.md--> Vald is a highly scalable distributed fast approximate nearest neighbor dense vector search engine. Vald is designed and implemented based on Cloud-Native architecture. It uses the fastest ANN Algorithm to search neighbors. Vald has automatic vector indexing and index backup, and horizontal scaling which made for searching from billions of feature vector data. Vald is easy to use, feature-rich and highly customizable as you needed. <!-- copied from README.md--> Asynchronous Auto Indexing Usually the graph requires locking during indexing, which causes stop-the-world. But Vald uses distributed index graphs so it continues to work during indexing. Customizable Ingress/Egress Filtering Vald implements it's own highly customizable Ingress/Egress filter. Which can be configured to fit the gRPC interface. Ingress Filter: Ability to Vectorize through filter on request. Egress Filter: rerank or filter the searching result with your own algorithm. Cloud-native based vector searching engine Horizontal scalable on memory and CPU for your demand. Auto Backup for Index data Vald supports to backup Vald Agent index data using Object Storage or Persistent Volume. Distributed Indexing Vald distributes vector index to multiple agents, and each agent stores different index. Index Replication Vald stores each index in multiple agents which enables index replicas. Automatically rebalancing the replica when some Vald agent goes down. Easy to use Vald can be easily installed in a few steps. Highly customizable You can configure the number of vector dimensions, the number of replica and etc. Multi language supported Go, Java, Clojure, Node.js, and Python client library are supported. gRPC APIs can be triggered by any programming languages which support gRPC. REST API is also supported. Vald supports similarity searching. Related image search Speech recognition Everything you can vectorize :) Vald is based on Kubernetes and Cloud-Native architecture, which means Vald is highly scalable. You can easily scale Vald by changing Vald's configuration. Vald uses the fastest ANN Algorithm to search neighbors by default, but users can switch to another vector searching engine in Vald to support the best performance for your use case. Also, Vald supports auto-healing, to reduce running and maintenance costs. Vald implements the backup mechanism to support disaster recovery. Whenever one of the Vald Agent instances is down, the new Vald Agent instance will be created automatically and the data will be recovered automatically. Vald implements its custom resource and custom controller to integrate with Kubernetes. You can take all the benefits from Kubernetes. Please refer to the for more details about the architecture and how each component in Vald works together. Please refer to to try Vald :)
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: reposaur.md

title: Reposaur software: github labels: category: security type: poweredbyopa tutorials: https://docs.reposaur.com/guides/writing-your-first-policy code: https://github.com/reposaur/reposaur inventors: reposaur Audit, verify and report on development platforms (GitHub and others) easily with pre-defined and/or custom policies.
Project: StarRocks (App Definition and Development / Database)
File: Scale_up_down.md

displayed_sidebar: "English" This topic describes how to scale in and out the node of StarRocks. StarRocks has two types of FE nodes: Follower and Observer. Followers are involved in election voting and writing. Observers are only used to synchronize logs and extend read performance. The number of follower FEs (including leader) must be odd, and it is recommended to deploy 3 of them to form a High Availability (HA) mode. When the FE is in high availability deployment (1 leader, 2 followers), it is recommended to add Observer FEs for better read performance. Typically one FE node can work with 10-20 BE nodes. It is recommended that the total number of FE nodes be less than 10. Three is sufficient in most cases. After deploying the FE node and starting the service, run the following command to scale FE out. ~~~sql alter system add follower "fehost:editlog_port"; alter system add observer "fehost:editlog_port"; ~~~ FE scale-in is similar to the scale-out. Run the following command to scale FE in. ~~~sql alter system drop follower "fehost:editlog_port"; alter system drop observer "fehost:editlog_port"; ~~~ After the expansion and contraction, you can view the node information by running `show proc '/frontends';`. After BE is scaled in or out, StarRocks will automatically perform load-balancing without affecting the overall performance. Run the following command to scale BE out. ~~~sql alter system add backend 'behost:beheartbeatserviceport'; ~~~ Run the following command to check the BE status. ~~~sql show proc '/backends'; ~~~ There are two ways to scale in a BE node `DROP` and `DECOMMISSION`. `DROP` will delete the BE node immediately, and the lost duplicates will be made up by FE scheduling. `DECOMMISSION` will make sure the duplicates are made up first, and then drop the BE node. `DECOMMISSION` is a bit more friendly and is recommended for BE scale-in. The commands of both methods are similar: `alter system decommission backend "behost:beheartbeatserviceport";` `alter system drop backend "behost:beheartbeatserviceport";` Drop backend is a dangerous operation, so you need to confirm it twice before executing it `alter system drop backend "behost:beheartbeatserviceport";`
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: what-is-backstage.md

id: what-is-backstage title: What is Backstage? description: Backstage is an open source framework for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure is an open source framework for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly without compromising autonomy. Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end. <iframe width="672" height="378" src="https://www.youtube.com/embed/85TQEpNCaU0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> Out of the box, Backstage includes: for managing all your software (microservices, libraries, data pipelines, websites, ML models, etc.) for quickly spinning up new projects and standardizing your tooling with your organizations best practices for making it easy to create, maintain, find, and use technical documentation, using a "docs like code" approach Plus, a growing ecosystem of that further expand Backstages customizability and functionality Backstage is a CNCF Incubation project after graduating from Sandbox. Read the announcement . <img src="https://backstage.io/img/cncf-white.svg" alt="CNCF logo" width="400" /> For engineering managers, it allows you to maintain standards and best practices across the organization, and can help you manage your whole tech ecosystem, from migrations to test certification. For end users (developers), it makes it fast and simple to build software components in a standardized way, and it provides a central place to manage all projects and documentation. For platform engineers, it enables extensibility and scalability by letting you easily integrate new tools and services (via plugins), as well as extending the functionality of existing ones. For everyone, its a single, consistent experience that ties all your infrastructure tooling, resources, standards, owners, contributors, and administrators together in one place. If you have questions or want support, please join our .
Project: Kubefirst (Provisioning / Automation & Configuration)
File: README.md

<!-- markdownlint-disable MD041 --> <p align="center"> <picture> <source media="(prefers-color-scheme: dark)" srcset="images/kubefirst-light.svg" alt="Kubefirst Logo"> <img alt="" src="images/kubefirst.svg"> </picture> </p> <p align="center"> GitOps Infrastructure & Application Delivery Platform </p> <p align="center"> <a href="https://docs.kubefirst.io/">Install</a>&nbsp;|&nbsp; <a href="https://twitter.com/kubefirst">Twitter</a>&nbsp;|&nbsp; <a href="https://www.linkedin.com/company/kubefirst">LinkedIn</a>&nbsp;|&nbsp; <a href="https://join.slack.com/t/kubefirst/shared_invite/zt-r0r9cfts-OVnH0ooELDLm9n9p2aU7fw">Slack</a>&nbsp;|&nbsp; <a href="https://kubeshop.io/blog-projects/kubefirst">Blog</a> </p> <p align="center"> <a href="https://github.com/kubefirst/kubefirst/releases"><img title="Release" src="https://img.shields.io/github/v/release/kubefirst/kubefirst"/></a> <!-- <a href=""><img title="Docker builds" src="https://img.shields.io/docker/automated/kubeshop/tracetest"/></a> --> <a href="https://github.com/kubefirst/kubefirst/releases"><img title="Release date" src="https://img.shields.io/github/release-date/kubefirst/kubefirst"/></a> </p> The Kubefirst CLI creates instant GitOps platforms that integrate some of the best tools in cloud native from scratch in minutes. Each of our platforms have install guides that detail the prerequesites, commands, and resulting platform that you'll receive. In beta: Akamai (docs coming soon) `kubefirst beta akamai create --help` K3s (docs coming soon) `kubefirst beta k3s create --help` <https://docs.kubefirst.io> Feed K-Ray a GitHub star above to bookmark our project and keep K-Ray happy!! ](https://star-history.com/#kubefirst/kubefirst&Date)
Project: ShardingSphere (App Definition and Development / Database)
File: responsibilities.en.md

+++ title = "Responsibilities & Routine" weight = 1 chapter = true +++ Develop new features; Refactor codes; Review pull requests reliably and in time; Consider and accept feature requests; Answer questions; Update documentation and example; Improve processes and tools; Check whether works or not periodically; Guide new contributors join community. Check the list of pull requests and issues to be processed in the community on a daily basis. Including label issue, reply issue, close issue; Assign issue to the appropriate committer, namely assignee; After a committer is assigned with an issue, the following work is required: Estimate whether it is a long-term issue. If it is, please label it as pending; Add issue labels, such as bug, enhancement, discussion, etc; Add milestone. Pull request that committer submits needs to add labels and milestone based on the type and release period. When committer reviewed and approved any pull request, committer could squash and merge to master. If there is any question you concerned about this pull request, please reply directly to the related issue.
Project: EJBCA Community (Provisioning / Security & Compliance)
File: bug-report.md

name: Bug report about: Create a report to help us improve title: "[BUG]" labels: bug assignees: '' Describe the Bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected Behavior A clear and concise description of what you expected to happen. Screenshots and Logs If applicable, add screenshots and logs to help explain your problem. Product Deployment Please complete the following information: Deployment format: [e.g. software, container] Version [e.g. 8.0.0] Desktop Please complete the following information: OS: [e.g. iOS] Browser [e.g. chrome, safari] Version [e.g. 22] Additional Context Add any other context about the problem here.
Project: KusionStack (Provisioning / Automation & Configuration)
File: kusion_apply.md

Apply the operational intent of various resources to multiple runtimes Apply a series of resource changes within the stack. Create, update or delete resources according to the operational intent within a stack. By default, Kusion will generate an execution preview and prompt for your approval before performing any actions. You can review the preview details and make a decision to proceed with the actions or abort them. ``` kusion apply [flags] ``` ``` kusion apply -w /path/to/workdir kusion apply -D name=test -D age=18 kusion apply --intent-file intent.yaml kusion apply --intent-file intent.yaml kusion apply --yes kusion apply --no-style=true ``` ``` -a, --all --detail Automatically show all preview details, combined use with flag --detail -D, --argument stringToString Specify the top-level argument (default []) -C, --backend-config strings backend-config config state storage backend --backend-type string backend-type specify state storage backend -d, --detail Automatically show preview details with interactive options (default true) --dry-run Preview the execution effect (always successful) without actually applying the changes -h, --help help for apply --ignore-fields strings Ignore differences of target fields --intent-file string Specify the intent file path as input, and the intent file must be located in the working directory or its subdirectories --no-style no-style sets to RawOutput mode and disables all of styling --operator string Specify the operator -o, --output string Specify the output format -Y, --setting strings Specify the command line setting files --watch After creating/updating/deleting the requested object, watch for changes -w, --workdir string Specify the work directory -y, --yes Automatically approve and perform the update after previewing it ``` ``` --profile string Name of profile to capture. One of (none|cpu|heap|goroutine|threadcreate|block|mutex) (default "none") --profile-output string Name of the file to write the profile to (default "profile.pprof") ``` - Kusion is the Platform Orchestrator of Internal Developer Platform