- Created conditional to parse new TrueNAS 13 version.
- Created conditional to check for a 200 and that the Content-Type is
text/html so it will change to v2.0 of the API's. This is new behavior
in TrueNAS-Core 13.
- Add the true path to the debug statement when comparing targets.
- Add patch set for ZFSPlugin.pm for Storage lib 7.1-1
- Add patch set for pvemanagerlib.js for pve-manager version 7.1-11
- Add patch set for apidoc.js for pve-docs version 7.1-2.
- Create stable-7 directory for future installs based on Proxmox major
version each modules version.
- The eval{} block was originally returning a value that would allow
execution in the $@ conditional. This changed between Proxmox 6 and 7.
Why, no idea at the moment. Also, the original HASH was no longer valid
as a variable. I don't like the code block at this moment, I need to do
some regression testing to Proxmox 5 and FreeNAS/TrueNAS 11 and 12 to
see if I can clean up the conditional block. It was there for a reason I
just don't know at this moment.
- Added a '}' at line 515.
- Fixes issues reported in #98 abd #75.
- freenas-proxmox-packer also fixed. The stable build directory somehow
was moved to the development building directory.
- Adjusted Regex to parse the current TrueNAS-SCALE product and
versioning. Also changed the FreeNAS and TrueNAS so releases will be a
variable (e.g. - U, BETA, RC, MASTER)
- Used the $product_name to change use either a slash (/) for
FreeNAS/TrueNAS-CORE and a dash (-) for FreeNAS-SCALE.
- Under a certain condition, the variable $freenas_rest_connection would
not be defined resulting in a perl ‘blessed’ error. Added logic to see
if a variable is being passed in the @_ and use it, else use
$freenas_rest_connection.
- Use caller (1)[3] instead of passing the function name through the @_.
- Just addign a 'last' statement once an extent is found. No since
looking for more after the extent is found because there is no more.
Should make plugin run a bit faster.
- When cleaning up code from last commit, I removed a line from the
run_lun_command that initialize the code thinking that the way it would
work would be throught the freenas_api_check when calling the
freenas_api_call. Well certain procedures from the Proxmox ZFSPlugin
call procedures that do not have the $freenas_api_methods variable set
yet because freenas_api_check has NOT been called yet. Inserted the
freenas_api_check() in the run_lun_command() to get the variable
initialized. Fixes#62 and other tests that I found to have this issue.
freenas-proxmox-2.0.0-0beta4 will also have the fix.
Kevin Scott Adams
Kevin Scott Adams
Hans
Quinn Wood
sontru
Hans
Tristan Lostroh