Host Imaging

Host Imaging Workflow indicates the sequence of actions performed when you run the Host imaging workflow.

Start Host Imaging Workflow

Starting Host imaging workflow is a parent workflow to all the host imaging sub-workflows. It acts as a wrapper workflow and performs imaging on every server presented in the customer input specification.

Running this workflow accomplishes end-to-end imaging operation on all the servers and finally sends an email notification to the recipient addresses with the workflow execution summary.

Workflow path: VMware_Bare_Metal_Automation_4_0/Start_Imaging_Workflow

Requirement: Customer input specification file must be available at a particular location.

The Start_Imaging_Workflow workflow begins by reading the customer input specification file. If the workflow must be executed through a REST API, then body variable value which is taken as an input parameter to the workflow represents the customer input specification JSON file. If the workflow is executed through VMware BMA UI, then the the customer input specification data is read by Read_Provisioning_Spec_Data sub-workflow
The workflow decrypts the encrypted passwords presented in the customer input using the secret key.
The workflow triggers the Pre-validation workflow. This is represented by Pre-validation workflow as captured in the path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Pre_Bootstrapping_Validations/Trigger_Pre_Validation_Workflow_Imaging_Only. This pre-validation workflow first validates all the customer input validations, followed by multiple use cases on pre-validations. Output of this pre-validation sub-workflow gives us a set of valid and invalid hosts. Hosts that failed to pass all the pre-validation use cases are considered as invalid hosts. Such hosts are not part in Host imaging process and are skipped. Actual reasons of the failure is notified to the user through the log messages. All the valid hosts are processed further in the Host imaging operation.
The workflow then proceeds by downloading or copying the default VMware Host ISO image to a particular location.
If the customer input specification is based on dhcp network configuration, then the workflow creates a custom ISO that is built on top of the default VMware Host ISO image. This action is represented by the 4_Create_Custom_ISO_Scripted_Installation sub-workflow.
For every server presented, in the customer input specification, workflow then proceeds to invoke Initiate_Imaging sub-workflow that is represented by this section. This completes the various operations involved in the Host Imaging operation.
If the network configuration of the workflow is dhcp, then this sub-workflow erases the Custom ISO image that was created earlier as part of this workflow as it is no longer required.
Finally, the workflow sends an email notification to the user with workflow execution summary details. This is represented by the sub-workflow Notification_Workflow.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exits out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages and email notification for future reference.

Read Provisioning Specification Data

The Read Provisioning Specification Data workflow reads the customer input specification data. This workflow retrieves the customer input data from the input specification file provided at a particular location through SFTP get operation.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Read_Provisioning_spec_data

Requirement: Customer input specification file must be available at a particular location.

This workflow invokes the Provide_Customer_Input_Data sub-workflow to read the customer input data. It first gets SSH access to the customer input specification file location and then perform sftp_getFile action to retrieve the input data. Finally, it performs JSON.parse operation on the file contents to retrieve the input data in JSON format.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Provide customer input specification

The Provide customer input specification workflow is used to provide customer input specification data by the customer.

Details of the customer input specification is forwarded as output of this action. This is the only workflow where customer must manually input the data into the workflow.

Workflow path: VMware_Bare_Metal_Automation_4_0/Provide_Customer_Input_Data

Manually fill ip_address, username, password, input_json_path details of the webserver.
This workflow returns all the specified customer input specification file details in the JSON format as output.

Initiate Host Imaging

This workflow combines a series of actions together. It binds multiple sub-workflows in a chain manner.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/Initiate_Imaging

Depending on the network configuration set in the customer input specification, various sub-workflows of the Host Imaging operation is carried out serially. This workflow executes per host. So, when multiple servers are presented to be imaged in the customer input specification, this workflow executes in parallel for all the servers.

This operation is carried out for both static and dhcp network configurations.

