Bug Report

System Information

• Operating System (Including distribution name and version number) Ubuntu 20.04.5 LTS
• AMP version and build date (Always use the version number, 'latest' is not valid!) 2.4.0.10
• Which AMP release stream you're using (Mainline, Nightly or FastTrack) Mainline

I confirm:

• [x] that I have searched for an existing bug report for this issue.
• [x] that I am using the latest available version of AMP.
• [x] that my operating system is up-to-date.

Symptoms

• What are you trying to do? Change permissions on a user for an instance that has just been provisioned
• What are you expecting to happen? Go to permissions for a user, see the instance as a permissible instance
• What is actually happening? ('Nothing' is not an acceptable answer!) Instance does not appear in the list to assign permissions.

Reproduction

Provision a new instance from a controller to a target Go to assign permissions for a user to that instance - notice it doesn't exist Restart controller It now exists.

Note that in addition to this, if provisioned via WHMCS, the user that is created for the client does not get permissions to the instance either, so they don't exist.

This has been addressed in CI, when the instance list changes the permissions node cache is now invalidated (it was doing this already, but not for template deployments) and the frontend is notified of the change, which prompts it to re-query the list of available permissions (including as a result, new/removed instances regardless of which target they're on) - this also prompts the frontend to re-query the list of users so that users that were created as a result of a template deployment are now available in the UI without even having to refresh the page never mind restarting the controller itself.

Sorry to reopen this. I do still experience this issue. I thought this should be fixed with 2.4.1.2

https://discourse.cubecoders.com/t/amp-halimede-2-4-1-release-notes/2743

Permissions node cache is properly invalidated when instances are created/destroyed so it’s not necessary to restart/refresh ADS to assign permissions to newly created instances.

• Operating System (Including distribution name and version number)
  Debian 11 (On Controller and Target)
• AMP version and build date (Always use the version number, 'latest' is not valid!)
  AMP Release "Halimede" v2.4.1.2, built 21/12/2022 17:54
• Which AMP release stream you're using (Mainline, Nightly or FastTrack) Mainline

To clarify, based on the previous response from dev:

The issue isn't that the user themselves do not appear, however it is the instance itself that does not appear in permissions lists, such as giving a user permission to Start, Stop, Update and Manage an instance - when on the controller looking at the dropdown of the target within the "All Instances" dropdown menu, the new instance does not appear until ADS is restarted.

Re-opening issue.

The issue persists with v2.4.2

To clarify more, I guess we are talking about creating a new instance on a target and if we want to give a user permission to that instance it doesn't appear in the list like shown in the screenshot until a restart of the controller ADS.

Does the new permission node appear within the target? I think this is just a propagation issue.

Indeed, the new permission node appears within the target

This is still an issue 8 months later. This needs to be resolved.

There were changes put in recently that should have improved this, but seems there's still cases people are experiencing it. Is it consistent or do you see any kind of pattern with it?