Feature ideas

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.

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 you can't understand what issues the Github integration has besides the Port API audit log, and issues can happen , for example: 1) GitOps typo is not reflected in Port 2) Wrong mapping is not reflected 3) Sync process is not reflected

TLDR - if Terraform is not creating the port_integration resources, then it should not delete them either ------- As per https://docs.getport.io/guides/all/import-and-manage-integration/ , when setting up a new integration via Terraform, it is necessary to first manually create the integration via the "Builder" UI, and then import this to Terraform. This creates a problem for projects which are subsequently rolled back - e.g. some change has broken a feature in the IDP, potentially unrelated to the new integration. Consider the following sequence: Integration created manually Integration imported into Terraform Changes are applied to the live Port instance (terraform apply) Something in that release is identified as breaking - so we need to roll back to an earlier version Earlier release is deployed - terraform plan & apply is run again, from an earlier version of the code Terraform sees that the integration wasn't present in the earlier version, so it deletes it from both the live portal and the terraform state! Now we're back to square-one, and having to re-create the integration, with a new installation id, all over. Terraform has a convention for resources which aren't directly managed via IaC - Data Sources. I suggest the Port provider should: Offer a "Data Source" to lookup an existing integration, by id / name Update the "port_integration" resource to only manage the config of the integration - not the integration itself

We need the ability to pause and resume data source syncs. While we understand that rate limits determine the sync frequency, having the option to pause and resume would give us control over the order in which data sources sync. This capability is essential as we gradually roll out Port to different teams, ensuring their service data is accurately captured and reviewed before proceeding to the next team.

Currently, Port lacks a command-line interface (CLI) tool for creating blueprints, entities, scorecards, and other functionalities. Introducing such a tool could provide valuable assistance to users.

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.

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).

Can Port support ingesting AWS costs from the Cost explorer API? https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/Welcome.html There is an official aws plugin for backstage that does this https://github.com/awslabs/backstage-plugins-for-aws/tree/main/plugins/cost-insights The link provided here is no longer valid. https://roadmap.getport.io/ideas/p/aws-exporter-support-cloud-resources-costs

Currently we are having to use the k8s exporter to get Rollout level data. We'd prefer to use the ArgoCD Ocean Integration as it supports Realtime updates through the webhook event approach