The host, username, password, raid_level, network_config, host_root_password, network_device_name, vlanid, custom_tag, host_ip, host_fqdn, netmask, gateway, dns_servers, dns_suffixes, iso_attachment_url, iso_image_info, smtp_server_info, server_details, vmware_os_iso_image, os_type variable values are passed on by the parent workflow, Start_Imaging_Workflow. Values passed on by parent workflow are represented by In and Required checkboxes being tick marked. ‘In means that the parameter it is mapped against is an input parameter passed on by its parent workflow. Required means that the value for this parameter is passed by its parent workflow.
Workflow begins by checking if there are any pending jobs at present and waits until all the ongoing jobs are complete. This is represented by sub-workflow CheckJobComplete.
Next, the workflow triggers 1_Delete_Virtual_Disk sub-workflow which erases all the virtual disks if any that was created before. Then, the sub-workflow 2_Detach_ISO_As_Virtual_CD is invoked which unmounts the Host ISO image that was previously mounted on the virtual media.
If the raid_level is set to 1 in the customer input specification for a particular server, then the workflow continues to create the virtual disks on this server. Depending on the number of physical disks available in the Server, virtual disks are created as per the mapping of 2 physical disks to 1 virtual disk scenario. This sub-workflow is represented by 3_Create_Virtual_Disk_Raid_N sub-workflow. If the raid_level is set to 0 in the customer input specification for a particular server, then the creation of virtual disks operation is skipped on this server.
If the customer input specification is based on static network configuration, then the workflow creates a custom ISO (built on top of the default VMware ESXi or PhotonOS ISO image). This action is represented by 4_Create_Custom_ISO_Scripted_Installationsub-workflow. The output of this workflow is an URL representing the custom Host ISO image URL.
Next, the sub-workflow 5_Attach_ISO_As_Virtual_CD is invoked which mounts the new custom Host ISO image to the virtual media.
The sub-workflow 6_Redfish_Reboot is invoked which reboots the server from the virtual media. Once the server is rebooted, the sub-workflow 7_Check_Host_Reachability continuously monitors for the host to be reachable. This monitoring continues for a certain time interval and the workflow expects the host to be reachable within this time limit. If the host is not reachable within this time, then the workflow bails out throwing a timeout error in the log. Since, the workflow bails out from this step if the host is not reachable after a certain time, workflow proceeds to trigger the sub-workflow 2_Detach_ISO_As_Virtual_CD which unmounts the Host ISO image that was previously mounted on the virtual media.
If the network configuration of the workflow is static, then this sub-workflow erases all the Custom ISO images that were created earlier as part of this workflow as they are no longer required.
This workflow ends by triggering the post-validation workflow which performs different validations post the Imaging process. This sub-workflow is represented by Trigger_Post_Validation_Imaging.

Delete Virtual Disk

This workflow deletes all the previously existing Virtual disks on the Server.

If any virtual disks are present on the server, it deletes them. If there are no virtual disks present, then this action is skipped. This operation is carried out for both static and dhcp network configurations.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/1_Delete_Virtual_Disk

host, username, password variable values are passed on by the parent workflow (Initiate_Imaging). Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
Using the REDFISH API Get Storage Collection Instance, the workflow retrieves all the Storage Controllers. The workflow iterates over each Storage controller and proceed to find volumes present in each of these controllers. If there is any exception during this step, the workflow throws relevant exception and bail out of the workflow.
Next, the workflow retrieves all the Virtual disks present in these volumes by making a HTTP GET request. If the count of the virtual disks is greater than 0, then the workflow iterates through each of these virtual disks and delete them one by one, by making a HTTP DELETE request. If the count of virtual disks is 0, then the workflow skips the deletion operation since there are no virtual disks to be deleted.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Detach ISO as Virtual CD

This workflow unmounts the ISO image attached to the Virtual Media of the Server.

If an ISO image is mounted as part of the Virtual media on the server, it unmounts it. If an ISO image is not mounted on the virtual media, this action is skipped.

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/2_Detach_ISO_As_Virtual_CD

The host, username, password variable values are passed on by the parent workflow Initiate_Imaging. Values passed on by parent workflow are represented by In and Required checkboxes being tick marked.
Authorization to the Server is obtained as a first step. Using this access to the server, a HTTP POST request is made to Eject the Virtual Media. This unmounts the ISO image that is mounted on the Virtual media of the server.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Create Virtual Disks

This creates new Virtual disks on the Server.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/3_Create_Virtual_Disk_Raid_N

