Import process + config sets

[Bsherba]

Is this a place to put requests in on top of problems?

It is nice to be able to create and assign config sets from the import window

It would be extra nice to be able to select multiple editors to apply the config set to instead of needing to pull down on each editor.

Particularly for members who have resisted config sets and when guiding them on now to easily adopt them to start, sending all of them to different config sets while stretching their legs.

It is a lot of clicks to do even one server you know?

[thommcgrath]

This is a fine place for feature requests. I can tag commits to issues this way to help keep track of them too.

The import window already has a button to manage config sets. The trouble is order of operation and project editing. What we know of as the import window is actually a merge window. The import process builds a project, then hands it off to the merge system so the new project's contents may be added to the existing project. This essentially makes the "import from other project" a free operation.

There are a few key considerations here. The merge window must be able to be cancelled, leaving the project untouched. The only exception is the Manage Config Sets button, which acts on the project immediately. It needs to do this because only the config sets from the destination project are selectable.

That means to make the source project's config sets selectable, they need to be added to the destination project. To make them selected by default, the destination project needs to have the new config sets first, which means just showing the merge window would add the config set definitions from the source project to the destination project. That's not ok. Plus there are other considerations, such as the fact that config sets are not tracked by name. If your destination already had a "The Island" config set, and the source has a "The Island" config set, they will actually be different sets.

So improving what's already implemented is quite a challenge. There would need to be some UI to import an entire source config set's contents into a destination config set.

[Bsherba]

I suppose I was thinking about this on a more basic level for newer people. Obviously, enhancing the concept for more advanced functionality would be super nice too.

The use case for this post was a gentleman in chat who has 15 projects. We talked about config sets in the past, but he didn't want to take the leap because he didn't want to accidentally misconfigure a few particular servers that are under the payroll of someone else's Nitrado account.

My suggestion was to get his feet wet by simply merging all of them into a single project, and having each server imported into its own config set. This way he could at least have them all deployable from one place while he stretches his legs.

This was simple enough to do, but of course, there was a lot of effort for each server needing to pull down each editor to the config set for each server.

Of course, this is such a low-level application of the config set concept that hardly scratches the surface of its capabilities. As opposed to having a "base" and then overrides, the idea was just to have a config set for Server A including all of it's editors, another for B and so forth.

In other words, it was just a baby step to make cluster management simpler.

I do see that there are logistical problems when we start talking about the fact that REAL use case of config sets involves using the sets across many servers instead, as well as the newer (admittedly requested by me) ability to absorb ALL config sets, even unused ones, from a server to a project.

[Bsherba]

Perhaps an easier solution for this use case of mine, if I understand your response above, would be to tell the user to create a config set in each project with the name of the server and shift all of the editors to that config set.

Upon importing, it sounds like you are saying Beacon would then automatically add the server to the project in this already made config set?

If not, perhaps it could be approached as a feature intended to inherit multiple projects into one for those who are not already familiar with config sets, to accomplish the same goal but "marketed" as the baby step approach?