OctoPrint / octoprint-docker

The dockerized snappy web interface for your 3D printer!
GNU General Public License v3.0
470 stars 224 forks source link

documentation on methodology for plugins and updates using dockerized octoprint #22

Open LongLiveCHIEF opened 4 years ago

LongLiveCHIEF commented 4 years ago

see #10 and #20

GitIssueBot commented 4 years ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/how-to-retain-plugins-when-updating-recreateing-docker-image/3174/14

RyanBalfanz commented 4 years ago

This is not an issue in my fork of balena-io-playground/balena-octoprint: https://github.com/balena-io-playground/balena-octoprint/pull/4#issuecomment-616943072

LongLiveCHIEF commented 4 years ago

@RyanBalfanz can you elaborate? I took a look at your fork, but didn't see how it's doing anything different. In fact, it seems you're suggesting the same thing I am, in keeping plugins separate from the docker image.

Feel free to hop on #octoprint freenode irc and chat also. I know there hasn't been much public activity on this repo the last 2 weeks, but I've been doing a lot of work on this behind the scenes around this one.

RyanBalfanz commented 4 years ago

@LongLiveCHIEF I'm not sure what you're actually suggesting because there are no code/documentation changes that I have seen to review. I mostly just wanted to get my PR in front of people who might not already be familiar with Balena.io (formlerly Resin.io) as it is a simple and convenient way to deploy OctoPrint.

Balena.io is "device deployment and management infrastructure" so while you might in the end be suggesting something similar, the implementation will be different. Over at my PR I haven't changed anything about OctoPrint itself. Documentation changes are probably irrelevant too, as my solution just works in the Balena environment. I'm just invoking the server in a way that enables the persistence, and creating the appropriate places in the filesystem to support the invocation options.

LongLiveCHIEF commented 4 years ago

@RyanBalfanz the biggest change we've made is multi-arch support. might want to take a look and see what yo ucan adopt for balena's project. This includes the latest versions of ffmpeg, which i'm not certain you get when installing through package manger. (Last time I tried i got v2 ffmpeg instead of v4.)

OctoPrint itself acts as a plugin supervisor, making it possible to upgrade plugins. This is a grey area when it comes to docker, because it's a process wrapper and not a full virtual machine.

The documentation I'm going to be focusing on here is going to target the approach that will be most stable to our end users, and I'm still testing that one out.

In the end, the big decision or recommendation will be answering the questions "should i upgrade octoprint/plugins by pulling/building a new image, or should I let octoprint update itself once I spin it up the first time."

RyanBalfanz commented 4 years ago

@LongLiveCHIEF Got it. I dropped installing ffmpeg recently, at least in my current PR because I planned to later use a multi-container app with their balena-cam WebRTC to drive the webcam feature in OctoPrint, rather than a solution such as running Supervisor to manage both the webcam (e.g. raspivid + gstearmer|ffmpeg|vlc, WebRTC, etc.). This feels like the right solution, although multi-containers are a paid feature for balena, so I might just fall back to Supervisor anyway, or publish both options in separate repos.

Their master branch, which does't seem to get a lot of attention, doesn't natively support a webcam anyway, as far as I know given the way it's designed. It's rather barebones and not super usable (e.g. plugin persistence, webcam, etc.), which I why I stopped using it in favor of OctoPi for a while. This is because of the same reasons you mention above, because it's a docker container environment. But I like using balena, and wanted to go back, hence my increased attention to my fork and changes there.

I have also folded into my changes the beginnings of a multi-container balena app, but thought that would be a separate PR so they are not pushed yet. I might just need to consider their project defunct and start a proper hard fork, rather than just relying on them to merge to master and me to follow along from there on my personal fork.

RyanBalfanz commented 4 years ago

As for balena-cam, this is not explicitly documented, but it also supports mjpeg as a fallback to WebRTC. I believe that will work fine with OctoPrint.