releases: support enterprise versions

[colinodell]

This pull request allows the installation of enterprise versions by supplying an Enterprise bool flag and an optional EnterpriseMeta string field as suggested in #15 (comment).

---

According to #15 and #16, the ability to download enterprise versions was removed from the public release of this library. It seems this decision was likely made to prevent users from accidentally installing Enterprise versions. However, there are some valid cases folks have the need to automate the downloading of Enterprise versions:

• Automated testing of the Consul API Gateway project against the latest Consul Enterprise binaries
• Preinstalling the latest enterprise versions of binaries on users' laptops (my use case)

With these proposed changes, users of this library can now opt-in to fetching the Enterprise versions as needed, without negatively impacting the ability for OSS users to continue using the OSS releases.

[hashicorp-cla]

All committers have signed the CLA.

[radeksimko]

Hi @colinodell
Thank you for sending the PR in.

This looks like a good start but there is one more aspect of enterprise releases which will need to be reflected before we can merge it in.

All enterprise products should come with two *.txt files - EULA.txt and TermsOfEvaluation.txt in the archive.

After asking internally, I was advised that we'd need to be installing those files somewhere while installing the product binary to alleviate any legal concerns.

This implies some changes:

We can introduce LicenseDir (string) which would be treated as required to let the user to specify where to place the files which contain licensing terms.

Since this brings us to a total of 3 fields related to enterprise, I wonder if it would make sense to instead turn this into a struct, e.g.

type LatestVersion struct {
  Enterprise EnterpriseOptions
}

type EnterpriseOptions struct {
  LicenseDir string // required
  Meta       string // optional
}

The code responsible for the installation would need to be updated to reflect that we need to install more than just a binary.

I see you updated releases.LatestVersion but for consistency we should add support for enterprise products into other parts of the API as well, i.e.

• releases.ExactVersion
• releases.Versions
• checkpoint.LatestVersion

Finally we should probably update the Readme.md to include an example with an enterprise product so that folks know this is supported and how to do it.

---

I appreciate this may be much more work than you initially planned for, so one of the maintainers (like myself) can probably pick it up and finish the work later if you don't want/intend to. Just let us know.

[colinodell]

Thanks for the detailed feedback! It is indeed more work than I had anticipated, but I'd be happy to take it on with your guidance :)

After asking internally, I was advised that we'd need to be installing those files somewhere while installing the product binary to alleviate any legal concerns.
...
We can introduce LicenseDir (string) which would be treated as required to let the user to specify where to place the files which contain licensing terms.

Currently, this PR installs those files into the InstallDir (because of how downloader.DownloadAndUnpack() extracts all files there). So I imagine this implementation would need to check for those license files in InstallDir and move them to LicenseDir. I'll proceed along that path unless you tell me otherwise.

I see you updated releases.LatestVersion but for consistency we should add support for enterprise products into other parts of the API as well

Adding support to the other releases APIs makes sense to me. But in #16 it was mentioned that:

As confirmed internally the Checkpoint API does not reflect Enterprise versioning at all, i.e. it will only ever return OSS versions without the metadata, so that one does not need patching.

Is that still true? If so, I'd propose we avoid touching checkpoint.LatestVersion for now.

[radeksimko]

Is that still true? If so, I'd propose we avoid touching checkpoint.LatestVersion for now.

I forgot about that entirely. I believe that is still true, so yes we can avoid touching that one. 👌🏻

So I imagine this implementation would need to check for those license files in InstallDir and move them to LicenseDir.

Instead of moving the files I think we could just unpack them directly to the appropriate path, i.e. modify this part of the function you mentioned and check for the filename there before deciding where exactly to copy the file from the archive, so we can avoid the additional I/O

hc-install/internal/releasesjson/downloader.go

Lines 169 to 181 in 850464c

	d.Logger.Printf("unpacking %s to %s", f.Name, dstDir)
	dstPath := filepath.Join(dstDir, f.Name)
	dstFile, err := os.Create(dstPath)
	if err != nil {
	return pkgFilePath, err
	}
	_, err = io.Copy(dstFile, srcFile)
	if err != nil {
	return pkgFilePath, err
	}
	srcFile.Close()
	dstFile.Close()

That means we'll need to introduce one more argument to DownloadAndUnpack, e.g. licenseDir string but the rest should be mostly plumbing in places from where we call DownloadAndUnpack.

With all these changes we shouldn't need to worry about compatibility as we're not changing public interface at all nor changing behaviour of existing surface.

[colinodell]

I think I've made all the requested changes - this is ready for re-review!

[radeksimko]

Thanks for making all the changes, this is pretty close.

I left mostly minor suggestions and comments. Happy to merge once these are addressed.

[colinodell]

Thanks for your help and guidance here! 🎉