Project Description
People need to test operating systems and applications on s390 platform. Solutions include:
- just deploy and provision manually
(with the help of
ftpboot
script, if you are at SUSE) - use
s3270
terminal emulation (used byopenQA
people?) - use
zPXE
to do some PXE-alike booting (used by theorthos
team?) - use
ICIC
web interface (openstack
in disguise, contributed by IBM) - use
ICIC
from theopenstack
terraform
provider (used byRancher
QA) - use
tessia
to install from scratch using autoyast - use
libvirt
for s390 to do some nested virtualization on some already deployed z/VM system - connect to
SMAPI
low-level socket interface - directly install a Linux kernel on a LPAR and use kvm + libvirt from there
IBM Cloud Infrastructure Center (ICIC
) harnesses the Feilong API, but you can use Feilong
without installing ICIC
, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.
What about writing a terraform Feilong
provider, just like we have the terraform
libvirt
provider? That would allow to transparently call Feilong
from your main.tf files to deploy and destroy resources on your system/z.
Goal for this Hackweek
My real goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.
Other solutions include e.g. making libvirt
Feilong-aware, or simply calling Feilong
from shell scripts.
My preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean.
Resources
Outcome
This project is part of:
Hack Week 23
Activity
Comments
-
about 1 month ago by mfriesenegger | Reply
As the Feilong project chair, I like the terraform-feilong-provider project and making libvirt Feilong-aware. I will support your effort!
-
about 1 month ago by e_bischoff | Reply
Thanks for your support Mike. For the moment, I am still not completely sure whether I will take the terraform approach or the libvirt approach. The first one seems to me better, as for practical purposes it's one software layer less for us. I could even pick up something completely different. But so far the terraform provider approach seems the most promising for the least effort.
-
about 1 month ago by e_bischoff | Reply
OK, decision taken, I will stick to the terraform approach.
The bad part is that I have to code for 2 versions of
terraform
as we need to support both plugin protocols 5 and 6.The good part is that we get a golang library for
Feilong
for free (there is a project ZVM connector golang but it does not provide marshalling and demarshalling). -
21 days ago by e_bischoff | Reply
We have a working provider and a partial Go library. Mission accomplished, although it would be nice to attract other contributors and fill in the holes.
Similar Projects
WebUI for your data by avicenzi
[comment]: # (Please use the project descriptio...
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come...
Gameboy emulator written in Go by mikeletux
[comment]: # (Please use the project descriptio...
Learn Golang contribuing to opensource projects by mbussolotto
Project Description
Get practice in Golan...
Go zip updater: Appending new files to zip archive without decompressing the whole file by StarryWang
Project Description
Currently, Golang's `...
Update Rancher Terraform Quickstart to leverage Elastic IP addresses by kevinmayres
Make Rancher and NeuVector AWS QuickStart pe...
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! [https://gitter.im/uy...