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

Group the table by the values of the specified columns or expressions and the time window. If GROUP BY is present in the query, then when selecting columns (between `SELECT STREAM ... FROM`) you can only use the following constructs: Columns by which grouping is performed (they are included in the `GROUP BY` argument). Aggregate functions (see the next section). Columns by which no grouping is made can only be included as arguments for an aggregate function. Functions that output the start and end time of the current window (`HOPSTART` and `HOPEND`) Arbitrary calculations combining paragraphs 1-3. You can group by the result of calculating an arbitrary expression from the source columns. In this case, to access the result of this expression, we recommend you to assign a name to it using `AS`, see the second example. Aggregate functions automatically skip `NULL` in their arguments. Among the columns by which grouping is performed, make sure to use the `HOP` construct to define the time window for grouping. ```yql HOP(time_extractor, hop, interval, delay) ``` The implemented version of the time window is called the hopping window. This is a window that moves forward in discrete intervals (the `hop` parameter). The total duration of the window is set by the `interval` parameter. To determine the time of each input event, the `time_extractor` parameter is used. This expression depends only on the input values of the stream's columns and must have the `Timestamp` type. It indicates where exactly to get the time value from input events. In each stream defined by the values of all the grouping columns, the window moves forward independently of other streams. Advancement of the window is totally dependent on the latest event of the stream. Since records in streams get somewhat mixed in time, the `delay` parameter has been added so you can delay the closing of the window by a specified period. Events arriving before the current window are ignored. The `interval` and `delay` parameters must be multiples of the `hop` parameter. Non-multiple intervals will be rounded down. To set `hop`, `interval` and `delay`, use a string expression compliant with . This is the format that is used to construct the built-in type `Interval` . Functions with omitted `HOPSTART` and `HOPEND` parameters, return a value of the `Timestamp` type and correspond to the start and end of the current window. The tumbling window known in other systems is a special case of a hopping window when `interval` == `hop`. Examples: ```yql SELECT STREAM key, COUNT(*) FROM my_stream GROUP BY HOP(CAST(subkey AS Timestamp), "PT10S", "PT1M", "PT30S"), key; -- hop = 10 seconds -- interval = 1 minute -- delay = 30 seconds ``` ```yql SELECT STREAM double_key, HOP_END() as time, COUNT(*) as count FROM my_stream GROUP BY key + key AS double_key, HOP(ts, "PT1M", "PT1M", "PT1M"); ```
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: about_services.md

+++ title = "About Services" aliases = ["/habitat/using-habitat/"] date = 2020-10-26T18:37:38-07:00 draft = false gh_repo = "habitat" [menu] [menu.habitat] title = "About Services" identifier = "habitat/services/About Services" parent = "habitat/services" weight = 10 +++ A service is a Chef Habitat package running under a Chef Habitat Supervisor. A service group is a set of one or more running services with a shared configuration and topology. If a service is started without explicitly naming the group, it is assigned to the default group for the name of that package. For example: `redis.default` `postgres.financialdb` (possibly running in a cluster) `postgres.userdb` (possibly running in a cluster) Chef Habitat allows you to define the topology of your service groups, which bakes in certain behaviors. This is the default topology, useful for services inside a group that are completely independent from one another. Note that this still means they can share the same configuration. This topology allows a distributed application running on at least three Chef Habitat nodes to use a leader/follower configuration. Leaders are elected with Chef Habitat's leader election algorithm, and followers are restarted to reflect a configuration that follows the new leader. Subsequent elections due to leader failure will update both leader and follower configuration data. You can read more about the internals behind the elections in our [advanced developer documentation]({{< relref "sup_crypto#leader-election" >}}).
Project: KICS (Provisioning / Security & Compliance)
File: 7dbba512-e244-42dc-98bb-422339827967.md

title: CloudWatch Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 7dbba512-e244-42dc-98bb-422339827967 Query name: CloudWatch Logging Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Check if CloudWatch logging is disabled for Route53 hosted zones<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 10" resource "awsroute53zone" "noquerylog" { name = "example.com" } resource "awsroute53zone" "loggroupmismatch" { name = "example.com" } resource "awsroute53querylog" "loggroup_mismatch" { cloudwatchloggrouparn = awscloudwatchloggroup.awsroute53log_mismatch.arn } ``` ```tf title="Negative test num. 1 - tf file" resource "awsroute53zone" "example_com" { name = "example.com" } resource "awsroute53querylog" "examplecom" { dependson = [awscloudwatchlogresource_policy.route53-query-logging-policy] cloudwatchloggrouparn = awscloudwatchloggroup.awsroute53example_com.arn zoneid = awsroute53zone.examplecom.zone_id } ```
Project: ClickHouse (App Definition and Development / Database)
File: v23.8.8.20-lts.md

