Connections
Managed and Unmanaged Connections
Each Meshery Model can contain one more ConnectionDefinitions (files), each Definition representing one Connection, and also, (as a matter of convenience multiple Connections can be described in the same ConnectionDefinition file).
Connections can be:
- a ConnectionDefinition based Meshery’s Connection Schema with hand-curated Connection attributes.
- a custom ConnectionDefinition based Meshery’s Connection Schema that references an existing Component within the same Model.
Managed Connections
Unmanaged Connections
States and the Lifecycle of Connections
Every connection can be in one of the below mentioned states at any given point of time. To better understand these states, consider you have a Kubernetes
cluster with Prometheus
already installed.
1. Discovered
All resources discovered by MeshSync’s multi-tier discovery or provided as part of config, and if Meshery can integrate, a connection with state as Discovered
will be created. Though, the connection/resources are not tested for its reachability/usability i.e. Meshery has not made an attempt to connect or manage the connection.
When a connection has been discovered, it will be listed in the MeshSync browser / Connections table in Meshery UI. You can self transition a particular connection to Register / Ignore state.
Example: MeshSync discovers Prometheus components and inform Meshery Server about available Prometheus connection, but Meshery is yet to connect and start scraping metrics.
2. Registered
The connection in this state have been verified for its use and reachability but not yet being used. Almost all reachable connections will auto transition to Registered state from Discovered state and it is upto the user what to do with this connection (i.e. User needs to administratively process the connection). It can be transitioned to Connected, Maintenance and Not Found.
EExampleg: User manually selects the registered Prometheus connection and transition to the connected state (i.e. User administratively processes the connection).
3. Connected
The connection in this state is administratively processed and being actively managed by Meshery. User can interface and invoke set of actions with the connection.</br> From this state the transition can happen to either Maintenance or Ignore state. </br> Auto transition to Disconnected state will occur if Meshery can no longer communicate with the connection, which can occur due to connectivity issue/AuthN-AuthZ/connection was deleted outside Meshery or any other issue.
Example: Meshery is communicating with Prometheus APIs to scrape metrics and present it in the UI.
Certain connections can auto-transition to connected state.
4. Ignored
The connection is administratively processed to be ignored from Meshery’s view of management. Meshery will not re-discover this connection even when current user session gets expired.
Example: Meshery server will stop/not scrape metrics from Prometheus. Though, the previous data (if connected previously) will continue to exist and user needs to manually delete.
Ignored versus Disconnected
You might intentionally choose to have Meshery ignore a given Prometheus connection, explicitly leaving in Meshery’s field of view, but identifying it as a connection not to manage. This is distinctly different than a Prometheus that Meshery was managing, but has been turned off/uninstalled and now Meshery is disconnected from the Prometheus.5. Maintenance
The connection is administratively processed to be offline for maintenance tasks. This is different from being Disconnected/Ignored.
6. Disconnected
The connection was previously discovered/registered/connected but is not available currently. This could happen due to connectivity issue/AuthN-AuthZ/connection was deleted outside meshery/administratively disconnected.
Example: Prometheus crashed/API token provided at time of registration is revoked.
Disconnected vs Deleted
The connection was previously connected but is unreachable due to connectivity issue/AuthN-AuthZ/connection was **deleted outside Meshery** i.e. Connection was deleted beyond the Meshery's view of management.7. Deleted
The connection is administratively processed to be deleted and removed from Meshery’s view of management. All the available/collected data will also be deleted.
Example: Prometheus metrics will no longer be accessible to you from the Meshery UI.
8. Not Found
User tried registering the connection manually but Meshery could not connect to it or if the connection is unavailable now. User can delete the connection or try re-registering.
Not Found vs Disconnected
You might attempt to transition to Connected state but the connection is unavaialble now due to being deleted/some other reason. This is distinctly different than a cluster with Prometheuses installed for `application monitoring` which was connected previously but is now unreachable from Meshery's view of management due to change in API token/similar issue.Connections like Registration of Meshery server with remote provider (and few other connection types) can self transtion to the valid states.
Suggested Reading
- Components - Meshery Components identify and characterize infrastructure under management.
- Credentials - Meshery uses one or more Credentials when authenticating to a managed or unmanaged Connection.
- Designs - Meshery Designs are descriptive, declarative characterizations of how your Kubernetes infrastructure should be configured.
- Environments - Meshery offers support for Kubernetes cluster and cloud state synchronization with the help of MeshSync.
- Models - Meshery uses a set of resource models to define concrete boundaries to ensure extensible and sustainable management.
- Patterns - Meshery Patterns are descriptive, declarative characterizations of how your Kubernetes infrastructure should be configured.
- Policies - Meshery Policies enable you with a broad set of controls and governance of the behavior of systems under Meshery's management.
- Relationships - Meshery Relationships identify and facilitate genealogy between Components.
- Workspaces - Meshery Workspaces act as central collaboration point for teams.