Configuration Plans get "orphan" when changing Role Name they are assigned to

[Guest]

So I changed a couple of Role names into something more logical. However, after I did that, I noticed that Configuration stopped being checked. When looking at configuration jobs, I had several configuration plans that had [R] next to their name and I was unable to edit them just delete them.

Steps to Reproduce:

1. Create a new role
2. Create Configuration plan for that role
3. Rename Role
4. Wonder where Configuration Plan went for that role
5. Check Configuration Plan view in Otter, realized Configuration Plan is now "orphaned"

I didn't get any warning this would happen but not sure why this would happen to begin with.

I assume I could fix this in the database or maybe via API, either seem like unacceptable headache for the user.

Product: Otter
Version: 2.0.5

[Guest]

Hi
The configuration are not "move" when you change the role name whatever the used raft.It seems to be the "normal" behavior since 1.7.2 at least. Nevertheless it looks lik a bug :-)

The only way is to create a new role and cut and paste the config from the old role.
In your case, just cretae a new role with the old name, you will see your configuration

[Guest]

I now understand how to fix it. I still assert it's a "bug" or "feature request". You have ServerRole_ID in database under ServerRoles Table. Why are you going based of name? That seems like recipe for disaster as I found out. Tie RaftItems like that to ServerRole ID in database, that way names can be changed and no one is bothered. I could even have Configuration Plans names that don't match Server Roles or Same configuration plan assigned to multiple roles.

I'm aware easier typed then done. Something to throw on list of "feature requests".

[Guest]

Chris, thanks for the suggestion. I agree, it's totally suboptimal, and as such as I've filed OT-208

But I want to take the opportunity to explain the design. Configuration plans are stored in rafts, which are a sort of abstract file system.

Rafts offer a tremendous amount of benefits, including portability across instances and the ability to edit outside the UI. But one major drawback (as you notice) is that we have to use names for everything.

In order to properly handle a rename of a server or role, we would need to dispatch an execution (via the service) that does the following:

• inputs the desired, UI-validated new name of the role
• renames the role in the database
• attempts to move item (create new , delete old) in the raft
• on failure, attempt a rollback of the raft item and role rename

So, this is a lot of complexity, and it's error-prone and can leave things in a weird state. Communicating these errors is also a challenge to the user... and it's an uncommon enough operation that, perhaps, it's ideal to just handle "manually".

I will make sure we better document this though,

[Guest]

Hi

Another point of complexity is the use of script and files in the raft.
Lets say, you define myraft and a file called myfile in this raft.
You make a plan whatever the raft you use and call myfile from myraft
Your code will contain something like ....myraft::myfile

But if you rename myraft to mynewraft the plan won't change and it will fail at the next run. The only way to handle correctly the raft renaming would be after changing the raft name to parse all the plans and configurations and templates in all the rafts to replace myraft::myfile by mynewraft::myfile.

So renaming a raft is not so simple, according my understanding of Otter :-)