3:50 p.m.
Having (briefly) scanned the emails on this topic, my couple of ZAR 0.20 (20 ZAR cents ==
~ EUR0.01 ~ 1 cent EUR ;) )
When you look at the hypervisor arena, the use cases I'll summarise as follows given
my experiences:
In the sharing environment:
- You have a Desktop - you’ll use Parallels/VMWare/VirtualBox (vagrant for headless vbox)
(Okay, you can and could use libvirt + KVM, but you are already on a GUI and want GUI
interaction/etc.)
- You have a LINUX/debops server with spare capacity and need to run VMs: libvirt with
KVM
(freeBSD: bhyv something in the place of kvm)
Now for dedicated hypervisor(s) on physical baremetals:
- Simple GUI, only a single servers: ProxMox / ESXi (free edition, and it doesn’t do
clustering afaik)
- fun “niche” SmartOS
- a few clustered servers with GUI no auto-allocations: ProxMox + clustering / VMWare
- medium size, auto allocations: ganeti / VMWare
- medium massive scale, auto allocations, USers with own rights and billing: OpenStack /
OpenNebula / VMWare
The “fun” with the OpenStack/Nebula/VMWare/etc. is that you might be installing some of
the controllers with a Debian type OS, the actual storage and compute physicals are not
necessarily a “distro” installation, but their own “thing” to talk to the master(s). I
might be wrong with these, but that was the information I saw last time I investigated
them.
On 21 Jul 2020, at 15:12 , Damiano Venturin <dam(a)venturin.net>
wrote:
On 19/07/2020 16:45, Maciej Delmanowski wrote:
>
> I haven't had a chance to play with OpenStack yet, but I know roughly what it
> is and what it does.
I've seen that I can create vms inside of OpenStack (like one would do
with Proxmox) but how do they play with Openstack components? This is
still a mistery to me.
it’s an auto allocations based on the controllers etc. controlling what/where etc. and you
typically only have block storage you write to… the challenge here: BIG FAT back end
network links, as every disk io goes out on the network
> I'm nore interested in OpenNebula[1] as the
> hypervisor/virtualization layer due to less complexity between the two
> solutions and more focused OpenNebula development[2]. The article linked is
> a bit old so take that into account. OpenNebula seems to be more focused on
> smaller-scale deployments which DebOps excels in at the moment.
I'm interested in OpenStack because of the Enough project
(https://lab.enough.community/main/infrastructure) which, btw, uses
debops. It was Nicolas pointing me at it. The Enough community seems to
have already (successfully?) achieved what I'm trying to do on my own.
Looking at the Enough project “quickly” you might be stuck with an OVH solution as it
seems they cater/work-inside OVH’s tweaks of the stack.. and yes, there are some (I’m
using OVH so I know the “funs” too ;( )
There is a solid chance that I can ditch part or all I've done so
far
and join the Enough project, however the OpenStack is a barrier for me
and it could also a barrier for many others (given the additional layer
of complexity as Imre has noted). The fact that Enough is tight to OVH
is, most likely, a direct consequence of OpenStack too.
Perhaps also ‘cause OVH provides the best bang for buck (compared to AWS/Azure/etc.) for a
public cloud setup!!!
I don’t think it was chosed for the OpenStack, I belive they chose it and just build/used
the OpenStack credentials to fast track the VM creation/etc.
>
> In both cases the installations require a bunch of different underlying
> services to function (MariaDB, RabbitMQ, etc.), management roles for these
> either are already in DebOps, or can be implemented as needed. Then there are
> packages with the software implemented for the OpenStack or OpenNebula
> specifically which could also be added in the project.
Are these specific packages needed to split processes across the
OpenStack components? Nova etc... (I'm guessing here)
I’ll not be surprised that you’ll have to be compiling lots of the stuff yourself too … no
need yet to investigate myself ;(
> I imagine that
> a separate set of playbooks could be developed to aid deployment of
> a production infrastructure in each case, with different types of hosts
> (compute, storage, cpu) instead of the default set of playbooks focused on
> a per-service general-purpose deployment. The debops scripts can be updated to
> acommodate multiple sets of playbooks for that purpose.
>
> There's already the openstack-ansible[3] project that allows deployment of
> OpenStack unsing Ansible; we could see what components are still missing in
> DebOps for it to function and implement them over time.
If I understand you well, debops would take care of both the OpenStack
infrastructure itself and the vms running inside of it
You most probably could, but BEFORE you consider a OpenStack/OpenNebula deployment, ask
yourself these questions:
1) do I need allocation across hypervisors?
2) Do I have the network bandwidth from the compute nodes to the storages nodes?
3) do I have very-very fast storage nodes?
Those are the single factors that’ll make or break your OpenStack/Nebula deployment
Okay: *I* don’t have the ZARs to buy those equipment priced in EUR/USD, neither am I
working for such a company (I’m just a free lance consultant) so I am biased towards
solutions that is not breaking my bank nor clients
> In the end, I think that DebOps as a solid base to deploy
OpenStack,
> OpenNebula or Kubernetes in production environment is a good target to aim
> for. Many of the underlying components are shared, which should make things
> a bit easier.
I do not disagree, I would rather advise that this be a tad sideline project, instead of a
full blown DebOps path, unless there are real needs and people having the budgets for
those equipment “sponsoring” this part of the project ;)
PS: Ansible have ProxMox VM creation stuff lately, and ProxMox does have API etc. to
control it ;)