Mash is a Python based CI/CD pipeline for automated testing and publishing of public cloud images. Currently the production and development deployment for the package is inconsistent, slow and manual. This is a barrier to rapid development, deployment and testing. It also means the development workflow is different than production. This can lead to production issues which were not seen during development.
In order to modernize the Mash workflow I plan to spend the week digging into a plethora of tools to first learn then build out a new workflow. The goal is to simplify deployment by choosing tools that provide consistency, modularity and repeatability. By leveraging the best tools available we can harden the code and accelerate the release cycle.
Key metrics to target are:
- Mash deployment and runtime environment is consistent (dev, staging, prod, etc.).
- Mash runtime environment is decoupled from the host.
- Mash can be deployed with one click.
- Any Mash branch in GitHub can be deployed with a single config change.
- Mash has an automated E2E test suite using the new deployment
Technologies to investigate:
- Docker, Podman, containers
- OBS (packages, images)
- Salt
- Terraform (stretch goal to handle cloud instance management)
- Pytest, Testinfra, img-proof for E2E testing
Looking for hackers with the skills:
containers podman deployment iac salt terraform ci/cd python3 docker obs
This project is part of:
Hack Week 19
Activity
Comments
Be the first to comment!
Similar Projects
Technical talks at universities by agamez
Description
This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.
For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.
Goals
- Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
- Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
- Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.
Resources
- Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
- SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.
terraform-provider-feilong by e_bischoff
Project Description
People need to test operating systems and applications on s390 platform.
Installation from scratch solutions include:
- just deploy and provision manually
(with the help of ftpbootscript, if you are at SUSE) - use
s3270terminal emulation (used byopenQApeople?) - use
LXCfrom IBM to start CP commands and analyze the results - use
zPXEto do some PXE-alike booting (used by theorthosteam?) - use
tessiato install from scratch using autoyast - use
libvirtfor s390 to do some nested virtualization on some already deployed z/VM system - directly install a Linux kernel on a LPAR and use
kvm+libvirtfrom there
Deployment from image solutions include:
- use
ICICweb interface (openstackin disguise, contributed by IBM) - use
ICICfrom theopenstackterraformprovider (used byRancherQA) - use
zvm_ansibleto controlSMAPI - connect directly to
SMAPIlow-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
libvirtFeilong-aware - simply call
Feilongfrom shell scripts withcurl - use
zvmconnectorclient python library from Feilong - use
zthinpart of Feilong to directly commandSMAPI.
Goal for Hackweek 23
My final 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 technical 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.
Goals for Hackweek 24
Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!
Let's add support for fiberchannel disks and multipath.
Possible goals for Hackweek 25
Modernization, maturity, and maintenance.
terraform-provider-feilong by e_bischoff
Project Description
People need to test operating systems and applications on s390 platform.
Installation from scratch solutions include:
- just deploy and provision manually
(with the help of ftpbootscript, if you are at SUSE) - use
s3270terminal emulation (used byopenQApeople?) - use
LXCfrom IBM to start CP commands and analyze the results - use
zPXEto do some PXE-alike booting (used by theorthosteam?) - use
tessiato install from scratch using autoyast - use
libvirtfor s390 to do some nested virtualization on some already deployed z/VM system - directly install a Linux kernel on a LPAR and use
kvm+libvirtfrom there
Deployment from image solutions include:
- use
ICICweb interface (openstackin disguise, contributed by IBM) - use
ICICfrom theopenstackterraformprovider (used byRancherQA) - use
zvm_ansibleto controlSMAPI - connect directly to
SMAPIlow-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
libvirtFeilong-aware - simply call
Feilongfrom shell scripts withcurl - use
zvmconnectorclient python library from Feilong - use
zthinpart of Feilong to directly commandSMAPI.
Goal for Hackweek 23
My final 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 technical 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.
Goals for Hackweek 24
Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!
Let's add support for fiberchannel disks and multipath.
Possible goals for Hackweek 25
Modernization, maturity, and maintenance.
Rancher/k8s Trouble-Maker by tonyhansen
Project Description
When studying for my RHCSA, I found trouble-maker, which is a program that breaks a Linux OS and requires you to fix it. I want to create something similar for Rancher/k8s that can allow for troubleshooting an unknown environment.
Goals for Hackweek 25
- Update to modern Rancher and verify that existing tests still work
- Change testing logic to populate secrets instead of requiring a secondary script
- Add new tests
Goals for Hackweek 24 (Complete)
- Create a basic framework for creating Rancher/k8s cluster lab environments as needed for the Break/Fix
- Create at least 5 modules that can be applied to the cluster and require troubleshooting
Resources
- https://github.com/celidon/rancher-troublemaker
- https://github.com/rancher/terraform-provider-rancher2
- https://github.com/rancher/tf-rancher-up
- https://github.com/rancher/quickstart