[BlueOnyx:23203] Re: Upcoming BlueOnyx 5210R additions

[Michael Stauber]

Hi Ernie,

> Lol at the WoW binge.

Yeah, I was laughing out loud when I read that.

> The change from rpm to .deb is major, but mostly at the package management
> level, once unpacked BX would be fine.

That's true. OTOH I could directly consolidate the package building
process. At the moment our "make rpm" spits out several individual RPMs
for every BlueOnyx module. Like this:

base-vsite-am-1.0.0-0BX03.el6.x86_64
base-vsite-capstone-4.0-0BX48.el6.noarch
base-vsite-glue-4.0-0BX48.el6.noarch
base-vsite-locale-da_DK-4.0-0BX48.el6.noarch
base-vsite-locale-de_DE-4.0-0BX48.el6.noarch
base-vsite-locale-en_US-4.0-0BX48.el6.noarch
base-vsite-locale-es_ES-4.0-0BX48.el6.noarch
base-vsite-locale-fr_FR-4.0-0BX48.el6.noarch
base-vsite-locale-it_IT-4.0-0BX48.el6.noarch
base-vsite-locale-ja_JP-4.0-0BX48.el6.noarch
base-vsite-locale-nl_NL-4.0-0BX48.el6.noarch
base-vsite-locale-pt_PT-4.0-0BX48.el6.noarch
base-vsite-ui-4.0-0BX48.el6.noarch

When I publish an update I always publish *all* RPMs from that latest
build (even if the "locale" files didn't change). When I address the
building of *.deb files I'll therefore do the "lazy" thing and let it
spit out just a single *.deb that contains everything. There may be
exceptions here and there where I might let it build multiple *.deb's,
but that would already greatly simplify the process.

> From a credibility perspective, Ubuntu 18.04 LTS would be an obvious choice, a major
> upgrade every 2 years with 5 years support, that would be the closest thing to RHEL in the debian
> world, but Debian itself runs some heavy duty stuff eg. Proxmox which is
> pretty stable and can take a hammering in data centers.

The LTS support of Ubuntu is indeed very nice and I've been on it since
12.04 for my desktops and the laptops. For 16.04 -> 18.04 I also did an
in-situ upgrade (fully prepared to have to do a full reinstall), but it
also went surprisingly well without any hitches.

But I'm not convinced Ubuntu is really good enough for data centers or
that they take security or enterprise levels of uptime seriously enough.
There has been a period not too long ago where they released a new
kernel every day or two. That prompted me to look at what they actually
were changing and the changelogs read like amateur-hour on a grand
scale. Fix X, fix for fix X, rollback to Y, backport Z to cover problem
X and Z, then fixing the things that the backport broke. Design wise I'm
also shaking my head about a few decisions they made which go beyond a
matter of taste and preference. Like the perverse and pervasive usage of
Snapd containers for applications that should have been rolled out as a
normal package instead.

Example from my workstation:

mstauber at beast.smd.net:~/$ mount|grep snaps|cut -d \  -f1|sort
/var/lib/snapd/snaps/canonical-livepatch_81.snap
/var/lib/snapd/snaps/chromium_849.snap
/var/lib/snapd/snaps/chromium_853.snap
/var/lib/snapd/snaps/core18_1098.snap
/var/lib/snapd/snaps/core18_1144.snap
/var/lib/snapd/snaps/core_7396.snap
/var/lib/snapd/snaps/core_7713.snap
/var/lib/snapd/snaps/discord_91.snap
/var/lib/snapd/snaps/discord_92.snap
/var/lib/snapd/snaps/discord_93.snap
/var/lib/snapd/snaps/gnome-3-26-1604_90.snap
/var/lib/snapd/snaps/gnome-3-26-1604_92.snap
/var/lib/snapd/snaps/gnome-3-28-1804_67.snap
/var/lib/snapd/snaps/gnome-3-28-1804_71.snap
/var/lib/snapd/snaps/gnome-calculator_406.snap
/var/lib/snapd/snaps/gnome-calculator_501.snap
/var/lib/snapd/snaps/gnome-characters_296.snap
/var/lib/snapd/snaps/gnome-characters_317.snap
/var/lib/snapd/snaps/gnome-logs_61.snap
/var/lib/snapd/snaps/gnome-logs_73.snap
/var/lib/snapd/snaps/gnome-system-monitor_100.snap
/var/lib/snapd/snaps/gnome-system-monitor_95.snap
/var/lib/snapd/snaps/gtk-common-themes_1198.snap
/var/lib/snapd/snaps/gtk-common-themes_1313.snap
/var/lib/snapd/snaps/lxd_11727.snap
/var/lib/snapd/snaps/lxd_11824.snap
/var/lib/snapd/snaps/lxd-demo-server_87.snap
/var/lib/snapd/snaps/lxd-demo-server_92.snap
/var/lib/snapd/snaps/ncdu-kz6fittycent_18.snap
/var/lib/snapd/snaps/nutty_10.snap
/var/lib/snapd/snaps/tor-mkg20001_13.snap
/var/lib/snapd/snaps/tor-mkg20001_5.snap

Why are Discord or Chromium Snaps? The bloody desktop Calculator as
well! And why did the update procedure not remove the outdated Snaps?
That's wasteful and looks disorderly. In fact it's outright lazy and
makes security audits a pain in the butt. Installs from RPMs and DEBs
can easily be verified for integrity, but with Snaps you're buying the
cats in the bag.

> I too have been thinking about how to decouple the base layer of BX and use
> containers to deliver the services. I think it's totally viable, it
> partially addresses HA with things like swarm, and containerization seems to be the direction
> enterprises want to go, rather than the monolithic setups we are use to.

Indeed. There are some interesting possibilities around. As for either
Kubernetes or Docker Swarm? They both have their advantages and
disadvantages:

https://thenewstack.io/kubernetes-vs-docker-swarm-whats-the-difference/

But like you said: That's a whole new world that needs to be mastered
and custom tailoring BlueOnyx for that would be a major undertaking. I'm
not ruling it out, but it's something for later.

In the meantime I'll invest some time into adapting the build
architecture for Debian 10. If need be the rest of the BlueOnyx 5210R
code base could be adapted for a Debian version as well if we ever want
to or need to pursue that road.

-- 
With best regards

Michael Stauber