Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means:
- Adding some lines to the corresponding config file
- For the room to be available immediately, either restarting the service, either creating the room also through the REST interface.
I want to explore Salt to see how it can be used in order to provide a better way to create/destroy rooms, so every admin can easily do it. I have never used Salt, so I'm open to suggestions about the approach.
On the other hand, I would also like to come up with a more sustainable organization of the rooms. We started with one room per team because we didn't expected so many teams adopting Jangouts. Now we have more than 15 rooms, so maybe we should switch to other approach, like having a defined set of rooms (named with colors, cities, whatever) that everybody shares. Once again, I'm open to suggestion.
Final result
The SaltStack part is done. Now we have a Salt execution module that allows not only to create rooms (persistent and with immediate effect) but also to inspect the status of the Janus instance (for example, listing the connected users). Here is the repository and here the rpm packages.
- Putting pieces together: check! (Jangouts + Salt)
- Learning: check! (I have learned the Salt essentials and played with it... and I REALLY like it)
- Improving the world: check! (Now all admins can manage rooms from the Janus host or from the salt master)
- Collaboration: check! (Pablo rocks!)
Still pending: coming up with a more sustainable organization of the rooms. Still open to suggestions.
This project is part of:
Hack Week 14
Activity
Comments
-
over 8 years ago by ancorgs | Reply
There is already some working code in this repository
It right now talks to the REST interface offered by Janus in order to manage rooms. You can execute, for example,
salt-call --local janus.create_videoroom "An awesome room" bitrate=128Next step would be to ensure that the change is not only performed through the REST interface, but also is persisted to the configuration file.
-
over 8 years ago by PSuarezHernandez | Reply
Some updates:
- Now the created rooms are also persisted in the configuration file.
janus.plugin_messageallow send custom messages through the REST interface.- Added some extra functions to
salt-janus-module.
Available functions of
salt-janus-module:- janus.info
- janus.list_videorooms
- janus.list_audiorooms
- janus.list_participants
- janus.create_videoroom
- janus.create_audioroom
- janus.plugin_message
- janus.save_rooms_status
Repository: salt-janus-module
-
over 8 years ago by ancorgs | Reply
Now that everything works nicely (I have successfully created rooms remotely from the salt master in my test environment). Next step would be package this. Most likely in https://build.opensuse.org/project/show/network:jangouts
-
Similar Projects
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! https://gitter.im/uyuni-project/hackweek
Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!
Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.
For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.
No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)
The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.
To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):
- Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
- Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
- Package management (install, remove, update...)
- Patching
- Applying any basic salt state (including a formula)
- Salt remote commands
- Bonus point: Java part for product identification, and monitoring enablement
- Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
- Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
- Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)
If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)
- If you don't have knowledge about some of the steps: ask the team
- If you still don't know what to do: switch to another distribution and keep testing.
This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)
Pending
FUSS
FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.
https://fuss.bz.it/
Seems to be a Debian 12 derivative, so adding it could be quite easy.
[W]Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)[W]Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).[W]Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.[I]Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?[W]Applying any basic salt state (including a formula)[W]Salt remote commands[ ]Bonus point: Java part for product identification, and monitoring enablement
Saline (state deployment control and monitoring tool for SUSE Manager/Uyuni) by vizhestkov
Project Description
Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.
In current state the published version can be used only as a Prometheus exporter and missing some of the key features implemented in PoC (not published). Now it can provide metrics related to salt events and state apply process on the minions. But there is no control on this process implemented yet.
Continue with implementation of the missing features and improve the existing implementation:
authentication (need to decide how it should be/or not related to salt auth)
web service providing the control of states deployment
Goal for this Hackweek
Implement missing key features
Implement the tool for state deployment control with CLI
Resources
https://github.com/openSUSE/saline