Add a document for Terraform

[atta]

A Document on how a potential Terraform
Provider for ganeti could be done

[rbott]

Thanks @atta for your PR :-) I agree that we should provide an upstream terraform provider so that people can easier integrate Ganeti into their workflows/tools.

This should probably live in its own repository under the ganeti organisation.

Since we already have lots of Ganeti RAPI Go code in gnt-cc I would strongly suggest to create an official RAPI client in Go as a separate package which both projects can use. This way we avoid duplicating code.

What do you think?

I have also included some more comments in this review. In general I think we should specify what to expect from the terraform provider (and what not to expect from it) and how it should be used. This will allow others to join the development efforts as it will be much clearer what the scope of this project is.

[rbott]

I would suggest to extend the examples to cover more usecases/parameters and also align the parameter names with ganeti (unless there are already conflicting conventions within terraform).

[atta]

@rbott my intention was to not overload this document: a lot of features are indeed possible with terraform but not jet a goal as a start.

[rbott]

This section should go a bit more into detail about what should be implemented or can be expected from the provider, so that we end up with something people can use to create code and/or also use to compare against PRs etc.

• supported hypervisors
• supported disk templates
• supported disk schemes (number of disks etc.)
• supported network schemes (numbers of nics, network types etc.)
• other supported features (e.g. automatic/manual node selection, custom hypervisor parameters)

I would suggest to start simple:

• we only support KVM for the first iteration
• all possible disk templates
• only automatic instance allocation
• any number of disks, any number of NICs
• network mode bridged with optional parameters link, network and vlan (this should cover most usecases)
• all backend parameters (maxmem, minmem, vcpus)
• all current KVM hvparams (given that we are using a strongly typed language, supporting "any" parameter will be harder to implement. OTOH most people will likely use only few hvparams on instance level as most will usually be set on cluster level)
• set OS type (and possibly also OS parameters?)

We also need to agree on what the provider should do with instance changes:

• will new disks/NICs be hot- or cold-added? Will this be configurable?
• will disks/NICs be deleted? Do we support that at all? Or maybe only in later releases? How should the terraform data be modeled to "detect" that a disk/NIC has been removed from the instance definition?
• it should support disk growing
• what happens when backend/hv parameters are changed? will this trigger an automatic reboot of the instance? should this be configurable?

[atta]

@rbott i will incorporate your suggestion, however i still think i should be less as a start to not over-complicate it.

[rbott]

This document needs to be fairly exhaustive to not over-complicate the development of the terraform provider itself :-) If we expect people to contribute, everyone needs to be able to understand planned features/goals/ideas. Otherwise we scare contributors away be rejecting their contributions because they do not meet whatever we might have in mind.

This document can/should also be used to decide whether the provider has reached a stable version 1.0 or if it is still missing features considered a bare minimum requirement.

[rbott]

This line seems to be a compile error - building the documentation fails with the following message:

Warning, treated as error:
/tmp/gntbuild.daxPPrTS/doc/design-terrafor-provider.rst:164:Block quote ends without a blank line; unexpected unindent.