Closed ddunlap2005 closed 4 years ago
@ddunlap2005 - I can't speak for here.com (the company behind this project), but not much happens in this project anymore. The components it deploys are all actively developed on though.
Your biggest problem is going to be rooted in the fact the container versions this repo deploys are really stale. In fact, "modern" reposervers no longer use vault which makes deploying this A LOT easier.
I'm not sure you larger goal, but I wrote up a blog series a while back on deploying this stuff. Its based on slightly newer versions of each service (including not needing vault):
https://foundries.io/insights/2018/06/27/ota-part-3/ https://foundries.io/insights/2018/06/27/ota-part-4/ https://foundries.io/insights/2018/08/09/ota-api/
The downside is that its geared towards GKE. However, you might get further by reading into this.
Another thing I've done is to run this stuff from docker-compose:
https://github.com/foundriesio/ota-compose
This stuff is rough around the edges, but its so much more simple than k8s that it provides a pretty fast way to quickly experiment/develop/debug etc. And despite what the description says, it now has the ability to run the Uptane bits as well: https://github.com/foundriesio/ota-compose/blob/master/uptane.yml
Hi @doanac - I most certainly have read your Foundries.io blogs. Thank you very much for those! I did not attempt to clone your repos for, as you said, they are geared towards GKE.
I did attempt to use your helm_migration branch (which uses all the latest images) but came across a problem in the ota-gateway with attempting to resolve ota-tuf-reposerver-internal.default.svc.cluster.local in the nginx logs. I also created a API_PROVIDER_HOST configMap parameter as it appeared to be missing. I guessed at a value of api for it. After getting stymied there, I went back to master branch and managed to fix most things.
I am attempting a proof-of-concept for a company and wanted to show them a working OTA with device manager backend server. We had used here.com's OTA Connect without issue but wanted an on-premise server. The thought was that ota-community-edition should work fine. The added benefit was that I would become much more familiar with Kubernetes. Well, I certainly am more familiar with Kubernetes now.
I'll take a look at the docker-compose work you have done and see what I can do with it.
Thanks very much
Hi, @ddunlap2005 I'm interested in trying out OTA-community-edition too. Have you managed to bring the whole infrastructure up?
Hi @kriive. We have brought up the Fountries.io version of Ota-community-edition described in Andy's blogs above (not the Docker compose version). We are still working on the client and having a few errors, however. I am not sure if the problem is the client or the server-side. I will be helping our developer with the client-side this week hopefully.
I have given up on the master branch of this software.
Hi,
Not sure if this project is still maintained. I've instantiated a minikube Kubernetes v1.15.6 cluster and ran 'make start'. I needed to modify the scripts/start.sh script in the following places:
Now, all pods come up but tuf-keyserver-daemon is complaining it cannot renew the vault token. HttpResponse(403 Forbidden,...{"errors":["permission denied"]}. The same error is returned when tuf-keyserver attempts to access the vault.
I can connect to tuf-vault using 'kubectl exec -it "tuf-vault-xxxx" -- sh' and can issue vault commands. I have, for example, unsealed the vaults manually and check the software version. However, anything else seems to return "missing client token". There is no curl on the 0.3.0.16 ota-tuf reposerver image.
Not sure what to do here.
Is this software dead?
P.S. I see a helm_migration branch that is far more recent but I could get the ota-gateway-device pod working. I just want something to work. Do not care what branch.