Skip to content

Project Architecture Documentation: Workflows change System Channels

Ricardo Mateus edited this page Sep 9, 2024 · 1 revision

ChangeChannelsWorkflow

Step 1 - API call

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.

Step 2 - taskomatic and salt call

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.

Step 3 - Salt state applied on minion

The salt state runs on the minion and the channels are modified

Step 4 - Salt reactor

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.

Step 5 - handle the salt job return

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)
Clone this wiki locally