For every pair of homogenous Physical disks present on the server, this action creates a mirrored version of one virtual disk.

This action is applicable only for RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

host, username, password, raid_level variable values are passed on by the parent workflow Initiate_Imaging. Values passed on by parent workflow are represented by In and Required checkboxes tick marked.
Using the REDFISH API (Get Storage Collection Instance), the workflow retrieves all the Storage Controllers or instances. The workflow finds all the storage instances which contain RAID term in it to filter and list only the RAID based Storage controllers. The workflow iterates over each of these filtered Storage controllers and proceed to find volumes present in each of these controllers by making a HTTP GET request. If there is any exception during this step, the workflow throws relevant exception and bail out of the workflow.
Next, the workflow iterates again over each of these filtered Storage controllers to find all the physical drives present in each of these controllers by making a HTTP GET request. For every pair of physical drives, an object ($available_drives) is formed with a comma separated combination of two drives so that 1 virtual disk can be created as a mirrored version of these two physical drives.
Next, the version of the firmware installed on the Server is found out. This is because, RAID level attributes are recognized differently between different versions of the firmware version.
If firmware version is less than 4.4.0, the RAID levels are recognized as:
```
{
   "0":"NonRedundant",
   "1":"Mirrored"
}
```
If firmware version is greater than 4.4.0, the RAID levels are recognized as:
```
{
   "0":"RAID0",
   "1":"RAID1"
}
```
Using a HTTP POST request, virtual disks are created (1 virtual disk per a pair of physical disks).
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Create Custom Host ISO image for automated installation

This action creates custom Host ISO image which helps to perform automated installation of Host on the VMware Bare Metal server.

Kickstart file is required to perform automated ESXi or PhotonOS installation. This kickstart file must be generated dynamically tailoring to the host details and must be made part of boot configurations inorder to perform automated ESXi or PhotonOS installation. This sub-workflow action is responsible to generate a custom Host ISO image that performs boot up by operating as per the instructions mentioned in the kickstart file.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/4_Create_Custom_ISO_Scripted_Installation

This operation is carried out for both static and dhcp network configurations.

host, username, password, network_config, network_device_name, vlanid, host_root_password, iso_image_info, os_typesmtp_server_info, current_vmware_os_iso, global_tag (if network configuration is dhcp) variable values are passed on by the parent workflow (Initiate_Imaging if network configuration is static and Start_Imaging_Workflow if network configuration is dhcp).
Additionally, if the network configuration is static, custom_tag, host_ip, host_fqdn, netmask, gateway, dns_servers, dns_suffixes variable values are passed on by the parent workflow (Initiate_Imaging). Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
The workflow generates a new kickstart file per host (if network configuration is static) or a single kickstart file for entire set of hosts as presented in the customer input specification (if network configuration is ‘dhcp’).
Depending on the os_type (either esxi or photon), the workflow prepares a kickstart file with attributes that are specific to the OS type chosen by the customer to be installed.
Next, the workflow creates a custom ISO image by wrapping the generated kickstart file as per requirements. The workflow creates a different custom Host ISO image per host (if network configuration is static) or a single global custom Host ISO image for entire set of hosts as presented in the customer input specification (if network configuration is dhcp). genisoimage utility is used to create custom Host ISO images.
Both kickstart file generation and custom ISO image generation is achieved through a set of SSH and SFTP blocks available in VMware BMA.
Next, the workflow creates a custom ESXi or PhotonOS ISO image by wrapping the generated kickstart file as per requirements. The workflow creates a different custom Host ISO image per host (if network configuration is static) or a single global custom Host ISO image for entire set of hosts as presented in the customer input specification (if network configuration is dhcp). genisoimage utility is used to create custom Host ISO images.
Both kickstart file generation and custom ESXi or PhotonOS ISO image generation is achieved through a set of SSH and SFTP blocks available in VMware BMA.
Finally, return the result as Host ISO image URL which is the HTTP location of where the custom Host ISO image is stored.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Attach ISO as Virtual CD

This workflow mounts the ISO image to the Virtual Media of the Server.

