Make Teslalogger easier to deploy through containers (for non-techies)

[tfenster]

Hello,

first of all, thanks a lot for an amazing job when creating Teslalogger! I came across it this week and after some initial struggles the setup went very well and I wrote a short blog post about it (https://tobiasfenster.io/running-teslalogger-with-portainer)

However, I would have some ideas how the setup could be improved. I want to prefix this with two things: 1) I basically have no clue about the code base, so you might have very valid technical and/or "philosophical" reasons why you don't want to go the way that I propose and 2) as you have certainly spent an insane amount of time on this, you have every right to just decline or ignore my proposal. I just want to offer help, but if you don't want or need it, no issue at all. Here is what I would like to do:

• Most importantly, having versioned images on the Docker hub would be a great improvement imho. My idea would be to create them automatically whenever you create a tag / release. I have done this dozens of times for other projects, so I am very confident that I could make this work.
• The setup steps to copy the connections string into the setup file and create the GrafanaDashboards folder could be automated
• With those changes, we could make the docker-compose file based deployment a bit easier to use for non-techies (no git clone, no docker-compose build)
• If we want to take it even further, we could use Portainer app templates (https://docs.portainer.io/v/ce-2.11/user/docker/templates), which could allow an easy, wizard-like deployment (https://docs.portainer.io/v/ce-2.11/user/docker/templates/deploy-stack)

In the sense of full transparency, I am a Portainer ambassador (https://www.portainer.io/ambassador-programme?hsLang=en), which is a non-paid community program by Portainer.

If you are interested, I would be happy to provide a pull request for those changes. But again, if you are not interested, also no issue :)

Thanks again for a great piece of software!

[jdelker]

@tfenster: I'm feeling with you. Unfortunately, your suggestions have not been considered so far, even after more than two years you've posted it. Being a software developer myself and managing other containerized applications, I would like to give this a comment.

First of all: I've used TeslaLogger for quite some time already and really like the functionality it is providing. So big kudos for that!

From an operational side, this hasn't been a great experience, though. @tfenster has already mentioned the major pain-points causing that.
I've started several attempts to apply required project modifications so that the docker stack conforms to standard design principles - unfortunately to no avail. Each time, I got lost in complexity, resulting in far too many project changes.

The main reasons for that from my perspective:

• The project has no reproducable and consistent build/development system.
• The project mixes development and runtime environment. Running the docker compose stack, actually alters the project - an absolut no-go.
• There is no seperation of code, config and variable (eventually temporary) data.
• The generated container images do not represent a particular TeslaLogger release but only provide a (code-less) runtime-framework. An image shall represent (and contain!) a particular release.
• There is an implicit update mechanism, which downloads a remote master.zip and applies that to the running container, despite of the current repository state the container is running on. Updates shall only provided through updated container images.

My attempts to address those issues myself actually failed, due to the complexity and my admittedly inexperience with .NET specific projects. Thus, I will be unable to provide any pull requests so far.

Final words:
I'm thankful this project exists. It has given me very interesting insides to my Tesla.
From a development and design perspective, I'm somewhat dissapointed and actually surpised how it evolved to this state.
Please take this as constructive feedback. It's not ment to be offensive in any way.
I would bet, that the project would benefit significantly from a more cleaner and structured setup.

[bassmaster187]

It seems like I missed this topic. Sorry for that.

Before I started to make a bunch of changes for the Fleet API, because Tesla told us they will shut down the unofficial API, I started a new .net8 branch. This one has moved from mono to the .net8 framework. It has a build system and also deploy to docker hub. It is pretty much everything you both are missing. There are some minor changes I have to do with the fleet API and after that I want to focus on .net8 with docker images. Right now I'm in vacation, but I get back next week.
I could try to merge everything to the .net8 branch and you can give it a try. I'm happy to get feedback.

[tfenster]

great, happy to take a look at that