update nko module for joyent & 2014
gerad opened this issue · 20 comments
so that we get a callback when people deploy their app to joyent
https://github.com/nko4/website/tree/master/module
https://github.com/nko4/website/blob/master/controllers/deploys.coffee
@gerad other than the domain .jitsu.com, there is other thing to update, am I right? what is going to be the domain being used this year in Joyent machines? :)
You can remove the subdomain stuff. We will already have that in the db. I'm not sure exactly what needs to be changed, you'll have to play around with it and see if you can get it working.
a couple tweaks we should make to this script (based on a lesson I remembered from last time):
last time, when an app was improperly deployed, it'd would "flop" a bunch, (e.g. die and get restarted by the script), so we'd get lots of deploy notices for every time it was restarted
to fix that, I recommend we take the following steps
- wait 5 seconds before sending the deploy checkin - that way, if the app dies within the first 5 seconds we don't incorrectly consider it deployed
- check that the app is responsive on localhost:80 (and returns a 200 status code, after following redirects) from within the deploy script before sending the notification, that way if the app is running on an invalid port, or not responsive, we don't incorrectly consider it deployed (we also already check this from the server, but this will save cpu on our end)
- only send the deploy notification if new code has actually been deployed... i'm not quite sure how to do this.. maybe by checking the git sha1 (that presupposes git-based deployment, but that might be ok)
all of those reasons should be documented on the page they'll be looking at for "is my app deployed yet?" eg, "not seeing your deploy? maybe here's why: 1, 2, 3."
On Oct 28, 2013, at 8:06 AM, Gerad Suyderhoud notifications@github.com wrote:
a couple tweaks we should make to this script (based on a lesson I remembered from last time):
last time, when an app was improperly deployed, it'd would "flop" a bunch, (e.g. die and get restarted by the script), so we'd get lots of deploy notices for every time it was restarted
to fix that, I recommend we take the following steps
wait 5 seconds before sending the deploy checkin - that way, if the app dies within the first 5 seconds we don't incorrectly consider it deployed
check that the app is responsive on localhost:80 (and returns a 200 status code, after following redirects) from within the deploy script before sending the notification, that way if the app is running on an invalid port, or not responsive, we don't incorrectly consider it deployed (we also already check this from the server, but this will save cpu on our end)
only send the deploy notification if new code has actually been deployed... i'm not quite sure how to do this.. maybe by checking the git sha1 (that presupposes git-based deployment, but that might be ok)
—
Reply to this email directly or view it on GitHub.
So the first 2 are here: https://github.com/nko4/website/tree/fixdeploymodule
Any tips or examples for the last one? :)
hey @diasdavid , @humanbagel is in this code for something else, so he'll work with you on getting this finalized
Also, did you check with @tjfontaine to make sure that the subnet we're looking at for the joyent instances is correct? https://github.com/nko4/website/blob/fixdeploymodule/models/deploy.coffee#L26-L27
Also, it look like that validation is currently commented out still, can you please fix it? Or else deploys will not work on production.
True, totally forgot to uncomment the prod options and comment the test ones, now it's right.
As for the subnet, I'm reaching out to TJ, should have news soon :)
I don't know offhand the subnets that will be used, why do we need that validation if joyent will be the only provider? or are you trying to determine for fraud later if someone has opted to take their app and move it elsewhere?
mostly, it's to ensure that there's no confusion from people who host their app somewhere else and say, "but it said it was deployed correctly" when we dq them for potential cheating
I can get the subnets that will be in us-east, but it would seem the easiest way to verify things are in the right place are validating ip to what you expect from the dns you set previously during provisioning. Otherwise it seems like the easiest way around it would be to spin up my own in joyent us-east.
Oh cool, so the remote ip from the request will match? That's great, I can just use that then!
@diasdavid can you look into getting the module republished on npm? You may need to work with @visnup to do so.
Can you also please update the README in the module directory to call out the changes you made to the module: #66 (comment) so that people can better debug
@gerad here: https://github.com/nko4/website/blob/fixdeploymodule/module/README.md :)
@visnup can you redeploy the module to NPM? Can I help you with anything to make this happen? TY :)
@visnup @diasdavid probably best to deploy the module after this is merged into master...
@diasdavid I made you an owner on the module https://npmjs.org/package/nko can you bump the version and push it to npm?
Done :) ready for all the npm install's out there :)
https://npmjs.org/package/nko