Bad Response statusCode [422] etc etc etc

Rancher 1.x
1

I am playing around with a new service I am building for the Rancher Catalog (this: Building a catalog item (that requires configuration files) - #4 by Daniel_Skinner) … I am almost done with it but, for some reasons, the catalog entry generate a weird error message half of the times I deploy it.

I know the syntax is fine because it gets deployed half of the times just fine but the remaining half of the times it just spits this error:

Error (Bad response statusCode [422]. Status [422 status code 422]. Body: [fieldName=name, baseType=error, code=NotUnique] from [http://localhost:8080/v2-beta/projects/1a5/services])

Only a subset of the 7 containers that comprise the app get shown in the deployment phase (it varies, it may be 5, it may be 2, it may be 3) and then it spits that error.

Here is an example of a failed instantiation:

Pasted image1904×249 42.5 KB

I can’t trace it down to anything obvious. It’s completely random… It can spit it for 6 consecutive times and then the 7th run will succeed.

I have been searching around and it appears that this was observed in the past as well. I was at first thinking about some sort of a race condition on the stack name (as I was deleting and re-deploying quickly with the same stack name and perhaps the delete was not completely occurred yet) but then I have seen this problem also when using a different name stack for every deployment.

Curious to see if anyone is seeing this?

2

Ok I think I was able to track down the problem.

The compose I use uses a sidekick container which crunches some data and then the app containers get the “volumes_from” this sidekick to read the data it crunched.

The “code=NotUnique” in the error message made me think about some sort of conflict / race condition. So I have created n different sidekick containers (where n is the number of app containers that need to get the volumes from the sidekick).

It makes the compose grow exponentially (and it also make it difficult to pass variables to compose because now I need to replicate the variables in the n sidekicks) but at least it works fine now (never failed ever since I made the change).

I am also sure @rawmind is happy cause he’s been advocating for dedicated sidekicks ever since :slight_smile: