Project Description
We would like to create a single interface for teams to manage our cloud governance.
We currently provide landing zones for AWS, GCP, and Azure, but in providing them, we’re becoming a central bottleneck, as most changes need to go through us. For our cloud usage to grow, we need to improve our processes, and delegate some responsibility when needed, especially in tasks where we’re not the subject-matter experts. We hope to empower everyone, including non-technical employees, to claim ownership over the processes that matter to them, and strengthen our current offerings.
Goal for this Hack Week
One of the major areas for improvement is the processes around tag maintenance. We use tags to manage account ownership, contact information, billing, alerting, and more. Because they’re a central part in our environments, we need to treat them as first-class citizens and ensure they’re always up-to-date. Our current setup setup isn't sufficient: we manage them in four separate repositories (change risk) and cannot easily allow non-technical employees to make changes.
This project was born out of our centralization efforts, a hope that we could manage our tags with care, and the desire to make a solid foundation for our governance to grow.
There is much we would like to accomplish, but here are the scoped tasks for Hack Week 21:
- To collect cloud tags for cloud providers (starting with AWS).
- To allow users to edit tags.
- To detect tag drift (notifications when the tags aren’t what they should be).
- To have Okta manage users/groups with SCIM.
In last year’s Hack Week, we experimented with a similar concept, but it covered cloud costs. This year, we took the lessons learned, and used parts of it to start our new project. You can view last year’s efforts at our GitHub project.
Resources
- Project Skyscraper’s design RFC: https://github.com/suse-skyscraper/rfc/pull/2
- Project Skyscraper’s server: https://github.com/suse-skyscraper/skyscraper
- Project Skyscraper’s helm charts: https://github.com/suse-skyscraper/skyscraper-helm-charts
This project is part of:
Hack Week 21
Activity
Comments
Be the first to comment!
Similar Projects
Mammuthus - The NFS-Ganesha inside Kubernetes controller by vcheng
Description
As the user-space NFS provider, the NFS-Ganesha is wieldy use with serval projects. e.g. Longhorn/Rook. We want to create the Kubernetes Controller to make configuring NFS-Ganesha easy. This controller will let users configure NFS-Ganesha through different backends like VFS/CephFS.
Goals
- Create NFS-Ganesha Package on OBS: nfs-ganesha5, nfs-ganesha6
- Create NFS-Ganesha Container Image on OBS: Image
- Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand. Mammuthus
Resources
Mammuthus - The NFS-Ganesha inside Kubernetes controller by vcheng
Description
As the user-space NFS provider, the NFS-Ganesha is wieldy use with serval projects. e.g. Longhorn/Rook. We want to create the Kubernetes Controller to make configuring NFS-Ganesha easy. This controller will let users configure NFS-Ganesha through different backends like VFS/CephFS.
Goals
- Create NFS-Ganesha Package on OBS: nfs-ganesha5, nfs-ganesha6
- Create NFS-Ganesha Container Image on OBS: Image
- Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand. Mammuthus
Resources
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
ftpboot
script, if you are at SUSE) - use
s3270
terminal emulation (used byopenQA
people?) - use
LXC
from IBM to start CP commands and analyze the results - use
zPXE
to do some PXE-alike booting (used by theorthos
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 theopenstack
terraform
provider (used byRancher
QA) - use
zvm_ansible
to controlSMAPI
- 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 withcurl
- use
zvmconnector
client python library from Feilong - use
zthin
part 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.