-
Notifications
You must be signed in to change notification settings - Fork 185
Project Architecture Documentation: Workflows change System Channels
System details page is developed in JSP. However change the channels assigned call a Spark endpoint defined in file "src/com/suse/manager/webui/controllers/SystemsController.java". POST call for "/manager/api/systems/:sid/channels", executing the java method named "subscribeChannels".
The API method will run a set of validation and create a action chain of type "channels.subscribe". See class "ActionChainManager", method "scheduleSubscribeChannelsAction". The result of this call is a new action chain that will be executed by taskomatic.
The only change in the database is create a action chain.
Taskomatic (MinionActionExecutor) will pick up the action at the scheduled time. It will be triggered on the class "src/com/redhat/rhn/taskomatic/task/MinionActionExecutor.java", method "execute". This will load the action chain to be executed, which in this case is of type "Subscribe channels".
Will delegate the execution on the class "src/com/suse/manager/webui/services/SaltServerActionService.java", method "execute". The type of salt call to be made is decided on the method "callsForAction", which will compose the correct call and data depending on the action chain step to be executed. In this case, it will be called the "subscribeChanelsAction" method.
For each minion, generate new channel access tokens and persist these tokens into the db. (SaltServerActionService.subscribeChanelsAction)
Call state.apply channels and pass the new access tokens in the pillar data. This will create/update the zypper .repo files on the minion
Channel access tokens are created and added to the database and linked to the minion. However the link between the minion and the channels (rhnserverchannel) is not created yet. Commit immediately after calling state.apply channels to make sure the return event will find the tokens in the db.
The salt state runs on the minion and the channels are modified
Salt reactor will process salt return event for the channels apply state. File: "src/com/suse/manager/reactor/SaltReactor.java", method: eventToMessages. In this case a "JobReturnEvent" will be processed.
Process the return event. Class "src/com/suse/manager/reactor/messaging/JobReturnEventMessageAction.java" method "execute".
It will delegate in the class "src/com/suse/manager/webui/services/SaltServerActionService.java" method "handleAction" which then delegates to "src/com/suse/manager/utils/SaltUtils.java" method "updateServerAction".
In here it handles all the return action for the server, one of the if statements is comparing/processing "TYPE_SUBSCRIBE_CHANNELS". It will call the "handleSubscribeChannels" of saltUtils.
If the return event is successful:
- The minion is subscribed to the new channels (src/com/redhat/rhn/manager/system/SystemManager.java:updateServerChannels). It does several validations in the JAVA. To create the association a PSQL function is called, which does another set of business logic validation.
- A ChannelsChangedEventMessage event is fired. The next steps are done asynchronously (SystemManager.updateServerChannels)
- An update of the errata cache is triggered (ChannelsChangedEventMessageAction.execute)
- The pillar data is refreshed (ChannelsChangedEventMessageAction.execute)