cwielenb/CNCF-Dataset huggingface dataset:
Project: CDK for Kubernetes (CDK8s) (Provisioning / Automation & Configuration)
File: migrating-from-1.x.md

This page describes the difference between versions `1.x` and `2.x` of the cdk8s toolchain, as well as instructions on how to migrate from one to the other. Version `1.x` of the cdk8s toolchain will be deprecated on 01/01/2023. After which, it will only receive critical bug fixes and security patches, but there will be no active development on it. We strongly recommend migrating to `2.x` using the instructions stated below. Version `2.x` of the core library is identical to version `1.x` from an API perspective. The only difference is in the dependency they declare on the `constructs` library. This also means that the documentation and code snippets presented throughout the site is compatible with `1.x` as well, in case you'd still like to use it. !!! info See for reasoning behind this change. Following are instructions on what changes should be performed to use version `2.x`: === "TypeScript" In `package.json`, define: ```json "dependencies": { "cdk8s": "^2.2.87", "constructs": "^10.1.12" } ``` === "Java" In `pom.xml`, define: ```xml <dependencies> <dependency> <groupId>org.cdk8s</groupId> <artifactId>cdk8s</artifactId> <version>[2.2.86,3.0]</version> </dependency> <dependency> <groupId>software.constructs</groupId> <artifactId>constructs</artifactId> <version>[10.1.12,11.0.0]</version> </dependency> </dependencies> ``` === "Python" In `Pipfile`, define: ```console [packages] constructs = "~=10.1.12" cdk8s = "~=2.2.87" ``` === "Go" In `go.mod`, define: ```go require ( github.com/aws/constructs-go/constructs/v10 v10.1.12 github.com/cdk8s-team/cdk8s-core-go/cdk8s/v2 v2.2.87 ) ``` Since major versions are encoded in go import statements, in your source code, change to: ```go import ( "github.com/aws/constructs-go/constructs/v10" "github.com/cdk8s-team/cdk8s-core-go/cdk8s/v2" ) ``` Version `2.x` of the is identical to version `1.x` from an API perspective. The only difference is in the project templates `cdk8s init` generates. CLI version `1.x / 2.x` will initiate projects utilizing version `1.x / 2.x` of the core library, accordingly. If you'd like to continue using version `1.x` of the CLI: === "Homebrew" version you'd like to install, and: ```console brew install cdk8s@1.<minor>.<patch> ``` === "npm" ```console npm install -g cdk8s-cli@^1 ``` === "yarn" ```console yarn global add cdk8s-cli@^1 ```
Project: ArangoDB (App Definition and Development / Database)
File: more_examples.md

