Feature ideas

Include a new blueprint of Opsgenie Comment and return the list of comments related to each Opsgenie Alert in the Opsgenie Integration.

Today Port hosted integrations are working on a schedule-basis, and ideally it would be better to be able to create real-time integrations hosted in Port.

Current Behavior: The 'Kinds to Test' section currently proposes samples based on the kind to test. However, since each kind can have multiple mapping blocks, this approach doesn't provide appropriate samples to validate individual mappings effectively. Proposed Change: Modify the testing section to propose samples based on mapping blocks instead of kinds. This change will allow users to select appropriate mapping samples to test specific mappings more accurately. Benefits: Improved mapping validation: Users can test each mapping block individually, ensuring more thorough and accurate testing. Better test coverage: By focusing on mapping blocks, we can ensure that all mappings are tested, not just a general sample for each kind. Increased efficiency: Testers can pinpoint and validate specific mappings more easily, potentially reducing the overall testing time. Implementation Details: Update the sampling algorithm to consider individual mapping blocks rather than just kinds. Modify the user interface to display mapping block-specific samples. Ensure that the sample selection process covers all mapping blocks within each kind.

Currently, self-hosted Ocean integrations require organizational credentials. Ideally, service account credentials should be used to improve security and create different tokens for different integrations.

Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties. Example of Tags property with type of array: Current state: "Tags" : ["tag1"] Ingesting a new tag using the API: "tag2" New state: "Tags": ["tag1", "tag2"]

Admins should be able to leave comments in the data source mapping.

As a builder, I want to understand my integration status so I will be able to fix errors and keep my Portal up-to-date === We want to show a more apparent status and surface outstanding errors with the integration

Currently, each data source requires specific mapping configurations tied to the exporter / integration deployment phase. This approach is inefficient when managing multiple data sources. We propose implementing a centralized and versioned configuration in Port to improve this process. Proposal: Port will store a list of mapping configurations for each integration type. Each data source will have an option to specify which configuration version to use and whether to stream data into port or not. This will allow sharing configurations between different exporters of same integration. The process will decouple data source management from exporter / integration rollout. Benefits: Reduced configuration duplication Easier updates and maintenance Improved scalability for managing many data sources Consistent configuration across environments This feature aims to streamline data source management, making it more efficient for teams working with multiple data sources. --- ## Additional explanation based on k8s integration Today, each k8s cluster is represented as a separate data source without any control over shared configuration for all clusters, in addition k8s data source can't be created on demand and depends on deployment of k8s exporter. Each configuration change needs to be applied to all k8s data sources explicitly either via API/UI/Terraform or based on config-maps deployed on each cluster. After applying the proposed approach, port builders will be able define and share configuration among multiple k8s clusters and apply experimental changes gradually. How this could work in practice: every k8s exporter is deployed on each k8s cluster when it is supplied with appropriate credentials to access port and publishes only the cluster name. In addition the exporter subscribes to receive new instructions from port (which data to stream). port builders (developers) discover all k8s clusters associated to their account and choose which clusters should be enabled as data sources and which mapping configuration version should be applied. This way k8s exporters are deployed once and upgraded only when there is a new version of exporter. The control over data input is managed centrally from port and configurations can be shared among multiple data sources of same type.

Today to install the cloud integration of Azure, you can do it using one Ocean deployment, and to have it done in real-time you need to setup event-grid for each account. When dealing with hundrads of accounts it becomes impossible to manage, so the feature idea here is to be able to handle hundreds of account through one integration that is done as real-time as possible, and allows you to scale for a big number of accounts.

It would be great to have an AI assistant with the context of previous mappings created in Port that can help me create mappings for my blueprints for each exporter. Even if it won't be 100% precise, it could save me a lot of trouble and time. It can help with writing and creating the mapping independently (e.g., finding relations between entities natively).