sidebar_position: 1 sidebar_label: 2023 Backported in : Allow backup of materialized view with dropped inner table instead of failing the backup. (). Backported in : There was a potential vulnerability in previous ClickHouse versions: if a user has connected and unsuccessfully tried to authenticate with the "interserver secret" method, the server didn't terminate the connection immediately but continued to receive and ignore the leftover packets from the client. While these packets are ignored, they are still parsed, and if they use a compression method with another known vulnerability, it will lead to exploitation of it without authentication. This issue was found with by https://twitter.com/malacupa. (). Backported in : There was an attempt to have the proper listing in , but the fix itself was in the wrong place, so it's still broken. See an . (). Fix ON CLUSTER queries without database on initial node (). Fix buffer overflow in Gorilla codec (). Close interserver connection on any exception before authentication (). Fix pygithub (). Avoid dependencies with no fixed versions (). Tiny improvement security ().
Project: CyberArk Conjur (Provisioning / Key Management)
File: authn_class_rules.md

Each authenticator must conform to the following rules: Authenticator module name must to start with `Authn` prefix Authenticator module must have a class named `Authenticator` `Authenticator` class must have `valid?` method All rules together define authenticator appearance in `installed` authenticators of the `authenticators` rest call. `valid?` is an interface method that's invoked duding The general authentication flow does not suite needs of all existing authenticators from both flow and authentication parameters view. Today it's often solved by adding degenerate `valid?` method to an `Authenticator` class. It makes code less readable and can cause . A recently introduced `authn-jwt` authenticator does not appear in `installed` authenticators of the `authenticators` rest call. It has its own authentication flow hence it has no `valid?` method. The method will throw . Also see the . proc: less intrusive solution cons: make the class code less readable may lead to unexpected behaviour and bugs Make appropriate changes in `Authentication::AuthenticatorClass` proc: makes an Authenticator contract more clear reduces complexity of future authenticators cons: makes contract weaker? Actually the reflection rules are looking for the first level class in the module. Ruby prioritizes classes with respective file name, means if there are multiple files with the same class definition `MyClass` for example ruby will "choose" the class from `myclass.rb` file. In our use-case all `Authenticator` classes are in `authenticator.rb` files and it's highly unlikely that we somehow will break this convention. In any case it will behave the same with or without `valid?` method rule. From my perspective this approach does not worth ROI at the moment and should be taken as a part of core-authenticators separation if occur.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: from.md

Overrides the first `FROM` instruction within the Containerfile. If there are multiple FROM instructions in a Containerfile, only the first is changed. With the remote podman client, not all container transports work as expected. For example, oci-archive:/x.tar references /x.tar on the remote machine instead of on the client. When using podman remote clients it is best to restrict use to containers-storage, and docker:// transports.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.38.md

