pythonindia / magudi

Salt stack based config for Python India servers
https://in.pycon.org
5 stars 9 forks source link

Can't update junction code while deployment #19

Closed ananyo2012 closed 6 years ago

ananyo2012 commented 6 years ago

The pillar/junction.sls file has the revs section that has the commit to which the code has to be updated. It is currently set to a specific commit. We need to set it to master.

The deployment configs are present in the pillar salt files which are being downloaded from the repo pointed by $PILLAR_GIT_URL as mentioned in the provision script here and updated in each run of provision script. The url is https://bitbucket.org/vigneshsarma/pycon-pillar which is a Private repo.

The present solution is updating the local junction pillar file in the server and comment the line in provision script where the pillar scripts are downloaded.

ananyo2012 commented 6 years ago

@vigneshsarma Can you have a look at #20. We should disable update of pillar files each time provision script is run. Instead update it in the server directly.

vigneshsarma commented 6 years ago

The pillar/junction.sls file has the revs section that has the commit to which the code has to be updated. It is currently set to a specific commit. We need to set it to master.

The problem with that is master of Junction will have to be always deployable. Earlier junction maintainers were not willing to give that guarantee. Has that assumption changed?

The present solution is updating the local junction pillar file in the server and comment the line in provision script where the pillar scripts are downloaded.

The reason for private repo is that we keep secrets like DB password and SMTP password and such in that repo. I don't think storing them in a public repo is a solution.

ananyo2012 commented 6 years ago

The problem with that is master of Junction will have to be always deployable. Earlier junction maintainers were not willing to give that guarantee. Has that assumption changed?

Since CI build is passing we can consider it deployable. Also we need to deploy the new changes.

The reason for private repo is that we keep secrets like DB password and SMTP password and such in that repo. I don't think storing them in a public repo is a solution.

Why not directly change the files in the server itself? We don't need to re-download it in every run.

vigneshsarma commented 6 years ago

Since CI build is passing we can consider it deployable. Also we need to deploy the new changes.

It might be so right now, but is that always guaranteed by the maintainers of Junction?

Why not directly change the files in the server itself? We don't need to re-download it in every run.

We need to be able to quickly setup the server away from the current machine. By storing the secrets outside we are trying to be machine independent. Also by redownloading the config each time we make sure that we do no accumulate local changes on that machine.

ananyo2012 commented 6 years ago

It might be so right now, but is that always guaranteed by the maintainers of Junction?

Uh I am not sure who is the current maintainer of junction. Krace stepped down as a maintainer as mentioned here. I have to check with others then. But let's update just this one for now since the CFPs are closing tomorrow and the CFP team won't be able to start reviewing if we don't get it ready.

We need to be able to quickly setup the server away from the current machine. By storing the secrets outside we are trying to be machine independent. Also by redownloading the config each time we make sure that we do no accumulate local changes on that machine.

Ok can you update the current revision of junction to master in the pillars repo ?

ananyo2012 commented 6 years ago

As per above discussion we should keep the junction credentials independent from the server in a secure place instead of manually updating it inside the server. Hence, Closing this issue.