[Harvest Source RPM]

[quartz cosmos]

My team is trying to automate the installation of Harvest with Puppet and for that we

• need the RPM available in a yum repository
• or the source RPM to compile the final RPM ourselves
• or the tarball for the x86_64.rpm architecture

That way, we can re-use your work and we wouldn't have to compile Harvest ourselves.

Observation: You are providing the RPM already for x86_64 but not the tarball for that same architecture.

Do you think any of these options are possible? Thanks in advance.

[scarlet sonnet]

Mmm, what’s a tarball for a rpm ?

[slender karma]

hi @quartz cosmos compiling Go applications is pretty straightforward. Can you provide more details on bullet 2 and 3. I see lots of info on building an RPM from a local tarball but I think you're asking for something else

[still cradle]

Hi @slender karma @scarlet sonnet
I am working with @quartz cosmos in my team. Sorry for jumping in the discussion.

Basically we are looking for a way to install Harvest, via RPM (we use RHEL based servers) in a way that we don't need to wget your RPM from GitHub.
For that we see several options:

• You provide the RPM in a public yum repository (not sure if you have one in NetApp?)
• We compile the RPM ourselves from sources

About the second point, I agree with you that compiling the Go application should be simple. For that, we would mirror you repository and add in our CI the compilation instructions to generate the binaries and the final RPM.
But, this would mean, for each release, to keep an eye and make sure that nothing has changed in the compilation process that you do.
In the other hand, for each release you are already compiling the application and providing 5 artifacts (https://github.com/NetApp/harvest/releases/tag/nightly):

• DEV package for amd64
• RPM package for x86_64
• Compiled tar for amd64 (used to create the DEV package)
• Source code (both in zip and tar.gz)

As you can see, the compiled tar for for x86_64 is missing.
If you provide that, we could just generate the final RPM ourselves in a very simple manner (following your spec file https://github.com/NetApp/harvest/blob/main/rpm/spec) and integrate it in our CI/CD and yum repositories.

So, do you think you can either expose your RPM via a public yum repository or provide the compiled tar file for x86_64?

Thanks a lot and let me know if something is not clear!
Borja

[slender karma]

thanks for the detailed response @still cradle
One clarification, you said "the compiled tar for for x86_64 is missing". The harvest-24.10.03-nightly_linux_amd64.tar.gz that you linked to there is what you are looking for. The x86_64 artifacts are the same as the amd64 ones. The provided harvest-24.10.03-nightly_linux_amd64.tar.gz will work in your rpm spec

[still cradle]

Thanks @slender karma ! You are totally right.
It just just a matter of having a clean process: as part of the RPM compilation process (following the spec file I linked above) I untar the file and the first folder in the structure contains the arch:

$ tar xvfz harvest-24.10.03-nightly_linux_amd64.tar.gz -C ./opt/
harvest-nightly_linux_amd64/
harvest-nightly_linux_amd64/bin/
harvest-nightly_linux_amd64/bin/grafana
harvest-nightly_linux_amd64/bin/harvest
...
...
...

That tar is generated for the specific architecture and includes that in the top-level folder of the package. (This comes from https://github.com/NetApp/harvest/blob/main/rpm/build-rpm.sh#L86) So this wouldn't match the naming of the RPM_BUILD_ROOT macro when building the RPM for x86_64 and this will fail: https://github.com/NetApp/harvest/blob/main/rpm/spec#L49
I will need to rework a bit the process to ignore that folder naming and inject the contents in $RPM_BUILD_ROOT/opt/harvest

Thanks!

[slender karma]

Sounds like you're all set. Any changes you need from us? Would it be possible to wget the rpm published on GitHub from the CI machine and add that RPM to your yum repo?

[still cradle]

Unfortunately, we use Koji to create RPMs and publish in yum repos and technically it is possible to import RPMs already compiled into Koji, instead of building from sources, but that requires full admin rights in Koji. The Koji instance we have is centrally managed in our organization and myself as a user, I don't have that right. All our yum repos are driven by that Koji instance.
Ideally, we could modify a bit your logic so the tar file doesn't include the top level folder and the spec file is not responsible of deploying that tar file but just copies the binaries into the target folder.
If I make it work over here, I can share with you the spec file.

Thanks for your help.