Evaluate the decision to prepend "dev-" to runner systems created using web interface about fluffi HOT 4 CLOSED

I favor the idea of getting rid of the "dev-" systems. Imho all systems should be treated equally, if possible.

However, we need to review the code to see what breaks if we remove this.

from fluffi.

I agree with you here and I will review and remove dev- (if possible). In addition, every system should be removable in the web gui and not just dev- systems.

from fluffi.

Personally, I also favor a design that

1. treats every host equally,
2. sees the web interface as the GUI method of performing CRUD in the DB, and
3. sees the DB as the single source of truth of the inventory of runner systems.

In this design, the Ansible inventory specification will follow a common pattern for cloud applications: a dynamic inventory, overlayed with overrides through the file system if necessary. (In older designs, adding overrides through the file system is often necessary due to schema inflexibility; nowadays we can use a JSON column to allow pretty much any overrides.)

P.S. Speaking of Ansible inventory, I suggest favoring YAML over INI, even for human-written files. When an inventory have enough number of subgroups, editing the INI will become quite difficult.

from fluffi.

• treats every host equally,
• sees the web interface as the GUI method of performing CRUD in the DB, and

These two ideas for the design are now implemented in #107

We have decided that Polemarch's host file is our source of truth. After launching the web user interface, a function is called in which the systems are retrieved from Polemarch and added to the database after you have added a location. At runtime, you can delete any system, add new systems, change locations, ...
If you restart the Webui, everything is deleted from the database that is not declared in the host file. When declared, it is added to the database.

from fluffi.