You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the user creates a service and it gets deployed on the platform, often the port is missing from the announce data written into etcd by the announce sidekick.
e.g.:
core@yld-paz-2 ~ $ etcdctl get /paz/services/intranet/6/1
10.131.238.241:
But if you restart the announce unit it will be fixed. E.g.:
core@yld-paz-2 ~ $ fleetctl stop intranet-announce-6-1 && sleep 2 && fleetctl start intranet-announce-6-1
Unit intranet-announce-6-1.service loaded on 76f05a29.../178.62.94.203
Unit intranet-announce-6-1.service launched on 76f05a29.../178.62.94.203
core@yld-paz-2 ~ $ etcdctl get /paz/services/intranet/6/1
10.131.238.241:49192
My guess it that it isn't correctly waiting for the port to be assigned before trying to fetch it with docker inspect.
Given that the hand-written announce unitfiles for the internal Paz services are more battle-tested, I propose re-writing lib/unitfile.js to write announce unitfiles the same as paz-orchestrator (for e.g.).
The text was updated successfully, but these errors were encountered:
When the user creates a service and it gets deployed on the platform, often the port is missing from the announce data written into etcd by the announce sidekick.
e.g.:
But if you restart the announce unit it will be fixed. E.g.:
My guess it that it isn't correctly waiting for the port to be assigned before trying to fetch it with
docker inspect
.Given that the hand-written announce unitfiles for the internal Paz services are more battle-tested, I propose re-writing
lib/unitfile.js
to write announce unitfiles the same aspaz-orchestrator
(for e.g.).The text was updated successfully, but these errors were encountered: