Closed ananyo2012 closed 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.
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.
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.
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.
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 ?
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.
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.