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
Hi @flovilmart are you running your app inside container engine? i am asking it because from your code i understand that GCLOUD_PROJECT and GOOGLE_APPLICATION_CREDENTIALS are mandatory but if you run inside google container engine or inside GCP then those params are not required. Also what about unsubscribe? I noticed that you didn't implemented the unsubscribe and i think that we must find a better solution (than SIGTERM or SIGINT) something from the platform...
In order to use pub/sub in container engine only need to allow access from container engine to pub/sub (a step that needs to be done when you create your cluster). I totally agree about the warnings but even if GCP set those env variables you need to know the name of them in order to check it in the app.
From what i noticed there will be only 2 subscriptions (one for afterSave and another one for afterDelete) each one will be located under one topic so if this is really the case we can assume that they will be there until the user/admin will manually delete them
I agree about the k8s one because each time you update a version (for instance) it will power off and power on the new instances according to your replica set ...
So it looks like that we need to go with the SIGINT and SIGTERM approach until we will find a better way to do it... what do you think ?
@ranhsd I added SIGINT/SIGTERM handlers to delete the subscription, works OK when removing, the process.exit(0) on parse-server CLI. parse-community/parse-server#3634
@flovilmart You are using this adapter only in production or you also use it for development mode? Currently i am planning to use this one in production only scenarios and use Redis for development
Activity
ranhsd commentedon Feb 23, 2017
Hi @flovilmart are you running your app inside container engine? i am asking it because from your code i understand that GCLOUD_PROJECT and GOOGLE_APPLICATION_CREDENTIALS are mandatory but if you run inside google container engine or inside GCP then those params are not required. Also what about unsubscribe? I noticed that you didn't implemented the unsubscribe and i think that we must find a better solution (than SIGTERM or SIGINT) something from the platform...
flovilmart commentedon Feb 23, 2017
I believe those env variables are set by default on container engine and app engine. I'm running on kubernetes.
Also, we could transform those as warnings or make sure the google platforms set them.
For the unsubscribe, I'm not sure how to correctly destroy those. We should probably add the event handlers in this code no?
ranhsd commentedon Feb 23, 2017
Hi ,
In order to use pub/sub in container engine only need to allow access from container engine to pub/sub (a step that needs to be done when you create your cluster). I totally agree about the warnings but even if GCP set those env variables you need to know the name of them in order to check it in the app.
From what i noticed there will be only 2 subscriptions (one for afterSave and another one for afterDelete) each one will be located under one topic so if this is really the case we can assume that they will be there until the user/admin will manually delete them
flovilmart commentedon Feb 23, 2017
This is part of google authentication docs, https://developers.google.com/identity/protocols/application-default-credentials I agree I should probably remove the warning and let the calls fail naturally.
2 subs / live query server, which can add up to a lot with kubernetes if those are not destroyed :)
ranhsd commentedon Feb 23, 2017
I agree about the k8s one because each time you update a version (for instance) it will power off and power on the new instances according to your replica set ...
So it looks like that we need to go with the SIGINT and SIGTERM approach until we will find a better way to do it... what do you think ?
flovilmart commentedon Feb 23, 2017
that seems to be reasonable, unless we have a way to clear up subscriptions that are unused for a while.
ranhsd commentedon Feb 23, 2017
Let's tested it and see if it works well. Do you know how it is implemented in Redis adapter?
flovilmart commentedon Mar 13, 2017
@ranhsd I added SIGINT/SIGTERM handlers to delete the subscription, works OK when removing, the process.exit(0) on parse-server CLI. parse-community/parse-server#3634
ranhsd commentedon Mar 13, 2017
Hi @flovilmart did you change also the pub/sub adapter ?
flovilmart commentedon Mar 13, 2017
Yup there too: #3
ranhsd commentedon Mar 13, 2017
Ok. I merged it. Love the idea that we are not using babel anymore. I will also change it on the other adapter (the firebase authentication)
ranhsd commentedon Mar 19, 2017
@flovilmart You are using this adapter only in production or you also use it for development mode? Currently i am planning to use this one in production only scenarios and use Redis for development
flovilmart commentedon Mar 19, 2017
We're planing to deploy to prod in the upcoming weeks. We're deploying in dev and scaling it across multiple AZ to see how it goes
flovilmart commentedon Apr 17, 2017
Closing as implemented.