We use Spring cloud vault as a credential store in our environment.
The fail fast option does not work when the Vault url returns 404 - no exception is thrown but the application continues to start and goes ahead with Spring default password (since no credentials have been fetched from Vault).
I was checking the logs, searched a little bit and found the following:
https://github.com/spring-projects/spring-vault/commit/5078a4c133211adb1bb3642cc867b40deed7b0f0
This takes away the VaultClient - does this mean it also takes away the fail-fast option?
https://github.com/spring-cloud/spring-cloud-vault/issues/143
Related
I recently updated our CDK code to move our OpenSearch cluster from version 1.3 to 2.3. The cluster itself seems to have upgraded to a healthy state and is still accessible / usable by our application, but CloudFormation failed when attempting to update our domain resource with:
Resource handler returned message: "Resource handler returned message: "Invalid request provided: DP Nodes are OOS, Tags operation is not allowed"
This kicked the stack into UPDATE_ROLLBACK_FAILED, which is not allowed. The cluster cannot be downgraded back to 1.3.
I'm struggling to find any information about this error it's kicking out and not quite sure how to resolve it to unblock the CloudFormation stack.
Things I have tried:
Digging through CloudWatch logs only revealed information pertaining to queries.
Forcing the rollback to occur without Domain resource. This got me back to an UPDATE_COMPLETE state, but each subsequent deploy of this stack will cause it to fail again since the core issue is not resolved.
This was an odd presentation of a permissions issue. As I was reading through some docs, I stumbled upon this section, which discusses changes to tag-based access control.
This lead me start looking into CloudTrail a bit and stumbled upon the exact error that was firing when this deploy happened. It was a little odd because the assumed role granted admin access to CloudFormation, but the last line of this event record caught my eye:
"sourceIPAddress": "cloudformation.amazonaws.com",
"userAgent": "cloudformation.amazonaws.com",
"errorCode": "ValidationException",
"errorMessage": "DP Nodes are OOS, Tags operation is not allowed",
"eventSource": "es.amazonaws.com",
Upon adding es.amazonaws.com to the trust relationship of that role, the deploy fully re-ran successfully.
Hopefully this helps someone else.
We are using kube2iam to pass ec2 roles inside containers. Occasionally we get:
Error: Failed to list store contents: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
but then if we restart the container - credentials are picked up.
Seems like we are hitting an issue when kube2iam takes time to pass the credentials.
I did find this commit that makes the timeout even shorter.
So question is:
Is there a way to introduce delayed retries in aws-sdk-go similar to AWS_METADATA_SERVICE_TIMEOUT/AWS_METADATA_SERVICE_NUM_ATTEMPTS?
The Go AWS SDK does not have a direct notion of AWS_METADATA_SERVICE_TIMEOUT/AWS_METADATA_SERVICE_NUM_ATTEMPTS, but it does have a similar concept.
By default, when a EC2Metadata type is created (which is used by the default credentials chain), a timeout override of 1 second is set on the http.Client. If your kube2iam does not respond within that time, the credential call will fail.
You can disable this behavior using the EC2MetadataDisableTimeoutOverride option on your aws.Config when creating the session.Session. When doing this, the timeout will match the behavior of http.DefaultClient.
Example:
cfg := aws.NewConfig().
WithEC2MetadataDisableTimeoutOverride(true).
WithCredentialsChainVerboseErrors(true)
sess, _ := session.NewSession(cfg)
db := dynamodb.New(sess) // etc.
Im new to chef and trying to understand why this code does not return any error while if i do the same with 'start' i will get an error for such service does not exist.
service 'non-existing-service' do
action :stop
end
# chef-apply test.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* service[non-existing-service] action stop (up to date)
Don't know which plattform you are running on if you are running on Windows it should at least log
Chef::Log.debug "#{#new_resource} does not exist - nothing to do"
given that you have debug as log level.
You could argue this is the wrong behaviour, but if the service dose not exist it for sure isen't running.
Source code
https://github.com/chef/chef/blob/master/lib/chef/provider/service/windows.rb#L147
If you are getting one of the variants of the init.d provider, they default to getting the current status of a service by grepping the process table. Because Chef does its own idempotence checks internally before calling the provider's stop method, it would see there is no such process in the table and assume it was already stopped.
Os is Mac Os Maverick.
In a jhipster context (last version, 1.2.2), I get an error when I request the default application on an entity I have just generate using yo jhipster:entity generator.
I run a yo jhipster to create a vanilla application with mongodb as database, java 7 and nothing special.
Then I run grunt build and grunt server for hot reload on the client part and mvn spring-boot:run for the server side app.
When I go to the http://localhost:8080/ url, I get the normal page. I can sign in with either the user or admin login.
I run the yo jhipster:entity foo to get an exemple of rest service in the back end.
When I request for the foo resource with the URL http://localhost:8080/#/foo, I get the page to CRUD the resource as it is said on the jhipster website.
But when I try to create a foo item with the modal form, I get an error on the back end server log ([WARN] org.springframework.web.servlet.PageNotFound - Request method 'POST' not supported).
I can't figure out how to solve this.
Do I miss something in the documentation ?
Do you have any idea, hint ?
I have the same issue using H2 as development database instead of mongodb.
Thanks.
Hervé
This might be due to MongoDB, if you have a date field.
We will release very soon a new and improved Entity sub-generator, which should work better for you. While testing it, I had a serialization issue with MongoDB and a date field, and I corrected it in this new version. This is due to Jackson which can't serialize Joda Time dates (the correct annotations were only generated for SQL databases, not NoSQL databases)
I have followed the instructions at https://github.com/cloudfoundry/oss-docs/tree/master/vcap/adding_a_system_service and copied the echo service and created my new service. (That document is somewhat out-of-date in that "excluded components" no longer exists.
In any case, my service shows up as running with a gateway and a node when I look at 'vcap status' on the server. However, when I look at 'vmc services' from the client my service is not in the list. Where is this list maintained and why is my service not on the list?
Various services, including blob, filesystem, mongodb, etc, are shown on the 'vcm services' list even though they have never been included in my config. Where is this maintained and why are other services on this list?
The cloud_controller.log file shows a "Create service request:" for echo every minute. This service is not in my config file (it was once but it was removed and I repeated the deployment). What is prompting this request for a service that was not defined in the config?
The _gateway.log for my service shows the following:
INFO -- Sending info to cloud controller: ...api.vcap.me/services/v1/offerings
INFO -- Fetching handles from cloud controller .../offerings/.../handles
ERROR -- Failed registering with cloud controller, status=400
DEBUG -- [GaaS-Provisioner] Connected to node mbus..
ERROR -- Failed fetching handles, status=404
Why does my gateway fail to register with the cloud controller? I have found some reports that suggest that the problem is with domain name mapping. I have verified that the server can find itself:
$curl api.vcap.me
Welcome to VMware's Cloud Application Platform
What can I do to register my service?
You can also try asking your question on the vcap_dev google group.
https://groups.google.com/a/cloudfoundry.org/forum/?fromgroups#!forum/vcap-dev
They are focused in answering and discussing OSS subjects for Cloud Foundry!
If you follow the document correctly things should work just fine. I understand that the mechanism for maintaining the excluded list of components has changed and can be a point of confusion when following the steps mentioned in the article (just ignore that step totally).
ERROR -- Failed registering with cloud controller, status=400
Well this is a point of worry. I recently followed the article step by step and was able to add a new service.
Is the echo service showing up in vmc services?
Have you copied the the yml files for node and gateway at ./cloudfoundry/.deployments/devbox/config?
Are the tokens for your gateway unique? and matching in the two files? ./cloudfoundry/.deployments/devbox/config/cloud_controller.yml and ./cloudfoundry/.deployments/devbox/config/**_gateway.yml**
I would recommend that you first concentrate on getting the echo service to be listed in the vmc services output. Once done with this you should replicate the steps (with absolute care to modify things like the token) to get your custom service working.
Cheers,
Ankit
You should follow this guide
It work to me.
regards.