With the next version I plan to add initial support to manage KPS in the same way as other entities. This means to provide the following features:

[acirami]

@cwiechmann
What happen to this? I don't see support for KPS?

          With the next version I plan to add initial support to manage KPS in the same way as other entities. This means to provide the following features:

• get existing entries (Console, JSON, CSV, etc.) from a given table/alias
  • Filter support
• import/replicate KPS entries based on JSON desired state
  • to replicate the KPS-ID is used to decide if update or create an entry
  • the desired state may contain multiple KPS Tables/Aliases and entries for each
• delete entries based on the given filter

In the version after KPS-Dependencies can be added to an API. This dependency will be the KPS-Alias plus the Entry-ID. This kind of fragment will then be added to an API on the root level:

kps: [
  {“kpsAlias”:”tableABC”, “kpsKey”:”123456”},
  {“kpsAlias”:”tableXYZ”, “kpsKey”:”987654”}
]

With that, during replication of an API the CLI validates that the required KPS entries do exists. The required KPS entries must be imported before using the KPS import feature added with the next version.
The KPS dependency information is planned to be stored in a custom property and based on that also exported.

Originally posted by @cwiechmann in #6 (comment)

[gcornacchia]

I vote for this feature too!!!

[emmanuel-galindo]

me too, this seems useful