ISO is customized as per the requirements of Network configuration. If the input specification specifies the network configuration to be set to dhcp, then a Global customized ISO is mounted on the Virtual media. This mountpoint is a common one for all the hosts presented in the input specification. If the input specification specifies the network configuration to be set to static, then a Unique customized ISO is mounted on the Virtual media, for every host presented in the input specification.

If the value for the image_url_scheme attribute in the iso_image_info section of the customer input specification is https, then a https based location of the ISO image is mounted. If the value is set as http then a http based location of the ISO image is mounted on the virtual media.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/5_Attach_ISO_As_Virtual_CD

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

host, username, password, os_image_url variable values are passed on by the parent workflow (Initiate_Imaging). Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
Authorization to the Server is obtained as a first step. Using this access to the server, a HTTP POST request is made to Insert the Virtual Media. This request takes a ESXi or PhotonOS Image URL path in the body section of the request. This step mounts the ISO image on the Virtual media of the server.
Next, a HTTP POST request is made to set a One-time Boot option from the VCD-DVD. This makes sure to boot the server from Virtual CD/ROM media type upon next reboot.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Redfish Reboot (Reboot of the server)

This workflow reboots the server. This performs POWER OFF and POWER ON operations serially.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/6_Redfish_Reboot

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

host, username, password variable values are passed on by the parent workflow (Initiate_Imaging). Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
Power OFF operation is performed on the Server. This action invokes another sub-workflow Off_Redfish. Authorization to the Server is obtained as a first step. Here, a REDFISH API redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset is invoked to power off the server: with the body content {'ResetType': 'ForceOff'} as the attribute value.
Power ON operation is performed on the Server. This action invokes another sub-workflow On_Redfish. Authorization to the Server is obtained as a first step. Here, a REDFISH API redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset is invoked to power on the server: with the body content {'ResetType': 'On'} as the attribute value.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Check Host Reachability

This workflow checks if the host is reachable post Host Imaging operation.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/7_Check_Host_Reachability

This action loops continuously to find if the host is reachable after imaging operation. It monitors continuously until a certain time limit is reached. If host is reachable within that time, it returns response that the host is reachable, and the next steps continue. If the host is not reachable within a pre-defined timeout interval, this action bails out from the workflow.

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

host, username, password variable values are passed on by the parent workflow, Initiate_Imaging. Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
First, hostname of the host is retrieved by invoking the REDFISH API Get Computer System Interface. Then, the ping command is used to find if the host is reachable or not.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Check Job Completion

This workflow checks for any pending/ongoing/stale jobs and return the status of job completion.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/CheckJobComplete

This action loops continuously to find if all the ongoing jobs have reached completion stage. It monitors for completion of all jobs continuously until a certain time limit is reached. If job is completed within that time, it returns successful response. If the job is not completed within the given time, this action bails out from the workflow.

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

host, username, password, timeOutInSeconds variable values are passed on by the parent workflow (Initiate_Imaging). Values being passed on by parent workflow are represented by ‘In’ and ‘Required’ checkboxes being tick marked.
This action invokes a REDFISH API – Get Job Collection Instance to find out all the In-Progress or Pending jobs. This step continues in loop until either all the jobs are in Completed state or a certain timeout interval is reached. For every In-progress job, this action next invokes another REDFISH API – Get Job Instance to find out the specific job among the collection of ongoing jobs, to track if this specific job has reached 100% completion or not. If within the timeout interval, if all the jobs have completed, then this workflow returns a successful response. Else, the workflow bails out marking the workflow as failure.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Erase all the Custom ISOs created on the Webserver

It deletes all the Custom ISO images that are created on the web server. For DHCP network configuration-based workflow, only 1 custom ISO is created. Hence, this workflow deletes only this ISO image. For Static Network configuration, 1 custom ISO image is created per Server presented in the input specification. Hence, in this case, all these custom ISO images is deleted at the end of the workflow.

This action is applicable for both RAID level 0 and RAID level 1 settings. This operation is carried out for both static and dhcp network configurations.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Imaging/Imaging_Sub_Workflows/Erase_custom_iso_images

