Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: A system for managing firewall rules between different services. In certain instances, the method includes receiving a discovery graph comprising a plurality of services and at least one application programming interface (API) dependency, wherein the plurality of services comprises a first service and a second service. In some instances, the method further includes determining whether the second service is permitted to receive an initial communication from the first service based upon the at least one API dependency included in the discovery graph. And, in response to determining the second service is permitted to receive the initial communication from the first service, the method can include establishing a first rule for a firewall between the first service and the second service, the first rule allowing the second service to receive the initial communication from the first service.

Abstract: A system for managing firewall rules between different services. In certain instances, the method includes receiving a discovery graph comprising a plurality of services and at least one application programming interface (API) dependency, wherein the plurality of services comprises a first service and a second service. In some instances, the method further includes determining whether the second service is permitted to receive an initial communication from the first service based upon the at least one API dependency included in the discovery graph. And, in response to determining the second service is permitted to receive the initial communication from the first service, the method can include establishing a first rule for a firewall between the first service and the second service, the first rule allowing the second service to receive the initial communication from the first service.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: Systems and methods are provided for coordinating the deployment of frontend assets to defined user groups. Individual groups of users may be assigned to a track comprising a set of frontend assets. Each set of frontend assets may comprise each of the individual components required to generate an entire frontend for an application. In some embodiments, different versions of a single component may be assigned within different tracks. As such, one set of users may be provided a first version of an application and a second set of users may be provided a second version of that application. By associating a new or updated version of a component to a given track, a new or updated version of a component not yet ready for widespread deployment may be provided to only a limited number of users.

Abstract: One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.

Abstract: There is disclosed a system comprising a solar electricity system, comprising a solar collection surface adapted to convert light into DC electricity; a mounting bracket connected to a corner of the solar collection surface, the mounting bracket comprising a hole therethrough adapted to receive a fastener to mount the system to a building structure.

Abstract: There is disclosed a system comprising a solar electricity system, comprising a solar collection surface adapted to convert light into DC electricity; a mounting bracket connected to a corner of the solar collection surface, the mounting bracket comprising a hole therethrough adapted to receive a fastener to mount the system to a building structure.