I have accidentally deleted LinstorController instance from Linstor Operator by Openshift console.
Fortunatelly it was not deleted because LinstorSatelliteSet exists.
Please see the error:
oc describe linstorcontroller/linstor
...
errors:
- >-
temporary error: timeout=60000000000, error=controller controller still
has active satellites which must be cleared before deletion:
[txl4201.nprod01.ocp.vub.sk txl4202.nprod01.ocp.vub.sk
txl4203.nprod01.ocp.vub.sk txl4204.nprod01.ocp.vub.sk
txl4205.nprod01.ocp.vub.sk txl4301.nprod01.ocp.vub.sk
txl4302.nprod01.ocp.vub.sk txl4303.nprod01.ocp.vub.sk
txl4304.nprod01.ocp.vub.sk]
Is it possible to recover from this state and how?
Openshift ver. 4.8.29
Linstor Operator ver. 1.5.1
Linstor controller version 1.13.0; GIT-hash: 37c02e20aa52f26ef28ce4464925d9e53327171c
Thank you in advance
Otto Bodor
The problem was resulted by deleting the finalizers following Red Hat knowledgebase: https://access.redhat.com/solutions/2317401 of the deleted LinstorController object oc patch linstorcontrollers linstor --type='merge' -p '{"metadata":{"finalizers":null}}' and recreating it by the original yaml file again.
The lucky thing was LinstorController did not initialized its db but reused it.
Everythings is working.
Related
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.
I have a Go program that uses aws-sdk-go to talk to dynamodb. Dependencies are vendored. Go version 1.7.1. aws-sdk-go version 1.6.24. The program works as expected in all the following environments:
dev box from shell (Arch Linux)
docker container running on my dev box (Docker 1.13.1)
Ec2 instance from shell (Ubuntu 16.04)
When I run the docker container on kubernetes (same one I tested on my dev box), I get the following error:
2017/03/02 22:30:13 DEBUG ERROR: Request dynamodb/GetItem:
---[ REQUEST DUMP ERROR ]-----------------------------
net/http: invalid header field value "AWS4-HMAC-SHA256 Credential=hidden\n/20170302/us-east-1/dynamodb/aws4_request, SignedHeaders=accept-encoding;content-length;content-type;host;x-amz-date;x-amz-target, Signature=483f56dd0b17d8945d3c2f2044b7f97e531190602f132a4d5f828264b3a2cff2" for key Authorization
-----------------------------------------------------
2017/03/02 22:30:13 DEBUG: Response dynamodb/GetItem Details:
---[ RESPONSE ]--------------------------------------
HTTP/0.0 000 status code 0
Content-Length: 0
Based on:
https://golang.org/src/net/http/transport.go
https://godoc.org/golang.org/x/net/lex/httplex#ValidHeaderFieldValue
It looks like the problem is with the header value validation, yet I am at a loss to understand why it works everywhere except on my k8s cluster. The cluster is composed of Ec2 instances running the latest CoreOS stable ami (CoreOS stable 1235.8.0)
The docker image that works on my dev machine is scratch based. To troubleshoot I created an image based on Ubuntu latest with a separate go program that just does a simple get item from dynamodb. When this image is run on my k8s cluster and the program run from an interactive shell, I get the same errors. I have confirmed I can ping the dynamodb endpoints from this env.
I am having a hard time troubleshooting this issue: am I missing something stupid here? Can someone point me in the right direction or have an idea of what is going on?
remember the "-n" when you do this:
echo -n key | base64
The \n after hidden is certainly invalid. Not sure if it is actually there or somehow got inserted when you were cleansing for posting.
Consider:
package main
import (
"fmt"
"golang.org/x/net/lex/httplex"
)
func main() {
fmt.Println("Is valid (without new line)", httplex.ValidHeaderFieldValue("AWS4-HMAC-SHA256 Credential=hidden/20170302/us-east-1/dynamodb/aws4_request, SignedHeaders=accept-encoding;content-length;content-type;host;x-amz-date;x-amz-target, Signature=483f56dd0b17d8945d3c2f2044b7f97e531190602f132a4d5f828264b3a2cff2"))
fmt.Println("Is valid (with new line)", httplex.ValidHeaderFieldValue("AWS4-HMAC-SHA256 Credential=hidden\n/20170302/us-east-1/dynamodb/aws4_request, SignedHeaders=accept-encoding;content-length;content-type;host;x-amz-date;x-amz-target, Signature=483f56dd0b17d8945d3c2f2044b7f97e531190602f132a4d5f828264b3a2cff2"))
}
One guess would be wherever the real hidden value is getting pulled from (config file etc) mistakenly has the \n in there and it's happily getting pulled into your header, but only in this case.
I wrote an automized puppet file for the installation with Vagrant.
It's just for a fast installation for a apache web server (with PHP5, MySQL)
and atm it is as simple as possible for the beginning.
Every time I start up my Vagrant I get these messages and couldn't interpret
by myself:
←[0;36mnotice: /Stage[main]/Lamp/Package[php5]/ensure: ensure changed 'purged' t
o 'present'←[0m
←[0;36mnotice: /Stage[main]/Lamp/Package[mysql-client]/ensure: ensure changed 'p
urged' to 'present'←[0m
←[0;36mnotice: /Stage[main]/Lamp/Package[mysql-server]/ensure: ensure changed 'p
urged' to 'present'←[0m
←[0;36mnotice: /Stage[main]/Lamp/Package[apache2]/ensure: ensure changed 'purged
' to 'present'←[0m
This is not an error at all.
It just says, that the state of those packages has changed from purged to present.
purged = not installed
present = installed
It just means, the package was installed successfully.
Sometimes Glassfish - OpenESB-v2.3 gives following error:
jbi-registry.xml:1:1: Premature end of file.
What did happen here?
This occurs sometimes when the Server or Glassfish restarts or have not correct shutdown (sometime Windows Update forced restarts). Then the file jbi-registry.xml is empty and we get above error.
To correct it, just go to the following folder:
%GLASSFISH_ESB%/glassfish/domains/domain1/jbi/config
And check if the jbi-registry.xml is empty. If this is the case, replace it with the jbi-registry-backup.xml which is located in the same directory and should not be empty.
I added a resource and then deleted it afterwards.
However, when I issue the following command:
crm_resource -l
It is still listed! I try to remove it:
crm configure delete <resource_name>
I get the following error:
ERROR: object <resource_name> does not exist
Moreover:
crm configure show | grep <resource_name>
doesn't match any resource of that name! CIB also doesn't have it listed under LRM...
Any idea how to get rid of this resource?
Thanks,
D.
This seems to be "normal" in Pacemaker 1.1.6 - if you tell it delete something, it will delete it and then complain to you that it no longer exists.