Ganeti Usage Survey

[Rudolph Bott]

Hey Everyone,

we - the Ganeti orga team - kindly ask you to help us improve our understanding of the current usage of Ganeti. Please fill out the following survey which should take less than a minute to complete:

  https://forms.gle/Ed5eKJaExmD854GF6

We will keep this survey open until the end of October 2020 and publish the results to the Ganeti mailing lists. This should provide us with insights which features are frequently or less frequently used and hence influence the development of Ganeti in the future.

Thank you for your time!

Cheers on behalf of the orga team,

Rudi

[Sedat Dilek]

Thanks for the survey, Rudolph.

I see several items in German like "Erforderlich" (Required) and
"Sonstiges" (Misc)?
Might depend on the localisation setting in Google-docs?

Regards,
- Sedat -

> --
> You received this message because you are subscribed to the Google Groups "ganeti" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/CAPG4N%3DYo3zNUsHcaYvdg%3DBg3-kLr%2BZf8W0hzKvF9qT9pjunkYw%40mail.gmail.com.

[Rudolph Bott]

Hi Sedat,

On Wed, Oct 7, 2020 at 12:30 PM Sedat Dilek <sedat...@gmail.com> wrote:

I see several items in German like "Erforderlich" (Required) and
"Sonstiges" (Misc)?
Might depend on the localisation setting in Google-docs?

Yes, I think this is due to localisation/browser settings. I realised just now that my system has an english localisation and therefore did not even think about it :-)

Cheers,

Rudi

 

Regards,
- Sedat -

On Wed, Oct 7, 2020 at 12:24 PM Rudolph Bott <bo...@sipgate.de> wrote:
>
> Hey Everyone,
>
> we - the Ganeti orga team - kindly ask you to help us improve our understanding of the current usage of Ganeti. Please fill out the following survey which should take less than a minute to complete:
>
>   https://forms.gle/Ed5eKJaExmD854GF6
>
> We will keep this survey open until the end of October 2020 and publish the results to the Ganeti mailing lists. This should provide us with insights which features are frequently or less frequently used and hence influence the development of Ganeti in the future.
>
> Thank you for your time!
>
> Cheers on behalf of the orga team,
> Rudi
>
> --
> You received this message because you are subscribed to the Google Groups "ganeti" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/CAPG4N%3DYo3zNUsHcaYvdg%3DBg3-kLr%2BZf8W0hzKvF9qT9pjunkYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/CA%2BicZUWUPaHcMoHZHgXWpXg-FQGyhbdqv1fHgDQsuJWepaxXVw%40mail.gmail.com.

--

 Rudolph Bott - bo...@sipgate.de

 Telefon: +49 (0)211-63 55 55-55

 Telefax: +49 (0)211-63 55 55-22

 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf

 HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois

 Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391

 www.sipgate.de - www.sipgate.co.uk

[Rudolph Bott]

Hey Everyone,

surely it is a bit later than what I promised. But last but not least I'd like to provide you with the outcome of the survey. Over time we gathered 50 responses which provide us with quite some insights! Thanks everyone for participating :-) 

I will attach the results as CSV so you can draw your own conclusions if you like to. One important information we can disclose right away: ~80% have no intention to move away from Ganeti and most of the other 20% will continue using Ganeti along with other solutions! There is definitely a public interest in Ganeti and it is worth every minute we can invest into this project to keep it going (and growing!).

Out of the 50 users who have responded, 96% use KVM as their virtualisation technique, while there are also some (10%) Xen users. However, only 4% use Xen exclusively while the others use KVM and Xen at the same time in their infrastructure.

Storage-wise DRBD is the winner (84%), but only 36% use DRBD as their sole storage solution. Most users also use the "plain" disk type along with it but actually every single storage backend has at least one active user (hu, even diskless!):

2.15 (34%) and 2.16 (76%) seem to be the dominant versions out there. That looks promising with regards to a 3.0 upgrade! However, those few 2.5 and 2.11 users really need to get their act together :-) 

Ganeti seems to be popular with Debian/Ubuntu (62%/20%) and CentOS/Fedora (20%/4%) which pretty much sums up my gut feelings on this topic. We should probably throw in some automated testing on CentOS in the future to make sure these platforms do not break.

Please feel free to start a discussion on the results - did anything surprise you? What conclusions should we draw from the results? Personally I am really interested in reports about Gluster and LXC as I actually did not expect these technologies to be in use at all with Ganeti.

Cheers,

Rudi

