I am acutely aware of AI limitations. As it seems, AI is not good for anything "original" but it seems to be a somewhat useful tool for polish. In any case, AI still has a long way to go.
I use AI for lots of things but it hallucinates with OMV coding quite often.
I use AI for lots of things but it hallucinates with OMV coding quite often.
I've notice this as well, not with OMV coding but with other things that are detail oriented, but should still be simple, such as "forgetting" a required absolute path. (That one bowled me over.) Inexplicably dropping such details can make even minor shell scripting problematic. As it was explained by one AI, things like that can happen when AI's try to summarize or compress a context, while still within the same context..??
Again, while useful, AI has a long way to go.
Feedbacks:
So, I spent the last 4 hours pretty much rewriting the plugin - https://github.com/OpenMediaVa…86ab3dff45313d349e5a733dc
You can get it here
sudo dpkg -P openmediavault-snapraid-aio # the old version will NOT upgrade properly to this new version. So purge the old one.
wget https://omv-extras.org/testing/openmediavault-snapraid-aio_8.0_all.deb -O openmediavault-snapraid-aio_8.0_all.deb
sudo apt install ./openmediavault-snapraid-aio_8.0_all.deb
I'm sure there is still a ton wrong but that is all I can handle today.
After a lot of work, I have finally pushed the v3.4 stable release for the AIO script.
I can now take on the task to work on this plugin! Thanks ryecoaaron for the initial work.
Hello, long time no see!
In the meantime I have gained some decent experience with Claude Code, and started working on the plugin.
I use AI for lots of things but it hallucinates with OMV coding quite often.
Heck yes: in the beginning I was spending more time fixing bugs introduced by Claude, rather than being productive.
I found my way out of this madness, by creating a ton of "Project Memory" based on the OMV documentation for developers (grateful for its existence).
I've extended the plug-in a lot, below there's a sneak peak.
I think I'm satisfied with the current UX and functionality. Now I have to validate the configs produced by the plug-in, for this I will need some time.
It's in my github repo, forked from ryecoaaron's. When ready, I'll do a PR.
We also need to decide what is the future of this plugin: will it be standalone, but relies on main SnapRAID functionality for arrays, or we integrate it in the main one, deprecating/removing the old script?
Per-config scheduling
Improved notifications
Cleaner UI
ignore_pattern field is flagged as advanced with a misuse warning.Quality of life
/etc/snapraid/ symlinks) instead of the raw config file path.Bundled script
We also need to decide what is the future of this plugin: will it be standalone, but relies on main SnapRAID functionality for arrays, or we integrate it in the main one, deprecating/removing the old script?
I don't think this decision is important right now. The snapraid-aio plugin can depend on the snapraid plugin. This is how the cterm plugin works with the compose plugin. I do want to remove the old script stuff from the snapraid plugin.
Full steam ahead, I also added some commands.
A couple of questions for you ryecoaaron
- Apprise handling Apprise is needed for service notifications, but not strictly required for a bare-bone run. I know users do use it. Its binary is not in `debian/control` Depends/Recommends; enabling Apprise without it fails mid-run with a cryptic error. Should it be added to Recommends? I believe it's needed.
- postrm cleanup Should we delete /etc/snapraid-aio-*.conf files left on disk after plugin removal?
Should it be added to Recommends? I believe it's needed
OMV doesn't install recommends but putting it there with no package in the debian repo makes little sense. Either the plugin should install it or fail with a message to install it when the script wants it.
Should we delete /etc/snapraid-aio-*.conf files left on disk after plugin removal?
Yes.
Alright. The script already handles dependencies via apt, so we're covered.
I implemented deletion of /etc/snapraid-aio-*.conf files on package purge.
One side question: how the snapraid binary is compiled for the main plugin? There's a little issue that bugs me that I want to solve, but the "snapraid" repo is archived.
how the snapraid binary is compiled for the main plugin? There's a little issue that bugs me that I want to solve
Why does it bug you? What are you trying to solve? The plugin is using snapraid 12.4 from the Debian repo. https://packages.debian.org/trixie/snapraid
Why does it bug you? What are you trying to solve? The plugin is using snapraid 12.4 from the Debian repo. https://packages.debian.org/trixie/snapraid
It's just cosmetic, but my script uses it: snapraid -v does not print the snapraid binary version, just prints "none".
I discovered that this issue is actually fixed in Debian Repo for forky which has the 13.0 Snapraid binary.
13.0 is just a bugfix version, we could backport that. Are backports available already?
(14.x is moving quite fast and I would not go on that)
just prints "none".
This was your concern? haha. It has been that way for a long time on my binaries and Debian's. Just use the package version
$ dpkg-query -W -f='${Version}' snapraid
12.4-1
we could backport that.
No. Not have to maintain packages like I did in the past it MUCH better than getting a version number out of snapraid -v.
Are backports available already?
No, snapraid is unlikely to ever be in backports.
(14.x is moving quite fast and I would not go on that)
Well aware. I follow the github repo and have 14 installed on my dev system. I have no plans to not use the Debian provided version.
A quick update.
I've finished adding functionalities: I believe the plugin is feature complete.
I'll be testing the plugin on real hardware for a while, then I'll prepare the PR on the GitHub repo.
I've also prepared a draft documentation for the Wiki.
A couple of highlights:
- Added a "Last Run" column to show last execution result, which is parsed from /var/log/snapraid.log
- Added Apprise test button for notifications and emails.
Development was completed a couple of weeks ago, since then I've tested the plugin on my real OMV NAS.
No issues to report, will open a PR now on GitHub.
Please let me know how to contribute to the Wiki, I have a draft for that as well.
Please let me know how to contribute to the Wiki, I have a draft for that as well.
You have an account on the wiki already.
Please let me know how to contribute to the Wiki, I have a draft for that as well.
This link really helped me learn how to post on the wiki --> https://www.dokuwiki.org/es:dokuwiki
It's simple, but if you need help, feel free to send me a private message and ask whatever you need. You can also ask crashtest ; I'm sure he'd be happy to help you, just like me.
Please let me know how to contribute to the Wiki, I have a draft for that as well.
There's a template that acts as rough guide for a plugin doc.
It's -> here.
It might be easier to copy the existing OMV7 snapraid document (which has yet to be updated for OMV8) into a draft doc, and edit or rewrite the automation section.
Copy the contents of the above into a new document like the following (for example):
https://wiki.omv-extras.org/doku.php?id=docs_in_draft:snapraid
Note that most documents on the wiki are in a basic "walk through" format. If you get too technical, you'll lose readers. On the other hand, sometimes it's necessary to introduce a concept new users are unlikely to know. In that case, you'd need to teach it.
PM me if you need help or, maybe, just some pointers.
You have an account on the wiki already.
Strange, I don't have a password for it. I sent a request to reset it, but never received anything. Can you please reset it for me?
I sent a request to reset it, but never received anything
It doesn't have a real email setup. I will PM the password. Change it right away.
Logged in and changed, thank you!
Don’t have an account yet? Register yourself now and be a part of our community!