layout: release date: 2024-03-25 tag: v0.7.38 Bump express from 4.17.3 to 4.19.2 in /install/docker-extension/ui @dependabot (#10618) feat: Relationship between Workspace and other aws-prometheusservice-controller components @RipulHandoo (#10493) Downgrade to MeshKit v0.7.19 @leecalcote (#10614) Update pattern API to support visibility change @Yashsharma1911 (#10612) fix edge annotation relationship @MUzairS15 (#10609) Create hierarchical_parent.json @MUzairS15 (#10607) Create edge_annotation.json @MUzairS15 (#10608) consolidate mesheryctl app into pattern @RipulHandoo (#10590) Bump express from 4.18.2 to 4.19.2 in /ui @dependabot (#10617) Bump react-dom from 17.0.2 to 18.2.0 in /ui @dependabot (#10466) Bump express from 4.18.2 to 4.19.2 in /ui @dependabot (#10617) Bump github.com/gorilla/websocket from 1.5.0 to 1.5.1 @dependabot (#10471) Bump react-dom from 17.0.2 to 18.2.0 in /ui @dependabot (#10466) Upgrade GitHub Action dorny/paths-filter@v3 @leecalcote (#10613) Upgrade to MeshKit v0.7.20 @leecalcote (#10606) consolidate mesheryctl app into pattern @RipulHandoo (#10590) Upgrade GitHub Action dorny/paths-filter@v3 @leecalcote (#10613) Consolidate Tasks with Guides @leecalcote (#10610) Thank you to our contributors for making this release possible: @MUzairS15, @RipulHandoo, @Yashsharma1911, @dependabot, @dependabot[bot] and @leecalcote
Project: YDB (App Definition and Development / Database)
File: ABSEIL_ISSUE_TEMPLATE.md

Please submit a new Abseil Issue using the template below: -- -- [Provide the background information that is required in order to evaluate the proposed API changes. No controversial claims should be made here. If there are design constraints that need to be considered, they should be presented here along with justification for those constraints. Linking to other docs is good, but please keep the pertinent information as self contained as possible in this section.] [Please clearly describe the API change(s) being proposed. If multiple changes, please keep them clearly distinguished. When possible, use example code snippets to illustrate before-after API usages. List pros-n-cons. Highlight the main questions that you want to be answered. Given the Abseil project compatibility requirements, describe why the API change is safe.]
Project: SPIFFE (Provisioning / Key Management)
File: ED_WARNICKE.md

I am honored to nominate Ed Warnicke for the SPIFFE Steering Committee. Ed is a long time user of SPIFFE/SPIRE, integrating it as a core component in Network Service Mesh. Through this experience, Ed has provided thoughtful feedback with a focus on useability and utility. For example, Ed is currently championing the design of SPIFFE ID Templating for Kubernetes workloads as seen in https://github.com/spiffe/spire/issues/2280 which will cover an important Kubernetes usability gap. The SPIFFE community would greatly benefit from Eds extensive open source governance and deep tech experience. Here is a brief bio: Ed Warnicke is a Distinguished Engineer at Cisco Systems. He has been working for over two decades in many areas of networking and Open Source. Ed is currently a FD.io TSC Member, and a founder of and active contributor to the Network Service Mesh and GitBOM projects. Ed has a masters in Physics (String Theory) from Rutgers University. Among other noteworthy activities, Warnicke was the FD.io TSC chair for six year, on the TAC at LFN for four years and is currently on the TAC at LFPH. He is a founding TSC member at OpenDaylight, is consistently in the top 70 individuals (#62 currently) on devstat for most PRs opened on CNCF projects, and is formerly a Wireshark maintainer. Ed answered the following questions in support of his nomination. What makes you a good fit for the SPIFFE Steering Committee? Good Steering Committees bring multiple perspectives that enhance their communities. The perspectives I bring are: A long time user of Spiffe in an Open Source project ( project at CNCF). Who has pushed the edges in using Spiffe (Federation, Transitive Identity, etc) A very experienced member of Open Source Steering Committees (founding TSC Member at OpenDaylight, long time TSC Chair at FD.io, LFPH TAC member, CNCF TAG-Network co-chair. I've seen enough to see some of the things that work and don't, and also so much as to know there is no single right answer and communities needs and personalities vary. Who still writes a lot of code (currently #62 out of ~20k CNCF contributors on ) Is very interested in ensuring Spiffe/Spire has excellent usability (see for one example). What aspects of SSC participation are you most excited about? I'm very interested in bringing my long deep background in Steering committees to bear. I'm also very interested in continuing to engage on issues of usability. That which is hard to use, doesn't get used, or is circumvented. Security requires usability. GitHub Handle: edwarnicke Email Address: hagbard@gmail.com LinkedIn Profile: https://www.linkedin.com/in/edwarnicke/ Current Affiliation: Cisco
Project: Meshery (Provisioning / Automation & Configuration)
File: containerd.md

layout: integration title: Containerd subtitle: Collaborative and visual infrastructure as code for Containerd image: /assets/img/integrations/containerd/icons/color/containerd-color.svg permalink: extensibility/integrations/containerd docURL: https://docs.meshery.io/extensibility/integrations/containerd description: integrations-category: Runtime integrations-subcategory: Container Runtime registrant: Artifact Hub components: featureList: [ "Implements a chunk-based content-addressable filesystem on top of a called RAFS (Registry Acceleration File System) format.", "Improves the current OCI image specification.", "Supports lazy pulling feature." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: KICS (Provisioning / Security & Compliance)
File: 3360c01e-c8c0-4812-96a2-a6329b9b7f9f.md

title: Role Binding To Default Service Account hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 3360c01e-c8c0-4812-96a2-a6329b9b7f9f Query name: Role Binding To Default Service Account Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Defaults URL: No role nor cluster role should bind to a default service account<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "kubernetesrolebinding" "example" { metadata { name = "terraform-example" namespace = "default" } role_ref { api_group = "rbac.authorization.k8s.io" kind = "Role" name = "admin" } subject { kind = "User" name = "admin" api_group = "rbac.authorization.k8s.io" } subject { kind = "ServiceAccount" name = "default" namespace = "kube-system" } subject { kind = "Group" name = "system:masters" api_group = "rbac.authorization.k8s.io" } } ``` ```tf title="Negative test num. 1 - tf file" resource "kubernetesrolebinding" "example2" { metadata { name = "terraform-example" namespace = "default" } role_ref { api_group = "rbac.authorization.k8s.io" kind = "Role" name = "admin" } subject { kind = "User" name = "admin" api_group = "rbac.authorization.k8s.io" } subject { kind = "ServiceAccount" name = "serviceExample" namespace = "kube-system" } subject { kind = "Group" name = "system:masters" api_group = "rbac.authorization.k8s.io" } } ```
Project: Portus (Provisioning / Container Registry)
File: issue_template.md

Check out the `CONTRIBUTING.md` file for some considerations before submitting a new issue. First I did this... Then that... And this happened! Expected behavior: I expected this to happen! Actual behavior: But this happened... Providing logs of the moment when the issue has happened would also be useful. If you are in production, you might want to set the `PORTUSLOGLEVEL` to `debug` to get a more verbose log. Deployment method: how have you deployed Portus? Are you using one of the as a base? If possible, could you paste your configuration? (don't forget to strip passwords or other sensitive data!) Configuration: You can get this information like this: In bare metal execute: `bundle exec rake portus:info`. In a container: Using the development `docker-compose.yml` file: `docker exec -it <container-id> bundle exec rake portus:info`. Using the : `docker exec -it <container-id> portusctl exec rake portus:info`. ```yml CONFIG HERE ``` Portus version: with commit if possible. You can get this info too with the above commands.
Project: YugabyteDB (App Definition and Development / Database)
File: pitr.md

title: Point-in-time recovery in YugabyteDB Anywhere headerTitle: Point-in-time recovery linkTitle: Point-in-time recovery description: Using Point-in-time recovery in YugabyteDB Anywhere headContent: Restore to a point in time menu: v2.18_yugabyte-platform: parent: back-up-restore-universes identifier: pitr weight: 50 type: docs To prevent data loss, YugabyteDB Anywhere supports (PITR) of the universe data. {{< note title="Note" >}} You must initiate and manage PITR using the YugabyteDB Anywhere UI. If you use the yb-admin CLI to make changes to the PITR configuration of a universe managed by YugabyteDB Anywhere, including creating schedules and snapshots, your changes are not reflected in YugabyteDB Anywhere. {{< /note >}} You can create a PITR configuration as follows: Navigate to Universes. Select the name of the universe for which you want to use PITR. Select the Backups tab, and then select Point-in-time Recovery to view a list of the databases and keyspaces already enabled for PITR, if any, as per the following illustration: If there are currently no databases or keyspaces enabled for PITR, a message is displayed. Click Enable Point-in-time Recovery to open the dialog shown in the following illustration: Complete the Enable Point-in-time Recovery dialog by selecting YSQL or YCQL as the API type, then selecting the database or keyspace for which to enable PITR, and then selecting the data snapshot retention period. Click Enable. The database or keyspace is now added to the Databases/Keyspaces with Point-In-Time Recovery Enabled list. You can recover a snapshot to a specific point in time as follows: Navigate to Point-in-time Recovery. Find the database or keyspace whose snapshot you want to recover, click the three dots (...) to display its actions, and select Recover to a Point in Time. In the Recover dbname to a point in time dialog shown in the following illustration, specify the recovery time parameters that fall within your predefined retention period: Click Recover. You can disable PITR as follows: Navigate to Point-in-time Recovery. Find the database or keyspace for which you to disable PITR, click the three dots (...) to display its actions, and then select Disable Point-in-Time Recovery. Use the dialog shown in the following illustration to confirm that your intention is to disable PITR for the database or keyspace:
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_reset_key.md

title: "Command - devspace reset key" sidebar_label: devspace reset key Resets a cluster key ``` devspace reset key [flags] ``` ``` Resets a key for a given cluster. Useful if the key cannot be obtained anymore. Needs cluster access scope Examples: devspace reset key my-cluster ``` ``` -h, --help help for key --provider string The cloud provider to use ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile string The devspace profile to use (if there is any) --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) ```
Project: KICS (Provisioning / Security & Compliance)
File: 1ee0f202-31da-49ba-bbce-04a989912e4b.md

title: Disk Encryption Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1ee0f202-31da-49ba-bbce-04a989912e4b Query name: Disk Encryption Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: Disks should have encryption enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "tencentcloudcbsstorage" "encrytion_positive1" { storage_name = "cbs-test" storagetype = "CLOUDSSD" storage_size = 100 availability_zone = "ap-guangzhou-3" tags = { test = "tf" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="6" resource "tencentcloudcbsstorage" "encrytion_positive2" { storage_name = "cbs-test" storagetype = "CLOUDSSD" storage_size = 100 availability_zone = "ap-guangzhou-3" encrypt = false tags = { test = "tf" } } ``` ```tf title="Negative test num. 1 - tf file" resource "tencentcloudcbsstorage" "encrytion_negative1" { storage_name = "cbs-test" storagetype = "CLOUDSSD" storage_size = 100 availability_zone = "ap-guangzhou-3" encrypt = true tags = { test = "tf" } } ```