Allow building and installing on unsupported architectures and OSes

[blag]

One of the reasons it's so difficult to add support for new OSes is that our scripts like to check for unsupported operating systems and bail. So if you are just trying to check if ST2 builds or installs on a newer OS version, there's a lot that you have to update.

This slows down development and growth of the platform, even when there is community interest.

Instead of throwing an error message and exiting, like we do in multiple places:

• st2_bootstrap.sh architecture check
• st2_bootstrap.sh RHEL check
• st2_bootstrap.sh Ubuntu check
• st2_bootstrap.sh check for other OSes
• st2bootstrap-deb.sh check for Ubuntu version (which comes from this part of the template file)

Instead of forcibly preventing our users from doing something unsupported, I think we should relax these checks to just issue warnings, but continue. We could even pause the script when it detects an unsupported environment and force users to hit enter or something so that they are absolutely aware that they are using it on an unsupported OS.

But I think forcibly preventing users from trying out new things at this point is silly and slows us down. We're no longer a product, we're a project, and we should allow users to use the project in unapproved or unsupported ways.

[cognifloyd]

Possible message:

WARNING! Your mileage may vary. We only test on x86_64 with CentOS 7-8 and Ubuntu 16, 18, 20. This may or may not work on [your platform]. If you proceed, you are in uncharted waters - so please let us know how it goes.
Do you still want to install? [y/N]

[arm4b]

I think we discussed relaxing the EL check so the rpm package could be installed on CentOS, RHEL, and also Oracle Linux. That makes sense to me and I hope someone would submit a PR to actually see how that works. Are there any other examples you may think of?

What I've seen from the past issues:

• force installing the Ubuntu package under Debian and it failed on systemd
• using OL6 instead of EL6 and having some random st2 python runtime issues
• using stackstorm amd64 package under the ppc64 and it failed
• building st2 from sources under the arm arch and it failed
• unable to add debian buster as it relied on py3.7 and Mongo 4.2
• U20 needed python 3.8 and Mongo 4.4
• EL8 needed a lot of pip hacks and cryptography at a package build time
• EL6 had a bunch of issues and corner cases we had to hack

So theoretically I'm cool with the idea, in practice it's different.
The packages we build are tightly dependent on the build environment. Eg. when building under U18 amd64 the package has very specific linked libraries and versions it relies on from that OS flavor and arch.

It's never just about relaxing the curl|bash installer. Someone needs to do the actual work and research. I believe the work @nzlosh is doing highlights the effort level required to add the new OS.

[blag]

Right, relaxing the curl|bash installer is only one piece of it.

[arm4b]

Even though, I'm good with adding the new flag to the installer to skip the OS check 👍
Let's do it with the warnings and similar mechanism we did before for insecure python3 ppa under the U16.
https://github.com/StackStorm/st2-packages/blob/32105b12c4b1274c3ca0e5977182f35671f177a2/scripts/st2bootstrap-deb.sh#L122-L140

Let's talk practically. What's your use case exactly, and what triggered to create this topic so we can help?
Do you want to install the amd64 package under the arm architecture?

[blag]

I don't really have much time to do much of anything, but I think there's a good market out there for an automation platform that people can run at home, and I think StackStorm can fill that role pretty well...if it can run on Raspberry Pis (read: arm). So enabling other people to explore that niche might work well for us and get users and contributors from a different source than corporate or enterprise contributions. And Python's wheel packages make running packages that wrap binary libraries much easier to work with (to the point that, when things go well, you may not even be aware that you're running a wheel package).

But there's also the argument that, maybe somebody really wants StackStorm, but wants to run it on Gentoo, or Debian, or something else, and they're willing to figure out all of the library/Python packages they need to install to get it up and running. Do we really care to maintain our code that blocks them from doing that? I think that's just kind of dumb. We advertise pretty well the limited number of OSes that we support, so I think that people who are going "off the reservation" know and accept what they're getting into without us manually blocking them with our installers, but emitting a warning and a "click through" (not really anything to click, it's more of a hitting the enter key, but you get my point) is a good compromise.

I do think that we don't need to respond to an explicit y/n choice though, and doing so then opens up the discussion about what we want the default to be, and I'd prefer to avoid that discussion entirely here. I think if we just pause the installation when we detect a non-supported OS/architecture and require the user to just hit enter to continue or hit ctrl+c to stop it that would be fine.

But I think this raises a fundamental question: how much effort do we want to put in to preventing people from running StackStorm in unapproved situations?

When we were a for-profit team working on a product, I thought a good amount of effort was appropriate. But now that we're an open source project, it just seems like we're needlessly throwing up roadblocks for people for essentially no benefit for us.

To turn this back around: what use case does the current code, the code that blocks installation in unapproved environments, have?