terraform-provider-feilong
a project by e_bischoff
Updated 4 months ago. 5 hacker ♥️. 2 followers.

Project Description

People need to test operating systems and applications on s390 platform.

Installation from scratch solutions include:

  • just deploy and provision manually add-emoji (with the help of ftpboot script, if you are at SUSE)
  • use s3270 terminal emulation (used by openQA people?)
  • use LXC from IBM to start CP commands and analyze the results
  • use zPXE to do some PXE-alike booting (used by the orthos team?)
  • use tessia to install from scratch using autoyast
  • use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
  • directly install a Linux kernel on a LPAR and use kvm + libvirt from there

Deployment from image solutions include:

  • use ICIC web interface (openstack in disguise, contributed by IBM)
  • use ICIC from the openstack terraform provider (used by Rancher QA)
  • use zvm_ansible to control SMAPI
  • connect directly to SMAPI low-level socket interface

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.

Other Feilong-based solutions include:

  • make libvirt Feilong-aware
  • simply call Feilong from shell scripts with curl
  • use zvmconnector client python library from Feilong
  • use zthin part of Feilong to directly command SMAPI.

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.

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, and compatible with our existing development infrastructure.

Resources

Outcome

Join this project

Looking for hackers with the skills:

s390 mainframe zvm golang terraform deployment

This project is part of:

Hack Week 23

Activity

  • 6 months ago: juliogonzalezgil liked this project.
  • 6 months ago: e_bischoff liked this project.
  • 6 months ago: mfriesenegger liked this project.
  • 6 months ago: dgedon liked this project.
  • 6 months ago: mfranc liked this project.
  • 6 months ago: e_bischoff started this project.
  • 6 months ago: e_bischoff added keyword "deployment" to this project.
  • 6 months ago: e_bischoff added keyword "terraform" to this project.
  • 6 months ago: e_bischoff added keyword "golang" to this project.
  • 6 months ago: e_bischoff added keyword "zvm" to this project.
  • 6 months ago: e_bischoff added keyword "s390" to this project.
  • 6 months ago: e_bischoff added keyword "mainframe" to this project.
  • 6 months ago: e_bischoff originated this project.


    • Comments

    • mfriesenegger
      6 months 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!

    • e_bischoff
      6 months 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.

    • e_bischoff
      6 months 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).

    • e_bischoff
      5 months 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.

    • e_bischoff
      4 months ago by e_bischoff | Reply

      Go library has now 100% coverage.

      I'm not sure anymore that the protocol 5 provider was useful, but I'll keep maintaining it because it's handy for my tests.

      The provider still lacks R and U parts of CRUD.

    Similar Projects

    Go zip updater: Appending new files to zip archive without decompressing the whole file by StarryWang

    Project Description

    Currently, Golang's `...

    WebUI for your data by avicenzi

    [comment]: # (Please use the project descriptio...

    Rancher Upgrader - Upgrades your rancher install via helm, and communicates critical changes from release A to B. by rweir

    [comment]: # (Please use the project descriptio...

    A CLI for Harvester by mohamed.belgaied

    [comment]: # Harvester does not officially come...

    Learn Golang contribuing to opensource projects by mbussolotto

    Project Description

    Get practice in Golan...