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

Delete node of a YugabyteDB Anywhere on-premises provider Delete nodes of a YugabyteDB Anywhere on-premises provider ``` yba provider onprem node remove [flags] ``` ``` --ip string [Required] IP address of the node instance. -f, --force [Optional] Bypass the prompt for non-interactive usage. -h, --help help for remove ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the provider for the action. Required for create, delete, describe, instance-types and nodes. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage YugabyteDB Anywhere onprem node instances
Project: Distribution (Provisioning / Container Registry)
File: osx-setup-guide.md

description: Explains how to run a registry on macOS keywords: registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced title: macOS setup guide This is useful if you intend to run a registry server natively on macOS. You can start a VM on macOS, and deploy your registry normally as a container using Docker inside that VM. Using the method described here, you install and compile your own from the git repository and run it as an macOS agent. Production services operation on macOS is out of scope of this document. Be sure you understand well these aspects before considering going to production with this. If you know, safely skip to the next section. If you don't, the TLDR is: ```console $ bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer) $ source ~/.gvm/scripts/gvm $ gvm install go1.4.2 $ gvm use go1.4.2 ``` If you want to understand, you should read . ```console $ mkdir -p $GOPATH/src/github.com/distribution $ git clone https://github.com/distribution/distribution.git $GOPATH/src/github.com/distribution/distribution $ cd $GOPATH/src/github.com/distribution/distribution ``` ```console $ GOPATH=$(PWD)/Godeps/_workspace:$GOPATH make binaries $ sudo mkdir -p /usr/local/libexec $ sudo cp bin/registry /usr/local/libexec/registry ``` Copy the registry configuration file in place: ```console $ mkdir /Users/Shared/Registry $ cp docs/osx/config.yml /Users/Shared/Registry/config.yml ``` Copy the registry plist into place: ```console $ plutil -lint docs/recipes/osx/com.docker.registry.plist $ cp docs/recipes/osx/com.docker.registry.plist ~/Library/LaunchAgents/ $ chmod 644 ~/Library/LaunchAgents/com.docker.registry.plist ``` Start the registry: ```console $ launchctl load ~/Library/LaunchAgents/com.docker.registry.plist ``` ```console $ launchctl stop com.docker.registry $ launchctl start com.docker.registry ``` ```console $ launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist ```
Project: YugabyteDB (App Definition and Development / Database)
File: dml_values.md

