Omada SDN Controller - Packaging Inconsistencies

Omada SDN Controller - Packaging Inconsistencies

Omada SDN Controller - Packaging Inconsistencies
Omada SDN Controller - Packaging Inconsistencies
2024-07-26 17:26:29
Hardware Version:
Firmware Version:

As someone who is needing to rely on automation for deploying the Omada SDN controller on Linux using the tarballs, I often run into packaging inconsistencies that require me to put all sort of workarounds in place for specific versions of the software, whether it is GA or beta. It makes me think that there isn't any sort of standard automation in how the Omada Controller software is being packaged and it seems like it could benefit from at least some sort of standard packaging scripting or Makefile executable packaging to provide a consistent experience for users.

 

Filename - the filenames are inconsistent which means having to handle different filename.
Mostly, the GA versions are fairly consistent (Omada_SDN_Controller_v<version>_linux_x64.tar.gz) although there have been some differences in case (linux vs Linux) but the beta versions are all over the place as .tar.gz, zip, tar, etc. You can see that here from the saved URLs I've put together for different versions (https://github.com/mbentley/docker-omada-controller-url/blob/a8d0d34f6655431cbf09dded560daed22d7b5c51/omada_ver_to_url.sh#L99-L110).

 

The latest beta also change the filename's version format to not include a "v" in front so the version detection I had put together needed to be reworked to deal with that scenario (https://github.com/mbentley/docker-omada-controller/blob/dc64805e30a32a1078b982813642850108cae0ab/install.sh#L38-L44).


Directory structure within the archives -
This monstrosity (https://github.com/mbentley/docker-omada-controller/blob/dc64805e30a32a1078b982813642850108cae0ab/install.sh#L144-L205) is needed to handle all of the possible file types, file names, and if there is a tarball inside a zip, a file inside a directory, a file directly in the tarball, etc. Again, this seems to be especially bad with the betas and more consistent with the GA versions but in my case, I am trying to handle both the GA installation and beta installation within a single script so changes to the beta process mean a potential for breaking something that previously worked in a GA version.

 

If some of those things could be improved upon to become more consistent, it would certainly make adopting new versions of the software much easier.

  15      
  15      
#1
Options