I must apologize for my delayed response, thank-you for taking the time to look into this topic. You guys do make a great product.
TL; DR
Unfortunately, however I cannot do what you ask. I lost that config in a HBA card failure. All said and done, it was a rather catastrophic. As a result, I have spent the last couple of days troubleshooting and now rebuilding the system. I do have an image of the lost data pool, but it’s been resistant to any form of recovery due to lost a partitioning table, damaged sectors, life, etc. I’ll report back if the issue persists after rebuild.
A bit of Humor
What I was able to determine was that the bridge network (lxdbr0) was some how getting mangled without the printed config changing. Running ‘lxc network set uplink dns.nameservers ‘ would resolve the issue, but the config never changed. That seemed so curious to me, it was like there was a ghost config haunting my setup. Looking forward to some paranormal activity; I enthusiastically cued up the X-Files soundtrack on repeat, and with some popcorn I watched one of those “Learn Golang in X hours” videos. As I tried to understand the material, I kept imagining myself as a Ghost Hunter (perhaps I’ll change my moniker). While I was wrestling with the ideas of go modules versus my newb preference for scheduled co-routines… boom! HBA Horror Story! Like Sam and Dean, the unknown monster had come to me and I wasn’t prepared. Hell had broken lose… again!
A bit of Reality
What arose subsequent to the original post and it maybe of some merit for consideration was that the dns handling was continually compromised somewhere between the reverse proxy and the physical nic; and I suspected the bridge. Though this assessment is now overshadowed by the hardware failure.
Like I mentioned in the original post, in every OVN iteration I was able to ping from containers to the internet, but I was not able to download anything; such as the certbot tool as explained above. However, updates to the test http websites were populated as expected. Traffic was getting in but none was getting out.
All the boxes were checked: firewalls, routing, etc. I had diligently followed the instructions on the website, watched @stgraber videos, and I implemented your points from the discussion and thoughts previously explained here, here,and here.
At the time, because I had witnessed the repeated behavior near/during the creation of new OVNs; I had assumed some degree of cause and effect. Typically, I was able to correct this by running the above command.
The last OVN which was right before the HBA issue. Didn’t respond to the command above like the rest. So perhaps, in someway I’ll never fully comprehend, the HBA failure was the contributing factor to the ghost config and the it’s lack response at the end was the last warning?
As mentioned, I am in the process of rebuilding a “like” setup using another HBA controller, and I will build another “like” ovn; the best I can do is report back whether or not the issue persists.
A bit of Wisdom
After all of this, I must comment that ‘self-taught’ means that despite all the setbacks, disappointment, suppositions, and hard learned lessons the person’s passion to endeavor thrives. This diligence is why Edison was able to make the light bulb; without which we would not, as we are, be here and now.
Now, please kindly excuse me while I go off to drown my sorrows…