On Wed, Oct 7, 2020 at 12:24 PM Rudolph Bott <bo...@sipgate.de> wrote:

[Gabriel Filion]

This is really interesting

On 2020-12-08 4:24 p.m., Rudolph Bott wrote:
> Out of the 50 users who have responded, 96% use KVM as their virtualisation
> technique, while there are also some (10%) Xen users. However, only 4% use
> Xen exclusively while the others use KVM and Xen at the same time in their
> infrastructure.

for my part I guess I'm mostly surprised about this detail. Since the
upstream documentation seems to point towards Xen being the main
virtualisation being supported and "some ppl use kvm but it's not the
main thing" while the survey shows interests are in practice the inverse
of that.

[Martin McClure]

At the time Ganeti was first developed, KVM was very new, while Xen had
been around a few years. It seems likely that the documentation was true
when it was written, but the usage has shifted.

Regards,
-Martin

[Karsten Heymann]

Hi Rudolph,

thanks for the analysis of the survey. I hope it's okay to add some personal perspective of ours since we are currently, after many years of using ganeti on more than a dozen of clusters, moving away from using it in production (towards vmware and probably proxmox) and I'd like to explain the main reasons:

1. Insufficient development manpower and stagnant userbase perspective. I think this is quite clear. A tool as complex as ganeti needs a steady stream of new users to attract developers, more users and keep the project alive. I believe there is a small group of devoted groups and companies using it, but I doubt there is relevant growth in the userbase and none of the companies using it can or want to invest real money to sponsor development time in the amount required.

2. No support for cloud-init. Ganeti's instance mechanism is quite powerful, but it requires too much work to support new versions of linux. IMO the only way to go is to deprecate the instance system and replace it with first-class support for cloud-init. This would make it *much* easier to run any linux version on ganeti. snf-image was a very good solution, but the last synnefo release is from 2017 and as far as I understand the main team founded Arrikto and stopped working on ganeti at all.

3. No terraform provider. In 2020 this is a hard requirement for a virtualization solution. It just saves *massive* amounts of time not having to script the setup of a cluster so that the resulting setup is reproducible and to prevent configuration drift. 

Sorry if this is a bit blunt but I really like the project and hope this "exit-feedback" helpes it to advance.

Best regards,

Karsten

--

You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/CAPG4N%3DYhSrOVzYSBucH1NtnJeSUckRSmO06_ao7JNa5%3Disxx7Q%40mail.gmail.com.

[Sascha Lucas]

Hi,

On Sun, 13 Dec 2020 21:27:41 -0800
Martin McClure <martin....@gemtalksystems.com> wrote:

> At the time Ganeti was first developed, KVM was very new, while Xen had
> been around a few years. It seems likely that the documentation was true
> when it was written, but the usage has shifted.

That is true.

> On 12/13/20 8:21 PM, Gabriel Filion wrote:
> > for my part I guess I'm mostly surprised about this detail. Since the
> > upstream documentation seems to point towards Xen being the main
> > virtualisation being supported and "some ppl use kvm but it's not the
> > main thing" while the survey shows interests are in practice the
> > inverse of that.

I'm sorry, that this kind of information got lost. And to be honest,
the status for Xen is probably worse. The expected 3.0 release has only
been tested for KVM. ATM there is no one in the github organization
having knowledge of using and testing Xen. For completeness, the same
is true for LXC.

Adapting docs to current time should be possible via github (website,
too), but we are still struggling to get in control of the ganeti.org
domain. Thankfully Google is patient and holding status quo, but from
the side of our legal entity (SPI) it's taking a way to long (9 month).
They are all volunteers, so no one to blame...

Thanks, Sascha.

[Sascha Lucas]

Hi Karsten,

thanks for your feedback and your open words. I'll replay with a top-post:

To point 1). Absolutely true.

There may be even a bigger userbase then expected from the survey or
the impression on this list. We discovered this during small
conferences like CLT or ganeticon. Mostly companies use Ganeti as a low
level tool, being itself not a manufacturer of such tools. This
sometimes leads to illogical decisions (probably in your case too?).
Everyone can calculate VMware license costs, but no one is willing to
invest the same amount of money into Ganeti. From my own calculations,
one year of VMware license fees for an equivalent of 150 Ganeti
instances are sufficient to dramatically boost Ganeti development.
Maybe for Ganeti this single invest is enough, but with VMware, you
will pay this year by year.

To point 2) cloud-init support.

