Allow user to attach resource file directly in vendor provided format

[dashmage]

As a UX improvement, it would be simpler for the end-user to directly attach the vendor provided CLI resource file, say a gzipped tarball instead of having the user to extract, unzip and find the right binary for the linux architecture before attaching it. The hardware-observer charm could instead do this work and pick out the binary from the attached tarball resource file.

[jneo8]

I trend to disagree of this because not all the zip file in different versions have the some file structure. For example StorCLI zip have more than 4 different file structure as I know. The effort is too big than the benifit if have. Imagine user have to implement the parse function when they want to support a new version which have a new file structure.

[dashmage]

Even if the zip files don't have the same structure, we will know beforehand which version(s) we are planning to support and could focus on that. I also don't believe the effort would be too great to search through the unzipped path recursively and find a deb package file supporting the x86_64 architecture (maybe through the glob package).

[jneo8]

Even if the zip files don't have the same structure, we will know beforehand which version(s) we are planning to support and could focus on that. I also don't believe the effort would be too great to search through the unzipped path recursively and find a deb package file supporting the x86_64 architecture (maybe through the glob package).

Some old versions of the tool have the nested zip structure and I already see so many different file structure when implement the checksum feature. So in the end we somehow need to define so many different parser for those zip files. If we implement this, yes it will be convenient but it cause a lot of maintain effort and also increase the difficulty to add a new version.

I believe the download link already cover the hardest part of providing resources. Unzip and find the target resource file doesn't really that hard for a cloud admin.

One more disadvantage is that I don't will to put unnecessary files on the server. So another clean resource logic is needed.

Overall the effort is much higher than the benefit if have.

How do you think?

[dashmage]

We would only need to implement a single parser with functionality to parse through most file structures and find the required deb package. Maybe we could try to find a generalized solution for this problem so that it doesn't need to be changed each time a new tool with a different file structure is added.

I believe the download link already cover the hardest part of providing resources. Unzip and find the target resource file doesn't really that hard for a cloud admin.

I agree, the issue is only meant as a UX improvement. The current way of doing things isn't particularly problematic :)

One more disadvantage is that I don't will to put unnecessary files on the server. So another clean resource logic is needed.

The extracted tarball (as opposed to just the deb package) might just be a couple of MBs larger which is alright I think. We can perform their removal along with the charm's regular cleanup procedure as an additional step. I don't think there's a lot of complex logic involved here tbh.

Overall the effort is much higher than the benefit if have.

If you think that's the case then we can choose to skip this improvement. It would only save the user an extra step to extract, unzip and figure out the right resource to upload.

[Pjack]

I also have concern to implement this feature. There is no specification of the zip file. I put this issue as low priority and get more feedback from the user in the future

[Pjack]

I haven't received any additional requirements for this task. I've decided to close it for now, but if someone brings up the same requirement in the future, we can revisit it then.