Abstract: A method comprising: detecting an event that is indicative of an error that has occurred in a first computing system; identifying a subsystem and an object that are associated with the event; identifying one or more log files that are associated with the subsystem and object; generating a first event report that is associated with the event, the first event report including the one or more log files, the first event report identifying the subsystem and the object that are associated with the event; identifying a support team that is associated with the event based on the object and subsystem; and routing the first event report to the support team.

Abstract: A method comprising: detecting an event that is indicative of an error that has occurred in a first computing system; identifying a subsystem and an object that are associated with the event; identifying one or more log files that are associated with the subsystem and object; generating a first event report that is associated with the event, the first event report including the one or more log files, the first event report identifying the subsystem and the object that are associated with the event; identifying a support team that is associated with the event based on the object and subsystem; and routing the first event report to the support team.

Abstract: An example methodology includes monitoring a replication workflow execution on a storage system and, responsive to a detection of a failure of the replication workflow, determining whether the failure is in a Software Defined Network Attached Storage (SDNAS) or in an underlying storage array platform. The method also includes, responsive to a determination that the failure is in the SDNAS, validating health of the SDNAS for performing the replication workflow and, responsive to validating the health of the SDNAS, performing recovery of the failed replication workflow. The method further includes, responsive to a determination that the failure is in the underlying storage array platform, determining that the underlying storage array platform can be rolled back to a previously known good state for performing the replication workflow, performing a rollback of the underlying storage array platform to the previously known good state, and performing the recovery of the failed replication workflow.

Abstract: A software update manager is configured to collect logs, container statistics, product configuration information, and system state from an application that is being modified when an issue is encountered during a software modification operation. The software update manager includes an issue analyzer that is configured to analyze the reported issue and search knowledge base article database(s) to determine if the reported issue is a known issue or a previously unknown issue. When the reported issue is a known issue, the software update manager retrieves a known workaround and applies the known workaround on the system to resolve the reported issue and continue the planned software modification operations. When the reported issue is a previously unknown issue, the software update manager identifies the correct engineering team responsible for responding to the reported issue and generates a bug fix request that is submitted to a software bug tracking system.

Abstract: A software update manager is configured to collect logs, container statistics, product configuration information, and system state from an application that is being modified when an issue is encountered during a software modification operation. The software update manager includes an issue analyzer that is configured to analyze the reported issue and search knowledge base article database(s) to determine if the reported issue is a known issue or a previously unknown issue. When the reported issue is a known issue, the software update manager retrieves a known workaround and applies the known workaround on the system to resolve the reported issue and continue the planned software modification operations. When the reported issue is a previously unknown issue, the software update manager identifies the correct engineering team responsible for responding to the reported issue and generates a bug fix request that is submitted to a software bug tracking system.

Abstract: An autonomous system for detecting primary site failure on a Replication Data Facility (RDF) and automating failover to a destination site includes a replication data facility health monitor on a destination site that monitors a plurality of health indicators of the primary site. Example health indicators include RDF session state of RDF sessions on the replication data facility, and reachability of a set of IP addresses. Example IP addresses include an IP address of a cluster master node on the primary site, IP addresses of all of the cluster nodes on the primary site, and IP addresses of Network Attached Storage (NAS) servers executing on the cluster nodes. The replication data facility health monitor generates a replication configuration and, upon detection of a failure of the replication data facility at the primary site, uses the replication configuration to automate failover of all of the NAS servers to the destination site.

Abstract: An API reader reads a system application's API specification file and creates a root.yml file containing key:value pairs, in which the keys are objects, and the values are staging_object.yml files. Each staging_object.yml file includes a set of entries, with each entry including a REST operation, a REST endpoint, and a description of the operation to be performed using that entry. An intelligent API converter creates structured object.yml files based on corresponding unstructured staging_object.yml files, and replaces the staging_object.yml files of the root.yml file with the newly created object.yml files. Each object.yml file includes a plurality of entries, corresponding to the entries of the respective staging_object.yml file. Each entry of the object.yml file includes an OPERATION, a JSON payload, and a VALIDATION section. An API builder uses the root.yml file to build a REST API for the system under test which is used to automate testing of the application.

Abstract: An API reader reads a system application's API specification file and creates a root.yml file containing key:value pairs, in which the keys are objects, and the values are staging_object.yml files. Each staging_object.yml file includes a set of entries, with each entry including a REST operation, a REST endpoint, and a description of the operation to be performed using that entry. An intelligent API converter creates structured object.yml files based on corresponding unstructured staging_object.yml files, and replaces the staging_object.yml files of the root.yml file with the newly created object.yml files. Each object.yml file includes a plurality of entries, corresponding to the entries of the respective staging_object.yml file. Each entry of the object.yml file includes an OPERATION, a JSON payload, and a VALIDATION section. An API builder uses the root.yml file to build a REST API for the system under test which is used to automate testing of the application.