I agree that this should be available and has been stated several times
on ganeticons etc. On simple approach is to integrate cloud-init into
your OS interface with the NoCloud datasource (injecting files) ->
several people have done so. However this is not as dynamic as one
would expect. So there is metad... maybe somehow partialy working, but
written in Haskell. An other interest stated at ganeticons is the
process of "De-Haskell-ation" (a wordplay, meaning the removal of
Haskell, to attract developers). metad is relatively isolated and could
be re-implemented from scratch in python. Synnefo and snf-image were
really great but haven't a better history than Ganeti.

To point 3. No terraform provider.

I don't know anything about terraform, but regarding node setup most
people have ansible/puppet/etc. for their config management. But I
guess that's not all your are looking for?

Thanks, Sascha.

[srOmatic]

To complement Rudolph's thoughts, I considered using Ganeti because I thought it was a KISS design.

In fact, Ganeti has so many possibilities that it is not a solution for everyone and, furthermore, it has not kept up with certain advances and is out of date for some applications.

The distribution of files on the system, with tons of symbolic link is not KISS.The use of two such conceptually different languages is not a good thing either.

I absolutely wanted to use Xen, especially since in Debian 10, the super PVH mode is up and running, plus pvgrub instead of pygrub. I also wanted to use the new features of DRBD9 as well, but that wasn't possible either.

So I recompiled Ganeti (hello Haskell dependencies or docs building nightmare) with patches, but in the end I gave up and designed our own (and very modest) little cluster manager named Genesix.

