Improve IP address resolution

[tideline3d]

I run all my Octoprint instances on a Docker Compose setup using a fork of the Octoprint official Docker image. I was having errors starting Continuous Print because it couldn't resolve the local IP address using the mDNS lookup approach.

2022-10-18 22:22:06 socket.gaierror: [Errno -5] No address associated with hostname
2022-10-18 22:22:06 return socket.gethostbyname(hostname)
2022-10-18 22:22:06 File "/octoprint/plugins/lib/python3.8/site-packages/continuousprint/plugin.py", line 135, in get_local_ip
2022-10-18 22:22:06 local_ip=self._plugin.get_local_ip(),

I posted this problem in #support-plugins on the OctoPrint discord and jneiliii suggested the change in this PR. It's used in another of his plugins here: https://github.com/jneilliii/OctoPrint-ipOnConnect/blob/4743a1ff71cc090f00f353bffe32213d2a13e8a2/octoprint_ipOnConnect/__init__.py#L39

This works for me, thought I'd pass it along and see if this makes sense up stream. I was expecting LAN queues to not work if I was having mDNS resolution troubles, but it's working great as well.

[smartin015]

Cool, thanks for the contribution! And I'm glad the mDNS code is holding up alright. As a bit of a teaser, I'm currently working on a version of network queues that uses the same backing infra as IPFS, go-eth etc. It'll support both mDNS and DHT (i.e. WAN) discovery.

The use of list comprehension is a bit... excessive, but the function is self-descriptive enough that it's probably fine for human comprehension :)

[tideline3d]

Nice! I'm probably going to take a different approach and just push to local queues from somewhere else via API (already have this going, test prints running now). I print everything for inventory (no queue of customer orders) and my main focus is setting up a job to use up an entire spool with as little waste as possible. Planning to have a few templates I can just push to a printer or shelf of printers.

Also my printer's OP instance is ephemeral, I push a config out to them with Balena.io and keeping local databases doesn't really work with that flow, they get deleted every time a printer reboots or gets a new deployment. I could put them on persistent volumes but still not sure I'll need them for my intended workflow. If interested, I'll open up a discussion about it.

[smartin015]

Nice! I'm probably going to take a different approach and just push to local queues from somewhere else via API (already have this going, test prints running now). I print everything for inventory (no queue of customer orders) and my main focus is setting up a job to use up an entire spool with as little waste as possible. Planning to have a few templates I can just push to a printer or shelf of printers.

Neat - that approach makes sense, and I know a few other folks who do the same. Do you have any tracking system for inventory management? #57 has been open for awhile to collect integration ideas, but I'm not sure if that's relevant to your interests as most folks I've talked with have very basic (if any) tracking on how much they print / have in stock.

Also my printer's OP instance is ephemeral, I push a config out to them with Balena.io and keeping local databases doesn't really work with that flow, they get deleted every time a printer reboots or gets a new deployment. I could put them on persistent volumes but still not sure I'll need them for my intended workflow. If interested, I'll open up a discussion about it.

Cool, keep me in the loop if you have suggestions. FWIW, the LAN queue implementation holds queues in RAM and "persists" them via replication across hosts, so you wouldn't need actually need PVs to maintain a persistent work queue across all printers in the farm assuming it works with the rest of your automation / push setup.

[tideline3d]

Neat - that approach makes sense, and I know a few other folks who do the same. Do you have any tracking system for inventory management? #57 has been open for awhile to collect integration ideas, but I'm not sure if that's relevant to your interests as most folks I've talked with have very basic (if any) tracking on how much they print / have in stock.

I use Shopify for my main system. But like others said in that thread, I have multiple parts that go to make 1 SKU in Shopify and Shopify's inventory is kinda weak from a kitting perspective. I've toyed with creating 'kits' through some Shopify automations, but honestly thats just too much tracking for me and easy to get things out of sync if I don't keep up with it perfectly.

My main flow for inventory is actually with a 3PL that does all my shipping. I create essentially Fulfillment Orders to myself for things that need to go to the distribution center. I'm kinda leaning towards making that my parent work order. 'Warehouse needs 42 of SKU ABC and 12 of SKU DEF'. ABC requires part x & y, DEF requires x and z.

But I'm taking the agile approach right now, small incremental improvements to the process. Planning out a spool is much better than looking at 24 spools and thinking 'I can probably print X with what's left'. I usually just over-produce on the printers then send to distribution from the shop's supply of parts.

Cool, keep me in the loop if you have suggestions. FWIW, the LAN queue implementation holds queues in RAM and "persists" them via replication across hosts, so you wouldn't need actually need PVs to maintain a persistent work queue across all printers in the farm assuming it works with the rest of your automation / push setup.

I'm just afraid of losing all the data if there's a power loss or something or I deploy to all 24 at once (I usually do after a canary test). Seems to me the queues belong in a higher level 'Farm Management' tool/storage, so that's where I'm heading.