<!-- Copyright 2018 Paul Fultz II Distributed under the Boost Software License, Version 1.0. (http://www.boost.org/LICENSE10.txt) --> More examples ============= As Boost.HigherOrderFunctions is a collection of generic utilities related to functions, there is many useful cases with the library, but a key point of many of these utilities is that they can solve these problems with much simpler constructs than whats traditionally been done with metaprogramming. Lets take look at some of the use cases for using Boost.HigherOrderFunctions. Initialization -- The will help initialize function objects at global scope, and will ensure that it is initialized at compile-time and (on platforms that support it) will have a unique address across translation units, thereby reducing executable bloat and potential ODR violations. In addition, allows initializing a lambda in the same manner. This allows for simple and compact function definitions when working with generic lambdas and function adaptors. Of course, the library can still be used without requiring global function objects for those who prefer to avoid them will still find the library useful. Projections -- Instead of writing the projection multiple times in algorithms: std::sort(std::begin(people), std::end(people), { return a.yearofbirth < b.yearofbirth; }); We can use the adaptor to project `yearofbirth` on the comparison operator: std::sort(std::begin(people), std::end(people), proj(&Person::yearofbirth, < )); Ordering evaluation of arguments -- When we write `f(foo(), bar())`, the standard does not guarantee the order in which the `foo()` and `bar()` arguments are evaluated. So with `apply_eval` we can order them from left-to-right: apply_eval(f, [&]{ return foo(); }, [&]{ return bar(); }); Extension methods -- Chaining many functions together, like what is done for range based libraries, can make things hard to read: auto r = transform( filter( numbers, { return x > 2; } ), { return x * x; } ); It would be nice to write this: auto r = numbers .filter( { return x > 2; }) .transform( { return x * x; }); The proposal for Unified Call Syntax(UFCS) would have allowed a function call of `x.f(y)` to become `f(x, y)`. However, this was rejected by the comittee. So instead pipable functions can be used to achieve extension methods. So it can be written like this: auto r = numbers | filter( { return x > 2; }) | transform( { return x * x; }); Now, if some users feel a little worried about overloading the bitwise or operator, pipable functions can also be used with like this: auto r = flow( filter( { return x > 2; }), transform( { return x * x; }) )(numbers); No fancy or confusing operating overloading and everything is still quite readable.
Project: KICS (Provisioning / Security & Compliance)
File: bca7cc4d-b3a4-4345-9461-eb69c68fcd26.md

title: RDS Using Default Port hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: bca7cc4d-b3a4-4345-9461-eb69c68fcd26 Query name: RDS Using Default Port Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Networking and Firewall URL: RDS should not use the default port (an attacker can easily guess the port). For engines related to Aurora, MariaDB or MySQL, the default port is 3306. PostgreSQL default port is 5432, Oracle default port is 1521 and SQL Server default port is 1433<br> ```tf title="Positive test num. 1 - tf file" hl_lines="11" resource "awsdbinstance" "positive1" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" parametergroupname = awselasticacheparameter_group.default.id skipfinalsnapshot = true port = 3306 } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="10" resource "awsdbinstance" "positive2" { allocated_storage = 10 engine = "postgres" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 5432 } ``` ```tf title="Positive test num. 3 - tf file" hl_lines="10" resource "awsdbinstance" "positive3" { allocated_storage = 10 engine = "oracle-ee" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 1521 } ``` <details><summary>Positive test num. 4 - tf file</summary> ```tf hl_lines="10" resource "awsdbinstance" "positive4" { allocated_storage = 10 engine = "sqlserver-ee" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 1433 } ``` </details> ```tf title="Negative test num. 1 - tf file" resource "awsdbinstance" "negative1" { allocated_storage = 10 engine = "mysql" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" parametergroupname = awselasticacheparameter_group.default.id skipfinalsnapshot = true port = 3307 } ``` ```tf title="Negative test num. 2 - tf file" resource "awsdbinstance" "negative2" { allocated_storage = 10 engine = "postgres" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 5433 } ``` ```tf title="Negative test num. 3 - tf file" resource "awsdbinstance" "negative3" { allocated_storage = 10 engine = "oracle-ee" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 1522 } ``` <details><summary>Negative test num. 4 - tf file</summary> ```tf resource "awsdbinstance" "negative4" { allocated_storage = 10 engine = "sqlserver-ee" engine_version = "5.7" instance_class = "db.t3.micro" name = "mydb" username = "foo" password = "foobarbaz" skipfinalsnapshot = true port = 1434 } ``` </details>
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_storage_bucket_objects.md

+++ title = "googlestoragebucket_objects resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlestoragebucket_objects" identifier = "inspec/resources/gcp/googlestoragebucketobjects.md googlestoragebucketobjects resource" parent = "inspec/resources/gcp" +++ A `googlestoragebucket_objects` is used to test a Google BucketObject resource ```ruby describe googlestoragebucket_objects(bucket: 'bucket-with-object') do its('object_names') { should include 'image1' } its('count') { should be <= 10 } end ``` ```ruby describe googlestoragebucket_objects(bucket: 'bucket-name') do its('count') { should be <= 100 } end ``` ```ruby describe googlestoragebucket_objects(bucket: 'bucket-name') do its('objectbuckets'){ should include 'myexpected_bucket' } end ``` ```ruby describe googlestoragebucket_objects(bucket: 'bucket-name') do its('objectnames'){ should include 'myexpected_object' } end ``` ```ruby describe googlestoragebucketobjects(bucket: 'bucket-name').where(objectcreated_time > Time.now - 606024) do it { should exist } end ``` Properties that can be accessed from the `googlestoragebucket_objects` resource: See the resource for more information. `object_buckets` : an array of `googlestoragebucket_object` bucket `objects` : an array of `googlestoragebucket_object` object `content_types` : an array of `googlestoragebucketobject` contenttype `crc32cs` : an array of `googlestoragebucket_object` crc32c `etags` : an array of `googlestoragebucket_object` etag `generations` : an array of `googlestoragebucket_object` generation `ids` : an array of `googlestoragebucket_object` id `md5_hashes` : an array of `googlestoragebucketobject` md5hash `media_links` : an array of `googlestoragebucketobject` medialink `metagenerations` : an array of `googlestoragebucket_object` metageneration `object_names` : an array of `googlestoragebucket_object` name `sizes` : an array of `googlestoragebucket_object` size `storage_classes` : an array of `googlestoragebucketobject` storageclass `objectcreatedtimes` : an array of `googlestoragebucketobject` timecreated `time_deleteds` : an array of `googlestoragebucketobject` timedeleted `timestorageclass_updateds` : an array of `googlestoragebucketobject` timestorageclassupdated `time_updateds` : an array of `googlestoragebucketobject` timeupdated This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: dynamic-log-level-settings.md

title: Dynamic Log Level Settings layout: documentation documentation: true We have added the ability to set log level settings for a running topology using the Storm UI and the Storm CLI. The log level settings apply the same way as you'd expect from log4j, as all we are doing is telling log4j to set the level of the logger you provide. If you set the log level of a parent logger, the children loggers start using that level (unless the children have a more restrictive level already). A timeout can optionally be provided (except for DEBUG mode, where its required in the UI), if workers should reset log levels automatically. This revert action is triggered using a polling mechanism (every 30 seconds, but this is configurable), so you should expect your timeouts to be the value you provided plus anywhere between 0 and the setting's value. Using the Storm UI In order to set a level, click on a running topology, and then click on Change Log Level in the Topology Actions section. Next, provide the logger name, select the level you expect (e.g. WARN), and a timeout in seconds (or 0 if not needed). Then click on Add. To clear the log level click on the Clear button. This reverts the log level back to what it was before you added the setting. The log level line will disappear from the UI. While there is a delay resetting log levels back, setting the log level in the first place is immediate (or as quickly as the message can travel from the UI/CLI to the workers by way of nimbus and zookeeper). Using the CLI Using the CLI, issue the command: `./bin/storm setloglevel [topology name] -l [logger name]=[LEVEL]:[TIMEOUT]` For example: `./bin/storm setloglevel my_topology -l ROOT=DEBUG:30` Sets the ROOT logger to DEBUG for 30 seconds. `./bin/storm setloglevel my_topology -r ROOT` Clears the ROOT logger dynamic log level, resetting it to its original value.
Project: KICS (Provisioning / Security & Compliance)
File: 05db341e-de7d-4972-a106-3e2bd5ee53e1.md

title: OSS Bucket Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 05db341e-de7d-4972-a106-3e2bd5ee53e1 Query name: OSS Bucket Logging Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: OSS Bucket should have logging enabled, for better visibility of resources and objects.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "alicloudossbucket" "bucket_logging2" { bucket = "bucket-170309-acl" acl = "public-read" } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="3" resource "alicloudossbucket" "bucket_logging1" { bucket = "bucket-170309-logging" logging_isenable = false logging { targetbucket = alicloudoss_bucket.bucket-target.id target_prefix = "log/" } } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudossbucket" "bucket_logging1" { bucket = "bucket-170309-logging" logging { targetbucket = alicloudoss_bucket.bucket-target.id target_prefix = "log/" } } ```
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.5.2.md

This hotfix release only updates the MongoDB State Store component to address a data serialization problem. An upgrade to this release is only recommended for users of this component. MongoDB State Store Component: Fixes an issue where actor reminders are broken when using the MongoDB State Store component as actor state store https://github.com/dapr/components-contrib/issues/1355. MongoDB State Store Component: Fixes an issue where array values could not be retrieved due to a serialization error. MongoDB State Store Component: Fixes an issue where MongoDB internal data types are returned in the State Store API response. Important: If upgrading to this version using Helm instead of the Dapr CLI, you will need to update the Subscription CRD prior to performing the Helm upgrade. ```cli kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/v1.4.4/charts/dapr/crds/subscription.yaml ``` When using MongoDB as actor state store actor reminders can no longer be loaded or written. Array values (e.g. `[{'item1':'value1'},{'item2':'value2'}]`) can not be retrieved via the State Store API. The JSON response includes unexpected artifacts from the internal BSON representation. For example `{"state":"OR","propertyType":"apartment","id":{"$numberDouble":"1003.1"},"city":"Portland"}` when `{"state":"OR","propertyType":"apartment","id":1003.1,"city":"Portland"}` is expected instead. With the introduction of the State Store Query API preview feature in release 1.5.1 data is no longer stored as a string encoded value, but instead as the MongoDB native BSON data types. Not all possible data types were being serialized correctly upon retrieval via the State Store API. Additionally, the internal BSON response was not correctly converted to JSON, thereby including BSON specific data type information in the final JSON representation. These issues were resolved with an update to the MongoDB component data retrieval serialization to properly convert from MongoDB BSON to JSON representation, also adding a special serialization step for array values at the top level of the document. Release `1.6.1` also addresses these issues.
Project: Keylime (Provisioning / Security & Compliance)
File: ROADMAP.md

For most features Keylime uses a kubernetes style enhancement system that is used to manage bigger changes and new features. For details of the enhancement process, please visit the enhancements . This document tracks only major changes done to Keylime. Some aspects of Keylime's user experience can be improved: Update the user documentation (https://github.com/keylime/keylime/issues/1035) Investigate integration with monitoring systems (e.g. Prometheus) The main eventloop in Keylime is very focused on TPM based attestation in combination with IMA and Measured Boot. This has the disadvantage that it is currently not easy to support other forms of claims and evidence (e.g. Intel SGX, AMD SEV) and their retrieval via different methods (e.g. push model, one shot attestation). Moving to a more flexible layered architecture allows us to implement those changes without requiring core changes to Keylime. This entails the following aspects: Evaluating the use of general policy languages for validation (e.g. Rego or Seedwing) (done for Measured Boot) Use common remote attestation terminology (see where the current one differs to the one) Moving the current validation parts into separate modules: quote validation, IMA validation, static PCR checks, Measured Boot (mostly done) Complete the split of the Rust agent into a library and the agent itself Besides the architecture changes there are changes planned to the core of Keylime. Introduce the concept of "named measured policy", very similar to what already is done to "runtime policies" (IMA). This will require both API and database changes Refactoring of verifier and registrar server API implementation Add support for "external actions" during the initial registration Switch to the Python UEFI event log parser Add "named tpm policies", completing the transition on having "policies" as a first-class object in keylime, with a life cycle independent of an agent Harden the "Durable Attestation" implementation, taking the feature out of "experimental" status We are implementing a mode that allows the agents to push the claims and evidence periodically to the verifier. This has the advantage, that the verifier does not need a direct connection to the agents. Accepted proposal: https://github.com/keylime/enhancements/issues/103 The goal is to have an initial implementation in Q1/Q2 and refine it during Q3/Q4. There is an ongoing effort of integrating Keylime with Kubernetes/Openshift: https://github.com/keylime/attestation-operator Enable a full CI/CD Full support for multi-verifier and multi-registrar Initial implementation of CRD to represent generic (i.e., runtime/IMA, measured boot and even tpm) keylime policies Agent scheduler Agent policy selector Map "named policies" model to CRDs Implement verifier-driven status updates Remove the need for atomic quotes, add clock validation and validate all IMA data first before validating content. Also done after the architecture change. Proposal: https://github.com/keylime/enhancements/issues/103
Project: Meshery (Provisioning / Automation & Configuration)
File: traefik-mesh.md

layout: default title: Meshery Adapter for Traefik Mesh name: Meshery Adapter for Traefik Mesh component: Traefik Mesh earliest_version: v1.0 port: 10006/gRPC project_status: stable lab: traefik-meshery-adapter github_link: https://github.com/meshery/meshery-traefik-mesh image: /assets/img/service-meshes/traefik-mesh.svg white_image: /assets/img/service-meshes/traefik-mesh.svg permalink: extensibility/adapters/traefik-mesh redirect_from: service-meshes/adapters/traefik-mesh language: en {% assign sortedtestsgroup = site.compatibility | group_by: "meshery-component" %} {% for group in sortedtestsgroup %} {% if group.name == "meshery-traefik-mesh" %} {% assign items = group.items | sort: "meshery-component-version" | reverse %} {% for item in items %} {% if item.meshery-component-version != "edge" %} {% if item.overall-status == "passing" %} {% assign adapterversiondynamic = item.meshery-component-version %} {% break %} {% elsif item.overall-status == "failing" %} {% continue %} {% endif %} {% endif %} {% endfor %} {% endif %} {% endfor %} {% include compatibility/adapter-status.html %} <!-- {% include adapter-labs.html %} --> The {{page.name}} can install {{page.earliest_version}} of {{page.component}}. A number of sample applications can be installed using the {{page.name}}. The {{ page.name }} is currently under construction ({{ page.project_status }} state), which means that the adapter is not functional and cannot be interacted with through the <a href="{{ site.baseurl }}installation#6-you-will-now-be-directed-to-the-meshery-ui"> Meshery UI </a>at the moment. Check back here to see updates. Want to contribute? Check our . The {{ page.name }} includes some sample applications operations. Meshery can be used to deploy any of these sample applications. - Follow this to set up and deploy the BookInfo sample app on Istio using Meshery. - Httpbin is a simple HTTP request and response service. Examine and how adapters fit in as a component. Learn more about .
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_list_spaces.md

title: "Command - devspace list spaces" sidebar_label: devspace list spaces Lists all user spaces ``` devspace list spaces [flags] ``` ``` List all user cloud spaces Example: devspace list spaces devspace list spaces --cluster my-cluster devspace list spaces --all ``` ``` --all List all spaces the user has access to in all clusters (not only created by the user) --cluster string List all spaces in a certain cluster -h, --help help for spaces --name string Space name to show (default: all) --provider string 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) ```