With little extras, like groups of instances inside a node, with their own internal networks, or Tiers-III instances (or even more, thanks to DRBD9, but I don't have military applications to run :). All this of course with hot migration, like Ganeti does for years.

Today, it's running, but I want to replace the temporary scripts by clean commands, coded in a well-implemented compiled language.

By the way, when it's finished (end of 2021), I'll release it for free (Debian Xen DRBD9 centric only). Dual network stack only (publics IPFO to internet with private nework behind for DRBD sync and cluster management).

It's not for everyone, just a KISS view of a n cluster, 50 nodes and 200 instances per cluster without dynamic routing and specific firewall/router VM. I use exclusively internal kernel ressources as a well populated sysctl.conf, anetwork/interfaces dynamically restarted when changed and, on course iptables scripts, also dynamically updated).

IPFOs are switched from node to node by the host API. So there is a small break of a few seconds. This is intentional because we want to stay KISS and not have to implement dual routers with, by example, something like CARP. But also we want to keep the network really private, without any public traffic.

My vision is to stay away from anything existing that goes beyond the circle of Debian, Xen and DRBD. Because my needs are modest, because I don't want to depend on trendy systems like terraform that one day will be replaced by other trendy systems or, worse, bought and then monetized (the latest is Centos).

Finally, I would like to warmly thank Ganeti and its community for giving me ideas about a really KISS CLI cluster manager. Ganeti was a forerunner and he deserves to evolve with the latest technology, not forgetting where it came from and hopefully one day return to his original KISS.

[Karsten Heymann]

Hi Sascha,

quick reply to some of your points:

> Everyone can calculate VMware license costs, but no one is willing to
> invest the same amount of money into Ganeti. From my own calculations,
> one year of VMware license fees for an equivalent of 150 Ganeti
> instances are sufficient to dramatically boost Ganeti development.

You are absolutely right. The problem was, we were already using vmware

in other parts of the company and thus had already purchased a large number

of vmware licenses. So that money way already spent and not available to

be invested into ganeti.

> I don't know anything about terraform, but regarding node setup most
> people have ansible/puppet/etc. for their config management. But I
> guess that's not all your are looking for?

Terraform is not used for configuring nodes, but to configure services or apis.

Instead of calling gnt-xxx add/modify, with terraform you would put your desired

cluster configuration into a terraform file and run "terraform apply". Terraform would

compare the current configuration of the cluster with the one stored in the terraform

config, show any differences and offer to correct them. Like you want to ensure that

your drbd replication speed is set the same on all of your clusters or that neworks a,b

and c exist on cluster X, that would be a job for terraform. Especially when running

multiple cluster (as I said, we were up to a dozen at a time), you don't want to manually

check the config for consistency. The great thing is that this allows you to version

control your cluster config and at any time ensure the cluster is configured the way

you want it to be.

Good luck with bringing ganeti forward,

Karsten

[Sascha Lucas]

Hi,

On Mon, 14 Dec 2020 23:18:40 -0800 (PST)
srOmatic <srivi...@gmail.com> wrote:

> The distribution of files on the system, with tons of symbolic link is not
> KISS.The use of two such conceptually different languages is not a good
> thing either.

Your are probably talking about the version symlinks, which enables
parallel installation of different Ganeti versions. They seem
unnecessary for me, too. I would assume, that up-/downgrade via a
package manager should be enough? Also I liked the old manual upgrade
path without "gnt-cluster upgrade --to ...", because it gives me the
feeling to be more in control (BTW: I assume this old path is still
possible).

Haskell dramatically reduces contributions. This is a big problem for
the Ganeti project, seeking for contributions. De-Haskell-ation
(replacing Haskell by Python) can be an option, but is a long way to go.

> I absolutely wanted to use Xen, especially since in Debian 10, the super
> PVH mode is up and running, plus pvgrub instead of pygrub. I also wanted to
> use the new features of DRBD9 as well, but that wasn't possible either.

Do I read this correct, that Xen does not work in Debian 10, the way
you wanted it?

DRBD9 would be nice. Ganeti's concept, that the instances always run on
the primary, seems ideal to me (from the perspective of failure
domains). The drawback is the limited mobility of instances. DRBD9
could possibly integrated via ESI[1], but this would mean, that Ganeti
does not manage storage, so knows nothing about placements of replicas
etc. It would just work like sharedfile (NFS) or ceph.

> So I recompiled Ganeti (hello Haskell dependencies or docs building
> nightmare) with patches, but in the end I gave up and designed our own (and
> very modest) little cluster manager named Genesix.

...

> Today, it's running, but I want to replace the temporary scripts by clean
> commands, coded in a well-implemented compiled language.
>
> By the way, when it's finished (end of 2021), I'll release it for free

That is interesting to here. I also wasted thoughts on starting a
project from scratch, because I learned from Ganeti over time that I
need just a few simple things... At Ganeticons we talked about that it
is common to give up at 80% and reinvent the wheel, just to noticed
later that the last 20% are hard. However your case seems far
advanced...

> My vision is to stay away from anything existing that goes beyond the
> circle of Debian, Xen and DRBD.

That's one point in common with Ganeti's vision, working as a debian
package. Others are being self-contained and moderate complexity (what
ever this means and how far this will be away from KISS).

> Finally, I would like to warmly thank Ganeti and its community for giving
> me ideas about a really KISS CLI cluster manager.

Thanks, too. I'm looking forward to hear from Genesix.

Sascha.

[1] http://docs.ganeti.org/ganeti/current/html/man-ganeti-extstorage-interface.html

[Martin McClure]

On 12/16/20 1:18 PM, Sascha Lucas wrote:
> Your are probably talking about the version symlinks, which enables
> parallel installation of different Ganeti versions. They seem
> unnecessary for me, too. I would assume, that up-/downgrade via a
> package manager should be enough? Also I liked the old manual upgrade
> path without "gnt-cluster upgrade --to ...", because it gives me the
> feeling to be more in control (BTW: I assume this old path is still
> possible).

Since the version symlinks have been there, they have made upgrades much
easier for us. Ganeti version upgrades have historically (for us) been
problematic, though much better in recent versions. We build Ganeti from
source, since at least in the past the pre-built packages were rarely up
to date. Being able to drop back to the previous version without pain is
really helpful. We can't afford really large quantities of downtime; our
company's critical infrastructure is running on Ganeti.

Regards,
-Martin

[srOmatic]

Hi Sascha,

> Your are probably talking about the version symlinks, which enables
> parallel installation of different Ganeti versions. They seem

Yes. Undoubtly useful when testing, not KISS in production.

> Haskell dramatically reduces contributions. This is a big problem for
> the Ganeti project, seeking for contributions. De-Haskell-ation

The guy who introduced the "fox into the henhouse" aka Haskell in Ganeti just forgot what Ganeti's usage was.

> (replacing Haskell by Python) can be an option, but is a long way to go.

It's probably too late now. Ganeti has to live with. Haskell is not bad and

has its strengths.

> Do I read this correct, that Xen does not work in Debian 10, the way
> you wanted it?

Sorry, my english skills are limited. Xen works flawlessly in Debian 10. Debian devs have made a lot of work to integrate the Xen great latests functionalities, including all the patches needed by PVH and pvGrub (in kernel and grub).

It's Ganeti which is now outdated, not handling : PVH mode (patch exist on the net but xen options have changed in the meantime),  pvGrub and DRBD9.

> That is interesting to here. I also wasted thoughts on starting a
> project from scratch, because I learned from Ganeti over time that I
> need just a few simple things... At Ganeticons we talked about that it
> is common to give up at 80% and reinvent the wheel, just to noticed
> later that the last 20% are hard. However your case seems far

> advanced...

I spent a lot of time on Ganeti. I don't like to reinvent the wheel too :) But I wanted PVH, pvGrub and DRBD9. I realized that I could do something that would be within the reach of one person, both on the dev side for coding¹ and on the admin side for operation. Above all, I wanted KISS. Something understandable and installable in a day by one mean people like me :)

¹ Coding language choice was a pain. C is too low level, I dislike all theses fashionable wild-typing interpreted languages. I strongly disagree about the hell's depencies that can be found in JS, Python or Haskell. I wanted a straight and clean install/desinstall process. I'm very found of strong typing languages (time and bug savers). As a sysadmin I want scripting. As a dev I like robustness. I choose Ada for binary coding and Hac for scripting (Hac is an small Ada subset interpreter). Ada is readable as Pascal or Python. It's really strong typed, avoiding tons of bugs and allowing speed coding. I don't care that Ada is less fashionable than JS, Rust, Go. Ada is clean. Hac is compilable in Ada. There is consistency. The code is very readable. I don't have a preferred language. I just want productivity. Anyone will be able to read and take over the code. The coding style will be neither object nor functional. Just plain procedural code. I want to stay focused to sysadmin people and job.

All Genesix docs are (mistakenly ;) in french. The Hac manual is in english from the start. I have planned to write finals docs in english. But already, for those who read French, I can give theses docs as they are. At least, they show precisely :
- The validated concept of Genesix (extensives shematics are in progress). The limitations are clearly written too.

- How to use Xen on Debian 10 with PVH¹ mode, with pvGrub² and Drbd 9³ (all this is really simple but not trivial by lack of accurate documentation on the net).

Genesix works today "manually" in production, with some Hac scripts for starting and stopping nodes, toggling IPFO, migrating Instances, managing TLS certs, backups, etc. I just have to code the whole thing the way I want, with consistency, with a readable standalone text database, a template manager, etc. I'm a "slow person", I have many others tasks to do in my company, but I use to go to the end of projects. I planned one year for a first Genesix for Debian 10 release. At this time Debian 11 will be out. I don't care. I use to skip one release of two (one over two, 10..12..14 don't know how to write that in english). Sysadmin time is not in a hurry :)

¹ PVH is virtualization at its best : no more QEMU, very fast mode, handle non cooperative OS like windows.
² pvGrub (no more pygrub) : better security and consistency as the boot is now done inside the domU.

³ no more stacking, better funtionnalities in the corners, mesh mode, makes Tiers-n apps a breeze (one primary, n secondaries). Genesix handles n=2 and n=3

[Ivan Rossi]

Has anyone used these cloud-init-based providers? Any comment?

1. https://github.com/neicnordic/ganeti-os-nocloud
   
2. https://github.com/pdxcat/ganeti_cloud-init

[Petter Urkedal]

On 2020-12-22 10:44, Ivan Rossi wrote:
> Has anyone used these cloud-init-based providers? Any comment?
>

> 1. https://github.com/neicnordic/ganeti-os-nocloud
> 2. https://github.com/pdxcat/ganeti_cloud-init

>
>
> Il giorno lun 14 dic 2020 alle ore 11:14 Karsten Heymann <
> karsten...@gmail.com> ha scritto:
>
> >
> > 2. No support for cloud-init. Ganeti's instance mechanism is quite
> > powerful, but it requires too much work to support new versions of linux.
> > IMO the only way to go is to deprecate the instance system and replace it
> > with first-class support for cloud-init. This would make it *much* easier
> > to run any linux version on ganeti.

I am the author of ganeti-os-nocloud, and I'm still maintaining it. I
don't know if anyone else uses it, but we are using it at two sites.
Requests and merge requests are welcome in case it is not generic enough
for other sites.

ganeti-os-nocloud it is primarily meant to be lightweight and simple to
maintain, so it may be a different solution is needed. The question is
what is expected from a "first-class" solution. One limitation of
ganeti-os-nocloud is that metadata is delivered once only, since it's
stored as a file rather than using the metadata daemon.

So, maybe a different solution would be in place? What do people
experienced with cloud-init from cloud platforms expect?

[Ivan Rossi]

Good to know. It should be ok for me. Going to test it on a brand new small gnt 3.0 cluster

--
You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/20201223135410.GA22115%40dione.int.eideticdew.org.