a project by vcuadradojuan
A successor of
- https://github.com/viccuad/salt-configs
- https://hackweek.suse.com/projects/saltify-dotfiles-workstation-laptop-desktop-environment-and-beyond-nas-router-media-center-kodi-if-time-allows
This project was already rolling before hackweek: https://github.com/viccuad/ansible-configs.
Right now it has a working testing setup using vagrant-libvirt that simulates home lan and wifi by switches, raid 10 of 4 disks on the NAS, router working with Freedombox (Debian pure-blend).
I plan to automate as much as possible the desktop plays, add to the router until it's a full fledged one, add roles for cockpit, borgbackup, and whatever I can think of.
It would be cool to add wifi simulation to the libvirt deployment using mac80211_hwsim or something similar.
This project is part of:
Hack Week 16 Hack Week 17
Activity
Comments
-
about 8 years ago by joachimwerner | Reply
I’d be really interested in your take-aways about how Salt and Ansible compare. I guess you are aware that Salt is the preferred choice for configuration management and automation at SUSE, but we are always open to suggestions on how to improve things.
-
about 8 years ago by vcuadradojuan | Reply
> I guess you are aware that Salt is the preferred choice for configuration > management and automation at SUSE, but we are always open to suggestions on how > to improve things.
Yes, I'm aware that Salt is the preferred choice for SUSE. Sadly, for my day to day work at SUSE I need Ansible (and hence this hackweek project as practice); I'll happily provide you more information outside of a public forum if you desire.
> I’d be really interested in your take-aways about how Salt and Ansible compare.
As you can see by the predecessor, salt-configs, listed in the description, I tried to achieve the same project half a year ago in Salt. In that repo there's an incomplete list of hiccups at TODO.org.
These include a list of bugs about mainly copying files maintaining their attributes, copying soft symlinks, appending to files with utf8 and being able to do pillar['var'] in pillar files. I remember working around other distinct bugs prior to start collecting the in the TODO.org file, so maybe perusing the code for TODOs and comment workarounds would be a good idea.
Some of these bugs have already been closed in the latest Salt version, but since Salt has a server-client architecture, I will need to backport those new versions to the several OSes that I target and write the Salt states with conditionals in case that is not possible; this is outside of my desire for a personal project as this one.
Another solution would be to use
salt-ssh; which I tried and found that it didn't implement the whole functionality of Salt, particularlygitfs, needed for using community salt-formulas, which are a big productivity multiplier (At the docs, grep for "However, needed fileserver wrappers are still under development.". I haven't found more documentation than that on this topic).I could also use
salt-calland run the states locally on the minions, but I also discarded that approach for security reasons: I didn't want to have all salt states, pillars and secrets present in all machines. One can think of possible workarounds for checking out salt configs, but it was also outside of my desire for a personal project.The folks in #salt @freenode where really nice, and I look forward to use Salt for my personal projects in the future. Please don't hesitate to come by my office if you are interested further.
-
-
about 8 years ago by vcuadradojuan | Reply
In 4 half-days I was able to: - Created repo https://github.com/viccuad/vagrant-libvirt-ansible-example. Contains a production/testing environment example for ansible - Contribute to ansible-configs https://github.com/viccuad/ansible-configs/graphs/contributors?from=2017-11-10&to=2017-11-16&type=c 35 commits, mainly achieving: * Add cockpit, unattended, themes, flatpak, server, desktop, icons, games roles * Migrate to roles of roles for desktop and server * Make freedombox installation idempotent * Reboot freedombox and wait for host to come back on installation * Make pcengines kernel tasks idempotent * Add firewalld configs for every thing networked on every role * Update dotfiles: .spacemacs, weechat, neovim, debian - Migrate fully to matrix.org and weechat plugin, ditch IRC. See: https://github.com/viccuad/ansible-configs/commit/3d11de899a29df3c9026b18798eb736610a3a36e-
over 7 years ago by vcuadradojuan | Reply
In this week I was able to:
https://gitlab.com/viccuad/ansible-configs/commits/master Write ~50 commits, made a lot of stuff idempotent, changed CI, added new roles
-
Similar Projects
Dynamic Ansible Inventory for Orthos 2 by SchoolGuy
Description
Ansible is used in the context of Orthos 2. To enhance the parallel execution of Ansible playbooks for Orthos 2 hosts (machine scanning), the Cobbler dynamic Inventory plugin should be evaluated.
Goals
Improve the parallelization of machine scanning in Orthos 2.
Resources
- https://github.com/openSUSE/orthos2/
- https://docs.ansible.com/projects/ansible/latest/inventoryguide/introdynamic_inventory.html#inventory-script-example-cobbler
Ansible to Salt integration by vizhestkov
Description
We already have initial integration of Ansible in Salt with the possibility to run playbooks from the salt-master on the salt-minion used as an Ansible Control node.
In this project I want to check if it possible to make Ansible working on the transport of Salt. Basically run playbooks with Ansible through existing established Salt (ZeroMQ) transport and not using ssh at all.
Goals
- [v] Prepare the testing environment with Salt and Ansible installed
- [v] Discover Ansible codebase to figure out possible ways of integration
- [v] Create Salt/Uyuni inventory module
- [v] Make basic modules to work with no using separate ssh connection, but reusing existing Salt connection
- [v] Test some most basic playbooks
Resources
TBD
Multimachine on-prem test with opentofu, ansible and Robot Framework by apappas
Description
A long time ago I explored using the Robot Framework for testing. A big deficiency over our openQA setup is that bringing up and configuring the connection to a test machine is out of scope.
Nowadays we have a way¹ to deploy SUTs outside openqa, but we only use if for cloud tests in conjuction with openqa. Using knowledge gained from that project I am going to try to create a test scenario that replicates an openqa test but this time including the deployment and setup of the SUT.
Goals
Create a simple multimachine test scenario with the support server and SUT all created by the robot framework.
Resources
- https://github.com/SUSE/qe-sap-deployment
- terraform-libvirt-provider
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles:
- https://linux-system-roles.github.io/
- https://build.opensuse.org/package/show/openSUSE:Factory/ansible-linux-system-roles Package on sle16 ansible-linux-system-roles
First meeting Hackweek catchup
- Monday, December 1 · 11:00 – 12:00
- Time zone: Europe/Madrid
- Google Meet link: https://meet.google.com/rrc-kqch-hca
Contribute to terraform-provider-libvirt by pinvernizzi
Description
The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.
It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.
If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.
Goals
- Get more familiar with Terraform provider development and libvirt bindings in Go
- Solve some issues and/or implement some features
- Get in touch with the community around the project
Resources
- CONTRIBUTING readme
- Go libvirt library in use by the project
- Terraform plugin development
- "Good first issue" list