1.0-rc2 struggles (multiple)

Drone Support
1

Trying to get 1.0-rc2 up and running.

Using this kubectl apply with a full version of the file at:

https://gist.github.com/ericsgagnon/a56c9f2a89fbe09919f8f92529799877

Issues:
using tls on postgres doesn’t work at all. From the sslmode=disable in the docs, it looks like this is unsupported?
I can get to the login screen, but I consistently get a timeout once I login. I’m using gitea - checking the gitea pod logs returns 200 status on GET for some logins and errors (can’t remember which) for others.
The environment variables are somewhat confusing - is the server proto for the agents or end users accessing the application? I’m sitting behind ambassador proxy.
The debug mode is useless - It constantly posts, but doesn’t post any of my error.
When attempting to login through the proxy (let’s call it https://ci/login), I get the login form, and fill it out, but then get an ‘upstream request timeout’ error.

I’ve tried about 35-40 slight variations on configurations, including using the sqlite db. I just don’t know enough about the configuration variables to tell if I’m doing that wrong or there’s some kind of actual bug, and the logs are effectively useless at the moment.

My main ask is if someone can take a look at my app yaml in the gist and let me know if the configuration itself looks bad. Or if anyone else is experiencing similar issues, knowing that might help.

I’m tempted to just deploy v0.8x but it looks like there are enough breaking changes that I’d just be buying myself a short time…

Thanks for any help!
Eric

2

using tls with postgres is fully supported at the driver level. You need to make sure you configure the Go postgres driver correctly (per their docs) and you mount your certs into the container properly.

I cannot really comment without seeing specific error messages.

This should be set to your drone server address (as you would type into your browser address bar). Also note that Drone for Kubernetes is agentless.

This comment is vague and unconstructive. Please consider reforming the question, or providing more clear and constructive feedback.

A network timeout would indicate some problem with your network configuration. Have you tried to docker exec (or whatever the kube-equivalent is) into the Drone server container and curl the gitea server to ensure it can be reached?

3

@bradrydzewski - thank you! I overlooked the port specification when referencing my kubernetes service, which was causing the disconnect between drone and gitea. I have that working now. I can login as the pre-created use (username is dronebot), but I can’t sync repos or login as any other gitea user. I think it’s probably due to a lingering issue with pq as below. Any advice on what might be cause this?

2018-12-17 16:07:06.113 UTC [33] ERROR:  value "-62135596800" is out of range for type integer
2018-12-17 16:07:06.113 UTC [33] STATEMENT:  
UPDATE users
SET
 user_email         = $1
,user_admin         = $2
,user_active        = $3
,user_avatar        = $4
,user_syncing       = $5
,user_synced        = $6
,user_created       = $7
,user_updated       = $8
,user_last_login    = $9
,user_oauth_token   = $10
,user_oauth_refresh = $11
,user_oauth_expiry  = $12
,user_hash          = $13
WHERE user_id = $14

Also, in debug mode, I don’t get any informative logs, just thousands of these per second:

{"fields.time":"2018-12-15T04:33:43Z","latency":13786,"level":"debug","method":"POST","msg":"","remote":"10.40.0.0:19938","request":"/rpc/v1/request","request-id":"1ENM5uXAVGOXQ2N03XnEBqfp3ou","time":"2018-12-15T04:33:43Z"}
4

Just updated to rc3 and I’m able to sync now, but I’m still getting the error below in the postgres container’s logs when trying to login under a different user than the precreated one. Is it possible there’s an empty field or fieldname mismatch that’s causing this?

2018-12-17 17:00:26.892 UTC [33] ERROR:  value "-62135596800" is out of range for type integer
2018-12-17 17:00:26.892 UTC [33] STATEMENT:  
INSERT INTO users (
 user_login
,user_email
,user_admin
,user_machine
,user_active
,user_avatar
,user_syncing
,user_synced
,user_created
,user_updated
,user_last_login
,user_oauth_token
,user_oauth_refresh
,user_oauth_expiry
,user_hash
) VALUES (
 $1
,$2
,$3
,$4
,$5
,$6
,$7
,$8
,$9
,$10
,$11
,$12
,$13
,$14
,$15
)

RETURNING user_id
5

Also, in debug mode, I don’t get any informative logs, just thousands of these per second:

If you get thousands of these per second, it would tell me there is some problem with your agent <> server configuration. It would like tell me the agent is connecting to the server and disconnecting. Perhaps due to an incorrect secret? Have you checked your agent logs? you can also enable DRONE_RPC_DEBUG=true in your agent (this should only be enabled temporarily) but will enable debug logs for the long polling and API requests.

6

Thanks! I think the issue was I was configuring agents before, until you pointed out that kubernetes runtime is agent-less. I’m no longer seeing these in debug mode. I will mention that the rpc secret section of the gitea/kubernetes installation guide still references agents, which I think was part of my confusion:

https://readme.drone.io/installation/gitea/kubernetes/
DRONE_RPC_SECRET references agents.

Is it still spawning agents as needed or just workers?