Can users cancel the process? I mean, suppose I added a host and then realize I made a mistake or need to check something first, so I quickly try to cancel. Will it cancel the process, or will the process continue working in the background? This question makes all the difference because the system response is entirely different, and so will the user experience.
Now, if users can't cancel or stop the running process and the reason for the button is just to close the modal, then I'd get rid of the cancel button and add a simple "Close" text link. If you can't cancel anything, then the cancel button shouldn't be there at all.
Just in case, your use case can be seen under the light of Shneiderman's 8 golden rules of UI, specifically Rules 4 to 7 (included):
4. Design dialogs to yield closure.
Sequences of actions should be organized into groups with a beginning,
middle, and end. Informative feedback at the completion of a group of
actions gives users the satisfaction of accomplishment, a sense of
relief, a signal to drop contingency plans from their minds, and an
indicator to prepare for the next group of actions. For example,
e-commerce websites move users from selecting products to the
checkout, ending with a clear confirmation page that completes the
transaction.
5. Prevent errors.
As much as possible, design the interface so that users cannot make
serious errors; for example, gray out menu items that are not
appropriate and do not allow alphabetic characters in numeric entry
fields (Section 3.3.5). If users make an error, the interface should
offer simple, constructive, and specific instructions for recovery.
For example, users should not have to retype an entire name-address
form if they enter an invalid zip code but rather should be guided to
repair only the faulty part. Erroneous actions should leave the
interface state unchanged, or the interface should give instructions
about restoring the state.
6. Permit easy reversal of actions.
As much as possible, actions should be reversible. This feature
relieves anxiety, since users know that errors can be undone, and
encourages exploration of unfamiliar options. The units of
reversibility may be a single action, a data-entry task, or a complete
group of actions, such as entry of a name-address block.
7. Keep users in control.
Experienced users strongly desire the sense that they are in charge of
the interface and that the interface responds to their actions. They
don’t want surprises or changes in familiar behavior, and they are
annoyed by tedious data-entry sequences, difficulty in obtaining
necessary information, and inability to produce their desired result.
EDIT: Answering comment
If the user wants to cancel the host-adding process, they can simply close the dialog.
To be clearer and cater to more generic scenarios than your specific one:
Ideally, actions should have two parts: a DO and an UNDO (hence why I mentioned the UI rules above).
In this particular case, there are two actions: the first one is user-driven and denotes the intentionality of the user to add a host (this is the DO), for which the user starts a flow that begins by opening a dialog. This action is interrupted by Close (the opposite or counterpart of open). That would be the UNDO.
Then there is a second action, which is initiated by the user when clicking the "add" button. This second user-driven action starts a system-driven action (adding the record to a DB or whatever). This action could be canceled or not (in your case it can't). But assuming that you could, the label would be "Cancel" (or "Stop" if it's a slow process, or similar wording as needed), because you're canceling the process that is occurring in the background.
Then again, since it's not possible to stop this process, the cancel button shouldn't be there; this secondary system-driven action has no possible counterpart. However, I assume the user can recover from a possible error by editing the host again.
