It came up during the „Server reboot“ meeting December 2020. It was
the idea of Matthew,
server and cloud are the same (basic concept), but (implemented) in different contexts.
We
had various short discussions in the first quarter this year and a longer discussion
with
Dusty, March 3
(
https://meetbot.fedoraproject.org/fedora-meeting/2021-03-03/fedora-server...)
and some discussion in various contexts. I wrote a short paper about various options of
possible cooperations and possible synergy effects (e.g. creating / maintaining
documentation and other).
By that account, Cloud is also the same as Workstation and by association, Server is the
same as Workstation.
I wrote a Fedora Magazine article about using cloud generic image als
VM in Fedora Server
(
https://fedoramagazine.org/setting-up-a-vm-on-fedora-server-using-cloud-i...
March 29) and a corresponding guide as part of Server documentation
(
https://docs.fedoraproject.org/en-US/fedora-server/virtualization-vmcloud/).
But that’s history and current opinion is that the two are completely different products.
I think Cloud base images are an excellent compliment to Server in this respect.
Well, I’m not a native speaker, maybe some formulations have a connotation not seen by
me.
Anyway, I (and also Matthew) were accused by some Cloud-WG members that we wanted to
"kill“ Cloud and/or cloud wg. And those members have explicitly stated there should
be and will be no cooperation at all.
Maybe "Bluntly failed“ is not exactly a correct phrasing for that. And of course,
nothing is irreconcilable in my opinion.
of course not, we are all friends here. I think that time resulted in a significant amount
of churn in the cloud group too, so let's return to finding out how we can make this
work. Let me invite you to the cloud meeting where we can have fun conversations.
The word means a replica, but in a different context. So I mean an as perfect a rebuild
of
Fedora Server as possible, not bare metal but in a virtual environment (the details of
„as
perfect a rebuild“ have yet to be decided).
(It’s originally Latin and denotes in the ancient music the opposite voice to the tenor
in
a higher register - sorry, sometimes I get carried away)
:D This makes me happy to know. Thanks.
Yes, I agree. In a server admin you may want to start with kind of thin provisioning. So
I
think, a VM disk image should be distributed as small as (reasonable) possible and let
the
admin choose an initial size (as cloud base image does, if I remember correctly).
I mean, there are many and detailed configuration options, so the resulting disk image
can
be customized very precisely.
The tool has similar issues as virtual-builder. The disk image is created on non-Fedora
infrastructure and imported as binary (what we avoid on package level at all costs). And
it involves a significant amount of work for sysadmin, at least the first time. It is
probably faster to do an Anaconda installation via Cockpit.
Yes, cloud is a different context with different requirements, of course. Cloud WG
creates
several variants, including a base image as a generic VM image for a generic virtual
machine (according to the download page description). If we were to cooperate, we could
build this variant or another one to fit Fedora Server perfectly - using Cloud WG's
knowledge and skills instead of building something ourselves. And in return server wg
could do something that would be useful for cloud as well.
I won't lie, I think this is going to basically end up reinventing the cloud
edition, but the activity sounds like it's worthwhile to determine the end result.
That was the basic idea at the beginning of the year. But that
"has bluntly failed“ -
so far at least.
I think that we are all going to have to keep an experimental mindset and not get caught
up in our conventions to make this successful. What comes out on the other end may not be
the server you need on iron.
As far as i know they distribute several deliverables, for cloud, for VM and for bare
metal.
Platform specific changes are the big deliverables here. Cloud ends up being one
thing with these platform-specific modifications, like Google's agent or Azure's
OMI, etc. DNS changes and time service modifications. It's also a fabulous base for
the container and vagrant images. With btrfs now, it empowers lot's of action around
layering and snapshot management without the overhead of LVM on an already virtual volume.
I'm excited for the future.
It perfectly replicates a standard installation with Anaconda. You get a Fedora server
build as VM like a full Anaconda installation, same software, same file system, same
management tools, firewall, cockpit, etc.. If you don't know, Sysamin doesn't
notice if he is on the server installation or in the VM.
I think that's a great experience. I spent a lot of time installing and reinstalling
Red Hat Linux on an ancient Poweredge while I prepared for my first RHCE. It certainly
would have been nice to have virtual machines that weren't complicated chroot
environments back in that time that matched my process.
Many thanks for all your information and hints.
Nothing like working together and enjoying the understanding and the results that come out
of that. It's why we do this. If we learn to work together better, we win.