I am getting this error when trying to deploy a simple function.
Serverless Error ---------------------------------------
ServerlessError: Inaccessible host: `cloudformation.us-west-2.amazonaws.com'. This service may not be available in the `us-west-2' region.
Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Issues: forum.serverless.com
Your Environment Information -----------------------------
OS: linux
Node Version: 10.15.3
Serverless Version: 1.38.0
Related
End Desire:
To build my AWS Amplify project in the dev environment, using full-stack CI/CD. So for example, pushing my changes to Code Commit will build the backend resources.
Build Logs:
2023-01-06T06:19:26.457Z [INFO]: [33mNote: It is recommended to run this command from the root of your app directory[39m
2023-01-06T06:19:27.797Z [WARNING]: - Initializing your environment: dev
2023-01-06T06:19:29.164Z [WARNING]: - Building resource api/project
2023-01-06T06:19:33.756Z [WARNING]: - Building resource auth/project
2023-01-06T06:19:33.902Z [WARNING]: - Building resource storage/project
2023-01-06T06:19:33.939Z [WARNING]: ✔ Initialized provider successfully.
2023-01-06T06:19:34.452Z [WARNING]: ✖ There was an error initializing your environment.
2023-01-06T06:19:34.453Z [INFO]: 🛑 Syntax Error: mismatched brackets found in the schema. Unexpected ) at line 239 in the schema.
2023-01-06T06:19:34.453Z [INFO]: Learn more at: https://docs.amplify.aws/cli/project/troubleshooting/
buildspec.yml:
version: 0.1
frontend:
phases:
preBuild:
commands:
- npm i
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- node_modules/**/*
Checks:
I have checked the graphql.schema for errors.
I have removed the testing section in the buildspec.
I have added amplify push --simple as recommended here
I've ran npm run build on my local CLI successfully
In the AWS Amplify console, under build settings, the AWS CLI version was "latest". Changing the AWS CLI version to 10.4.0 fixed the issue.
View AWS CLI Versioning here: https://www.npmjs.com/package/#aws-amplify/cli?activeTab=versions
Rather than going to 10.4.0, go back a couple versions from the latest AWS CLI version at the time.
Jaeger operator shows this log.
time="2022-01-07T11:27:57Z" level=info msg=Versions arch=amd64 identity=jaeger-operator.jaeger-operator jaeger=1.21.0 jaeger-operator=v1.21.3 operator-sdk=v0.18.2 os=linux version=go1.14.15 time="2022-01-07T11:28:20Z" level=warning msg="Failed to parse current Jaeger instance version. Unable to perform upgrade" current= error="Invalid Semantic Version" instance=tracing namespace=istio-system
The tracing operated resource shows like this afterwards:
kubectl get jaeger
NAME STATUS VERSION STRATEGY STORAGE AGE
tracing Running allinone elasticsearch 37d
We use GitOps for distributing the applications (included jaeger-operator and jaeger tracing resource). Only difference we are aware is between versions of clusters. In this case, this is only failing for a particular cluster with the following kubernetes version:
Server Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.12-gke.1500", GitCommit:"d32c0db9a3ccd0ac73b0b3abd0532505217b376e", GitTreeState:"clean", BuildDate:"2021-11-17T09:30:02Z", GoVersion:"go1.15.15b5", Compiler:"gc", Platform:"linux/amd64"}
Other than the log error and the resulting missing information from the get jaeger command, the jaeger-operator modifies 2 things from the initial manifest:
It removes the line: .spec.storage.esRollover.enabled: true
It lowercases the .spec.strategy: AllInOne
The functions used for parsing the version: https://github.com/jaegertracing/jaeger-operator/blob/v1.21.3/pkg/upgrade/main.go#L28
The the function used to check the current version and compare it to verify if it needs to update the resource: https://github.com/jaegertracing/jaeger-operator/blob/v1.21.3/pkg/upgrade/upgrade.go#L134
They both look ok to me. Can't tell where/what the problem is and how to workaround it.
When issuing serverless deploy --region eu-central-1, I get the error
Type Error ---------------------------------------------
Cannot read property 'Properties' of undefined
For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.
This error only started after including
plugins:
- serverless-iam-roles-per-function
and can be reverted by commenting the plugin out. But I would like to use it for giving my lambda access to a DynamoDB.
The internet is pretty void about this error besides this typo. The error is not solved by a recent update (yet) and the notice of serverless doesn't help much. set SLS_DEBUG=*" before deployment yields:
Type Error ----------------------------------------------
TypeError: Cannot read property 'Properties' of undefined
at ServerlessIamPerFunctionPlugin.createRoleForFunction (C:\Users\XXXXX\MyProject\node_modules\serverless-iam-roles-per-function\dist\lib\index.js:273:25)
at ServerlessIamPerFunctionPlugin.createRolesPerFunction (C:\Users\XXXXX\MyProject\node_modules\serverless-iam-roles-per-function\dist\lib\index.js:383:18)
at PluginManager.invoke (C:\snapshot\serverless\lib\classes\PluginManager.js:579:20)
at async PluginManager.spawn (C:\snapshot\serverless\lib\classes\PluginManager.js:601:5)
at async Object.before:deploy:deploy [as hook] (C:\snapshot\serverless\lib\plugins\deploy.js:60:11)
at async PluginManager.invoke (C:\snapshot\serverless\lib\classes\PluginManager.js:579:9)
at async PluginManager.run (C:\snapshot\serverless\lib\classes\PluginManager.js:639:7)
at async Serverless.run (C:\snapshot\serverless\lib\Serverless.js:452:5)
at async C:\snapshot\serverless\scripts\serverless.js:751:9
For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.
Should I iunclude my serverless.yml in this post? It's quite large.
Using some different key words I retrieved a second (!) online search result, quoting:
The plugin doesn't support working with the role property. You have the following in your provider sections: role: arn-for-deployment-role'. Try removing this.
More info here
This basically solves the issue and serverless-iam-roles-per-function worked after commenting out this:
provider:
name: aws
runtime: python3.7
#iam:
# role: CallsTableQueryRole
The reason for this could be, that previos versions (serverless < v2.24.0) used a different syntax than current ones. Compare:
provider:
#previously:
iam:
role:
statements:
#≥ v2.24.0
iamRoleStatements:
If you're using Bref framework make sure to update bref in composer and serverless globally to the latest version
Is there a way to deploy GCP function with Go 1.15 using Serverless framework ?
Looks like 1.15 is available (https://cloud.google.com/appengine/docs/standard/go/runtime) but I can't find a way to do it with Serverless.
serverless.yml
...
provider:
name: google
runtime: go115
...
I have this Invalid runtime error :
{"ResourceType":"gcp-types/cloudfunctions-v1:projects.locations.functions","ResourceErrorCode":"400","ResourceErrorMessage":{"code":400,"message":"The request has errors","status":"INVALID_ARGUMENT","details":[{"#type":"type.googleapis.com/google.rpc.BadRequest","fieldViolations":[{"field":"runtime","description":"Invalid runtime."}]}],"statusMessage":"Bad Request","requestPath":"https://cloudfunctions.googleapis.com/v1/projects/**************/locations/us-central1/functions/*****","httpMethod":"PATCH"}}
The GO1.15 runtime is not supported by the regular and beta version of Cloud Functions.
Use Go1.13 instead, or use Cloud Run.
When I try us api-platform version 2.6.4 I am not able to run it when i build adn strat containers and check logs caddy is not working i get an error like this. Any idea? Caddy version is 2.3.0
caddy_1 | panic: proto: file "pb.proto" is already registered
caddy_1 | See https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict
tureality_caddy_1 exited with code 2
Other people have reported having this bug and I had it too.
Fortunately, the bug as just been fixed by Dunglas itself. :)
https://github.com/api-platform/api-platform/issues/1881#issuecomment-822663193
The repair was done at the mercure level and not in the api platform source code itself so you can keep your current version.
You just have to docker-compose up and it will work.