host, tag_name, network_config, iso_image_info variable values are passed on by the 2 parent workflows (Initiate_Imaging in case of Static Network configuration and Start_Imaging_Workflow in case of DHCP network configuration). Values passed on by parent workflow are represented by selected In and Required checkboxes.
Authorization to the Server is obtained as a first step.
SSH operation is performed by using the Web server credentials. In case of Static Network configuration, this SSH operation performs deletion of all the custom ISO images created on the Web server using rm -rf bash command for every custom ISO image created per host. In case of DHCP Network configuration, this SSH operation performs deletion of the one golden custom ISO image created on the Web server using ‘rm -rf’ bash command. If the SSH operation does not return any error, then the removal of custom ISO operation is deemed successful. If SSH operation returns error, then an error has occurred while removing the custom ISO images and bail out throwing appropriate error messages.
For every action in this workflow, error handling is in place. If due to any reason, there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

Post-validation workflow

This workflow performs different validations to check if the Host Imaging operation is successful or not.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Post_Bootstrapping_Validations/Trigger_Post_Validation_Imaging_Only

This workflow performs few post-validation checks and captures the result. In case of failure, the you get an error message.

To accomplish this step, the parent workflow (Start_Imaging_Workflow) provides the appropriate values for Trigger_Post_Validation_Imaging_Only workflow in start section. Parent workflow handles the execution accordingly.

To achieve the end goal, this workflow performs the below actions:

Post-validations start once the parent workflow (Start_Imaging_Workflow) provides the input for server_detail, network_config, host_root_password, valid_iso_image fields.
This workflow reads the input details and performs the post validations based on the network configuration type such as static or dhcp.
Below is the list of sub-workflows which post-validation workflow consumes for further validation:
- Validation check for host reachability: Validate if the IP/FQDN which is assigned to the Bare Metal is accessible post imaging. This sub-workflow uses ping command to accomplish this task
- Host installed version validation: This sub-workflow uses ssh command such as vmware -v for ESXi OS and uses /etc/photon-release for PhotonOS to validate whether the Host installed OS version is valid.
- Uptime check on the host: This sub-workflow provides the host up time using the ssh command such as uptime.
- Stale datastores check: This sub-workflow uses the ssh command such as esxcli storage filesystem list for ESXi OS and df -h for PhotonOS to identify if any stale datastores are present on the server.
If post-validation phase succeeds successful result displays as response. For failure, an error message displays.
Error handling is performed for every action in this workflow. If there is an issue in the operation steps, the workflow captures this failure and exit out of the current sub-workflow execution marking the reason for failure. Both success and failures are also captured as part of the log messages for future reference.

E2E Post-validation Flow Walk Through

Notification workflow

This action sends a mail to all the recipient addresses about the summary of the workflow execution. Recipient addresses are as provided in the customer input specification.

Workflow path: VMware_Bare_Metal_Automation_4_0/OOTB_Workflows/Notification/Notification_Workflow

This action uses the VMware Bare Metal Automation Platform’s Email plugin. Using this plugin, an email is sent from a particular sender email address to the different recipient email addresses as provided in the customer input specification. This plugin takes SMTP server details as input to make sure a connection is established for the email communication.

This action is applicable for Server Imaging, independent pre_validation and Collect Server Information workflows.

Along with SMTP server details and user credentials, Email plugin authentication also needs below email security related properties to be set:

Secure
IgnoreTLS
Require TLS

For example, one of the working combinations for an email notification is:

Secure is set to False

IgnoreTLS is set to False

RequireTLS is set to True

smtp_host, smtp_username, smtp_password, smtp_port, sender_address, recipient_email_addresses, workflow_name, timestamp, task_status, result_content, table_content variable values are passed on by the parent workflow.
- In case of Server Imaging workflow, the parent workflow is Start_Imaging_Workflow. In case of Collect Server Information workflow, the parent workflow is Trigger_Collect_Server_Information workflow. Values being passed on by parent workflow are represented by In and Required checkboxes being tick marked.
Email plugin block is invoked to send an email. Well formatted HTML page is part of the Email block. This HTML page contains workflow execution details, total time taken and the status of the workflow. If there is an error during the Email notification action, error appears. Else, a successful response is sent back to the user as an email.