Ticklist is a web application enabling users to record their ascents of climbing routes as well as to maintain their personal list of currently projected routes. My implementation went from working alpha back to pre-alpha status (~ basic things not working) while migrating parts of the codebase (knockout.js -> angular.js). The goal of this hackweek project was therefore to finish this migration and fix the basic features in order to make the app useful at least for personal usage.
The current technology stack is node, express, sequelize, jade (templating), angular and twitter bootstrap. Lots of future features come to my mind, like showing advanced statistics, integration with social networks, support bouldering ticklists as well, location based stuff, and so on.
A new web UI for saltstack, possibly the future of systems management.
The official salt UI halite is now officially retired and saltpad is still very young and in alpha state. In addition to the creation of a new frontend to salt, the goal could be to work towards a full replacement for existing systems management solutions like spacewalk, including the migration (minionification) of systems from there.
In SUSE Manager we want to offer support for bootstrapping systems that don't have the salt-minion installed and configured yet. This can be done using salt-ssh given just a hostname, username and password. See the docs about salt rosters for even more options. What we are missing:
- Support for using salt-ssh in our library
This project is about using Salt SSH for managing systems without the need of an additional agent to be installed (besides sshd). With the SSH protocol the connection is initiated by the management server, thus Salt SSH can be used to even manage systems that are located outside of company firewalls, i.e. machines that cannot access a salt-master due to firewall restrictions.
In order to still be able to access resources inside a company network though it would be very helpful if the salt-ssh command supported remote port forwarding (as with the -R parameter of the ssh command) for tunneling other traffic through the existing ssh connection, for instance a package manager might want to install packages from a company internal RPM repository. A patch was therefore contributed to Salt SSH in order to enable this feature (merged into develop):
There is a number of possible improvements to the architecture of SUSE Manager / Salt integration that should be investigated in order to improve the reliability and scalability of the backend:
1. Actions are currently scheduled in the minions using the schedule module of Salt. This brings problems with reliability as for instance a minion can be down at the specified schedule time which leads to actions not being executed. Scalability can be an issue as actions being scheduled for many minions might return results to the server at the same time. Instead it might be better to keep control over scheduled actions on the server to allow batching of actions as well as downtimes of minions or even the server. There is a work in progress branch to get started.
There is a couple of libraries available for asynchronous and non-blocking processing of HTTP requests (in Java) that can be used to avoid having threads waiting for responses in request intensive applications, for example:
- Apache HttpAsyncClient
Many of the Uyuni / SUSE Manager web UIs are still based on the no longer maintained Struts framework (version 1.2!) and implemented as JSP pages, while we added newer features based on the Spark framework and React. For me there is a vision of using only one technology stack (especially just one web framework, frontend framework and template engine) eventually, so it is about time to get rid of the old stack. While this is surely a huge effort, why not start with a new login page and then go from there rewriting other pages one by one?
Things to look at in particular: