There's a warning that states that, in Serverless Framework 3.0, apiKeys, usagePlan and resourcePolicy keys are only going to be available under provider.apiGateway, however, there are some extra fields related to the API that are still leftover in the provider key, e.g apiName and endpointType and 1) there's no warning for them 2) it's not possible for use them inside apiGateway (

Next line returns 200 as status https://github.com/Kong/kong/blob/c817fada7a514d84f6e0aab7461605c71bf3a841/kong/plugins/cors/handler.lua#L13

Internet says it should return 204:

• https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
• https://docs.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-3.1#preflight-requests

Internet changed its mind since 2018 https://

In what area(s)?

/area test-and-release

Describe the proposal

Currently before each rc release

Is your feature request related to a problem? Please describe.
AWS has released a newer version of their SDK which is far more lightweight.

Affected packages:

• @cubejs-backend/athena-driver
• @cubejs-backend/serverless-aws
• @cubejs-backend/mysql-aurora-serverless-driver

Describe the solution you'd like
Use the new SDK.

Command: cortex debug exec API_NAME

Behavior: choose a running API pod (at random is ok if there are multiple), and run e.g. kubectl exec -it api-iris-classifier-6d866654f8-pwz62 --container api -- /bin/bash

This command should be executed in the manager container, similar to how the cortex cluster up command works. However unlike cortex cluster up, this command will require interact

We want to use caching to speed up Appwrite's Travis CI build process, and we can use the community help here.

Currently our build process time is around ~10 minutes which is OK, but as faster it can be less time maintainers needs to wait for confirmation that there changes are running as expected.

This change should be focused on our Travis CI YAML file. Any suggestions for improving the co

Is your feature request related to a problem? Please describe.

Missing functionality to update min/max cpu/mem of an exiting ENV. Currently, to update, we are forced to delete and re-create the env. This also has a risk of dependent functions being erratic. It also de-couple resource utilization independent of function creation and be useful to update the resource in a quick to respond situ

The typescript runtime was recently added to openwhisk but we do not yet have docs for the runtime and it is missing from runtimes.json.

We need a doc like https://github.com/apache/incubator-openwhisk/blob/master/docs/actions-nodejs.md for typescript functions.

Adding the runtime to the runtime manifest can be done per https://github.com/apache/openwhisk/blob/master/docs/actions-new.md#the-

this will very quickly get out of hand if we allow it, i realize we don't have principles written down anywhere but to date one of them has been that binaries 'just work' without having to do any configuration. currently a user must set FN_MAX_REQUEST_SIZE, FN_MAX_RESPONSE_SIZE -- neither of these should be required to run.

test case:

cd tests/fn-system-tests/
go test -v

this

Improve Docs

Please describe which part of docs should be improved or typo fixed

Currently in getting-started, there would always be a $ at the front of each command, which makes users hard to do three-click to directly copy the whole command and run without modification. They have to manually delete `