title: VALUES statement [YSQL] headerTitle: VALUES linkTitle: VALUES description: Use the VALUES statement to generate a row set specified as an explicitly written set of explictly written tuples. menu: v2.18: identifier: dml_values parent: statements type: docs Use the `VALUES` statement to generate a row set specified as an explicitly written set of explicitly written tuples. {{%ebnf%}} values, expression_list {{%/ebnf%}} A comma-separated list of parenthesized expression lists. The degenerate form is just a single constant, thus: ```plpgsql values ('dog'::text); ``` You should see the following output: ```output column1 dog ``` The result has as many columns named "column1", "column2", ... "columnN" as there are expressions in the expression list, thus: ```plpgsql values (1::int, '2019-06-25 12:05:30'::timestamp, 'dog'::text), (2::int, '2020-07-30 13:10:45'::timestamp, 'cat'::text); ``` This is the result: ``` column1 | column2 | column3 ++ 1 | 2019-06-25 12:05:30 | dog 2 | 2020-07-30 13:10:45 | cat ``` If an expression is written without a typecast, then its data type is inferred. For example, 'dog' is inferred to have datatype `text` and 4.2 is inferred to have data type `numeric`. Each successive parenthesized expression list must specify the same number of expressions with the same data types. Try this counter example: ```plpgsql values (1::int, '2019-06-25 12:05:30'::timestamp, 'dog'::text), (2::int, '2020-07-30 13:10:45'::timestamp, 'cat'::text, 42::int); ``` It causes this error: ``` 42601: VALUES lists must all be the same length ``` And try this counter example: ```plpgsql values (1::int), ('x'::text); ``` It causes this error: ``` 42804: VALUES types integer and text cannot be matched ``` These clauses have the same semantics when they are used in a `VALUES` statement as they do when they are used in a `SELECT` statement. A `VALUES` statement can be used as a subquery by surrounding it with parentheses, and giving this an alias, in just the same way that a `SELECT` statement can be so surrounded and so used. Try this first: ```plpgsql select chr(v) as c from ( select * from generate_series(97, 101) ) as t(v); ``` This is the result: ``` c a b c d e ``` Now use a `VALUES` statement (on line #2) within the parentheses instead of the `SELECT` statement: ```plpgsql select chr(v) as c from ( values (100), (111), (103) ) as t(v); ``` This is the result: ``` c d o g ```
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: operator-sdk_alpha_config-3alpha-to-3.md

title: "operator-sdk alpha config-3alpha-to-3" Convert your PROJECT config file from version 3-alpha to 3 Your PROJECT file contains config data specified by some version. This version is not a kubernetes-style version. In general, alpha and beta config versions are unstable and support for them is dropped once a stable version is released. The 3-alpha version has recently become stable (3), and therefore is no longer supported by operator-sdk v1.5+. This command is intended to migrate 3-alpha PROJECT files to 3 with as few manual modifications required as possible. ``` operator-sdk alpha config-3alpha-to-3 [flags] ``` ``` -h, --help help for config-3alpha-to-3 ``` ``` --plugins strings plugin keys to be used for this subcommand execution --verbose Enable verbose logging ``` - Alpha-stage subcommands
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_global_address.md

+++ title = "googlecomputeglobal_address resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputeglobal_address" identifier = "inspec/resources/gcp/googlecomputeglobaladdress.md googlecomputeglobaladdress resource" parent = "inspec/resources/gcp" +++ A `googlecomputeglobal_address` is used to test a Google GlobalAddress resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputeglobal_address(project: 'chef-gcp-inspec', name: 'inspec-gcp-global-address') do it { should exist } its('ip_version') { should eq 'IPV6' } end describe googlecomputeglobal_address(project: 'chef-gcp-inspec', name: 'nonexistent') do it { should_not exist } end ``` Properties that can be accessed from the `googlecomputeglobal_address` resource: `address` : The static external IP address represented by this resource. `creation_timestamp` : Creation timestamp in RFC3339 text format. `description` : An optional description of this resource. `id` : The unique identifier for the resource. This identifier is defined by the server. `name` : Name of the resource. Provided by the client when the resource is created. The name must be 1-63 characters long, and comply with RFC1035. Specifically, the name must be 1-63 characters long and match the regular expression `?` which means the first character must be a lowercase letter, and all following characters must be a dash, lowercase letter, or digit, except the last character, which cannot be a dash. `labels` : (Beta only) Labels to apply to this address. A list of key->value pairs. `label_fingerprint` : (Beta only) The fingerprint used for optimistic locking of this resource. Used internally during updates. `ip_version` : The IP Version that will be used by this address. The default value is `IPV4`. Possible values: IPV4 IPV6 `region` : A reference to the region where the regional address resides. `prefix_length` : The prefix length of the IP range. If not present, it means the address field is a single IP address. This field is not applicable to addresses with addressType=EXTERNAL. `address_type` : The type of the address to reserve. EXTERNAL indicates public/external single IP address. INTERNAL indicates internal IP ranges belonging to some network. Possible values: EXTERNAL INTERNAL `purpose` : The purpose of the resource. For global internal addresses it can be VPCPEERING - for peer networks This should only be set when using an Internal address. Possible values: VPC_PEERING `network` : The URL of the network in which to reserve the IP range. The IP range must be in RFC1918 space. The network cannot be deleted if there are any reserved IP ranges referring to it. This should only be set when using an Internal address. Ensure the is enabled for the current project.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-kube-apply.1.md

% podman-kube-apply 1 podman-kube-apply - Apply Kubernetes YAML based on containers, pods, or volumes to a Kubernetes cluster podman kube apply [options] [container... | pod... | volume...] podman kube apply deploys a podman container, pod, or volume to a Kubernetes cluster. Use the `--file` option to deploy a Kubernetes YAML (v1 specification) to a Kubernetes cluster as well. Note that the Kubernetes YAML file can be used to run the deployment in Podman via podman-play-kube(1). The path to the CA cert file for the Kubernetes cluster. Usually the kubeconfig has the CA cert file data and `generate kube` automatically picks that up if it is available in the kubeconfig. If no CA cert file data is available, set this to `insecure` to bypass the certificate verification. Path to the kubernetes yaml file to deploy onto the kubernetes cluster. This file can be generated using the `podman kube generate` command. The input may be in the form of a yaml file, or stdin. For stdin, use `--file=-`. Path to the kubeconfig file to be used when deploying the generated kube yaml to the Kubernetes cluster. The environment variable `KUBECONFIG` can be used to set the path for the kubeconfig file as well. Note: A kubeconfig can have multiple cluster configurations, but `kube generate` always picks the first cluster configuration in the given kubeconfig. The namespace or project to deploy the workloads of the generated kube yaml to in the Kubernetes cluster. Used to create a service for the corresponding container or pod being deployed to the cluster. In particular, if the container or pod has portmap bindings, the service specification includes a NodePort declaration to expose the service. A random port is assigned by Podman in the service specification that is deployed to the cluster. Apply a podman volume and container to the "default" namespace in a Kubernetes cluster. ``` $ podman kube apply --kubeconfig /tmp/kubeconfig myvol vol-test-1 Deploying to cluster... Successfully deployed workloads to cluster! $ kubectl get pods NAME READY STATUS RESTARTS AGE vol-test-1-pod 1/1 Running 0 9m ``` Apply a Kubernetes YAML file to the "default" namespace in a Kubernetes cluster. ``` $ podman kube apply --kubeconfig /tmp/kubeconfig -f vol.yaml Deploying to cluster... Successfully deployed workloads to cluster! $ kubectl get pods NAME READY STATUS RESTARTS AGE vol-test-2-pod 1/1 Running 0 9m ``` Apply a Kubernetes YAML file to the "test1" namespace in a Kubernetes cluster. ``` $ podman kube apply --kubeconfig /tmp/kubeconfig --ns test1 vol-test-3 Deploying to cluster... Successfully deployed workloads to cluster! $ kubectl get pods --namespace test1 NAME READY STATUS RESTARTS AGE vol-test-3-pod 1/1 Running 0 9m ``` , , , , September 2022, Originally compiled by Urvashi Mohnani (umohnani at redhat dot com)
Project: Chef Infra (Provisioning / Automation & Configuration)
File: running_adhoc_builds.md

Buildkite ad hoc builds are a great way to ensure that complex changes or changes that impact package creation will build across all supported platforms. The testing of Chef Infra Client occurs at the PR level and the build level, each incrementally improving developer confidence in the safety of a change. Pull Request testing in GitHub is our first layer of defense but is far from perfect. It's optimized for speed and to work within the constraints of GitHub and public CI instances. This means this testing occurs against Ruby containers and no builds are created. Any change to build dependencies or configuration untested at the PR level. Build testing occurs post-merge and involves the creation of packages for the platforms we support and the execution of RSpec tests using those packages. Since these RSpec tests are performed within the packages, we test against the dependencies we ship to the customer. When making changes that impact the package you always want to validate the build process by running an ad hoc Buildkite build. Ad hoc builds take the same path as merged changes but without the need to merge code. Ad hoc Buildkite builds can be created against any branch in the `chef/chef` GitHub repository by Chef employees with access to the private Buildkite account. If you don't have access to this account or the ability to push branches to `chef/chef` ask in `#releng-support`. Buildkite pipelines for running ad hoc builds are automatically created for each branch configured in the Expeditor `config.yml` file. They follow a standard naming system: https://buildkite.com/chef/chef-chef-master-omnibus-adhoc/ https://buildkite.com/chef/chef-chef-chef-16-omnibus-adhoc/ Once in the ad hoc pipeline page, select "New Build" in the upper right hand corner. Then provide a message to display in the Buildkite UI, the commit, and branch name. Once your build completes you can download it from either Artifactory or via mixlib-install. Builds are available in Artifactory at http://artifactory.chef.co/ui/builds/chef Successful ad hoc builds are promoted to the unstable channel and can be downloaded using mixlib-install (part of Chef Workstation) `mixlib-install download chef -c unstable` Keep in mind this just downloads the last build so you may end up the wrong build if the ad hoc isn't the last build to promote to unstable.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.58.md

layout: release date: 2023-02-28 tag: v0.6.58 language: en Fix version bug in mesheryctl @Revolyssup (#7211) urgent fix: meshery crash due to formdata in RJSF @Abhishek-kumar09 (#7219) Feat/graphql ws @acald-creator (#7206) [bug] Fix Broken Dashboard @theBeginner86 (#7210) Meshmodel summary dark mode bug fixed @deepakdinesh1123 (#7073) [chore] Update relay-compiler to v14.1.0 @theBeginner86 (#7058) [bug] Fix Broken Dashboard @theBeginner86 (#7210) [chore] Update relay-compiler to v14.1.0 @theBeginner86 (#7058) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Revolyssup, @acald-creator, @deepakdinesh1123, @leecalcote, @theBeginner86 and l5io
Project: Meshery (Provisioning / Automation & Configuration)
File: ps-db.md

layout: integration title: Percona Server for MySQL subtitle: Meshery provides performance reports, including performance test results, node resource metrics etc. so that operators may easily understand the overhead of their service meshs control plane and data plane in context of the overhead incurred on nodes running within the cluster. In order to generate performance test reports of service meshes and their workloads, Meshery uses Grafana and/or Prometheus as visualization and metrics systems, respectively. This guide outlines the requirements necessary for Meshery to connect to these systems. The steps may vary depending upon the service mesh and its configuration. image: /assets/img/integrations/ps-db/icons/color/ps-db-color.svg permalink: extensibility/integrations/ps-db docURL: https://docs.meshery.io/extensibility/integrations/ps-db description: integrations-category: Database integrations-subcategory: App Definition and Development registrant: Artifact Hub components: name: percona-server-my-sql-backup colorIcon: assets/img/integrations/ps-db/components/percona-server-my-sql-backup/icons/color/percona-server-my-sql-backup-color.svg whiteIcon: assets/img/integrations/ps-db/components/percona-server-my-sql-backup/icons/white/percona-server-my-sql-backup-white.svg description: name: percona-server-my-sql-restore colorIcon: assets/img/integrations/ps-db/components/percona-server-my-sql-restore/icons/color/percona-server-my-sql-restore-color.svg whiteIcon: assets/img/integrations/ps-db/components/percona-server-my-sql-restore/icons/white/percona-server-my-sql-restore-white.svg description: name: percona-server-my-sql colorIcon: assets/img/integrations/ps-db/components/percona-server-my-sql/icons/color/percona-server-my-sql-color.svg whiteIcon: assets/img/integrations/ps-db/components/percona-server-my-sql/icons/white/percona-server-my-sql-white.svg description: featureList: [ "Native support for PromQL", "Create custom charts with your own Prometheus queries", "Keep charts in-sync with Mesherys panel viewer" ] howItWorks: "Meshery provides performance reports, including performance test results, node resource metrics etc. so that operators may easily understand the overhead of their service meshs control plane and data plane in context of the overhead incurred on nodes running within the cluster. In order to generate performance test reports of service meshes and their workloads, Meshery uses Grafana and/or Prometheus as visualization and metrics systems, respectively. This guide outlines the requirements necessary for Meshery to connect to these systems. The steps may vary depending upon the service mesh and its configuration." howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: SPIRE (Provisioning / Key Management)
File: plugin_agent_nodeattestor_azure_msi.md

Must be used in conjunction with the server-side azure_msi plugin The `azure_msi` plugin attests nodes running in Microsoft Azure that have Managed Service Identity (MSI) enabled. Agent nodes acquire a signed MSI token which is passed to the server. The server validates the signed MSI token and extracts the Tenant ID and Principal ID to form the agent SPIFFE ID. The SPIFFE ID has the form: ```xml spiffe://<trustdomain>/spire/agent/azuremsi/<tenantid>/<principalid> ``` The agent needs to be running in Azure, in a VM with MSI enabled, in order to use this method of node attestation. | Configuration | Description | Default | ||--|-| | `resource_id` | The resource ID (or audience) to request for the MSI token. The server will reject tokens with resource IDs it does not recognize | <https://management.azure.com/> | It is important to note that the resource ID MUST be for a well known Azure service, or an app ID for a registered app in Azure AD. Azure will not issue an MSI token for resources it does not know about. The resource ID that is chosen has security implications. If the server was compromised, the agent would be granting the compromised server access to whatever resource on behalf of the agent VM. If that is a concern for your deployment, you should register an application with Azure AD with a dummy URI that you can use as a resource instead to limit the scope of replay-ability. A sample configuration with the default resource ID (i.e. resource manager): ```hcl NodeAttestor "azure_msi" { plugin_data { } } ``` A sample configuration with a custom resource ID: ```hcl NodeAttestor "azure_msi" { plugin_data { resource_id = "http://example.org/app/" } } ```
Project: YugabyteDB (App Definition and Development / Database)
File: security.md

Security =============================================================================== Permissions Here's an overview of what users can do depending on the priviledge they have: | Action | Superuser | Owner | Masked Role | | : | :-: | :: | :: | | Create the extension | Yes | | | | Drop the extension | Yes | | | | Init the extension | Yes | | | | Reset the extension | Yes | | | | Configure the extension | Yes | | | | Put a mask upon a role | Yes | | | | Start dynamic masking | Yes | | | | Stop dynamic masking | Yes | | | | Create a table | Yes | Yes | | | Declare a masking rule | Yes | Yes | | | Insert, delete, update a row | Yes | Yes | | | Static Masking | Yes | Yes | | | Select the real data | Yes | Yes | | | Regular Dump | Yes | Yes | | | Anonymous Dump | Yes | Yes | | | Use the masking functions | Yes | Yes | Yes | | Select the masked data | Yes | Yes | Yes | | View the masking rules | Yes | Yes | Yes | Limit masking filters only to trusted schemas By default, the database owner can only write masking rules with functions that are located in the trusted schemas which are controlled by the superusers. Out of the box, only the `anon` schema is declared as trusted. This means that by defautt the functions from the `pg_catalog` cannot be used in masking rules. For more details, read the [Using pg_catalog functions] section. Security context of the functions Most of the functions of this extension are declared with the `SECURITY INVOKER` tag. This means that these functions are executed with the privileges of the user that calls them. This is an important restriction. This extension contains another few functions declared with the tag `SECURITY DEFINER`.
Project: StarRocks (App Definition and Development / Database)
File: DATE.md

displayed_sidebar: "English" Extracts the date part of a date or datetime expression. ```Haskell DATE date(DATETIME|DATE expr) ``` `expr`: the date or datetime expression. Returns a value of the DATE type. NULL is returned if the input is NULL or invalid. Example 1: Extract the date part of a datetime value. ```plaintext SELECT DATE("2017-12-31 11:20:59"); +--+ | date('2017-12-31 11:20:59') | +--+ | 2017-12-31 | +--+ 1 row in set (0.05 sec) ``` Example 2: Extract the date part of a date value. ```plaintext SELECT DATE('2017-12-31'); +--+ | date('2017-12-31') | +--+ | 2017-12-31 | +--+ 1 row in set (0.08 sec) ``` Example 3: Extract the date part of the current timestamp. ```plaintext SELECT DATE(current_timestamp()); ++ | date(current_timestamp()) | ++ | 2022-11-08 | ++ 1 row in set (0.05 sec) ```