Closed carlesarnal closed 8 months ago
Couple of questions:
Couple of questions:
- Does Apcurio support the CloudEvents standard for messages?
Yes, we currently support firing events the the CloudEvents format for the different operations happening in Apicurio Registry to both and HTTP sink or to Kafka . Aditionally, we did some PoCs in the past around the standard, like this one.
- Are there ways to use Apcurio with the Kubernetes API?
No, we do have a Kubernetes operator to manage Apicurio Registry, but the artifacts managed by Registry cannot be managed through the Kubernetes API.
@carlesarnal could you and the Apicurio Registry team come present to TAG App Delivery at our general meeting on December 20, 2023?
@carlesarnal could you and the Apicurio Registry team come present to TAG App Delivery at our general meeting on December 20, 2023?
Hi @angellk, yes! I have no problem presenting next week.
Thanks
- Are there ways to use Apcurio with the Kubernetes API?
No, we do have a Kubernetes operator to manage Apicurio Registry, but the artifacts managed by Registry cannot be managed through the Kubernetes API.
I was asking about the other way around: can I use Apicurio to manage the Kubernetes API?
Hello @carlesarnal! I am reaching out on behalf of TAG Runtime. It would be great to have you present Apicurio at our bi-weekly meeting to understand the project roadmap.
The next occurrence of the meeting is on 4th Jan 2024. Let me know if that works for you else we can find some other time!
Hello @rajaskakodkar,
Based on some internal conversations we've been having, I think we should postpone the Apicurio presentation until we can get clarification on some key questions.
I'll write here again once we're ready to present.
Thanks!
Hello all,
For now, we will defer contributing to the project, since we have some branding issues that have to be resolved before contributing it. That said, we might resume the activity in the future whenever we have a more mature version of some other parts of our projects. In any case, for now, we have engaged with the Discovery API working group to get engaged with https://github.com/xregistry initiative, which might create a more organic opportunity for the contribution.
Thanks everyone for your time. For now, I'll close this issue.
- Are there ways to use Apcurio with the Kubernetes API?
No, we do have a Kubernetes operator to manage Apicurio Registry, but the artifacts managed by Registry cannot be managed through the Kubernetes API.
I was asking about the other way around: can I use Apicurio to manage the Kubernetes API?
We have a Kubernetes Operator to manage the application deployment, but nothing beyond that.
Application contact emails
apicurio-registry@redhat.com
Project Summary
Apicurio Registry is a runtime server system that stores a specific set of artifacts (primarily schemas and API designs) as files and manages evolution of artifact versions. Apicurio Registry enables you to add, update, and remove the artifacts from the store using a REST API or a Web UI.
Project Description
API Registry
The key use case for the Apicurio community is as an API registry, which is a system that enables you to register your designs (OpenAPI, AsyncAPI, GraphQL, Apache Avro, Google Protocol Buffers, JSON Schema, Kafka Connect schema, WSDL and XML Schema (XSD)) so that potential API consumers can do the following:
Schema Registry
In the messaging and event streaming world, data published to topics and queues often must be serialized or validated using a schema (OpenAPI, AsyncAPI, GraphQL, Apache Avro, Google Protocol Buffers, JSON Schema, Kafka Connect schema, WSDL and XML Schema (XSD)). Schemas can be packaged in each application, but it is often a better architectural pattern to register schemas in an external system and then reference them from each application. A schema registry provides the following benefits:
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/Apicurio/apicurio-registry
Additional repos in scope of the application
No response
Website URL
https://www.apicur.io/registry
Roadmap
https://github.com/orgs/Apicurio/projects/6
Roadmap context
Over time, all applications face organic growth. We’re no different in that sense, and we’re planning a new major release for the project. For example, the project supports different storage options, like storing the application data in a Kafka topic or storing the information in a relational database. Due to some technical constraints, in the past, we had to release a new container image per each storage option (even for separate database drivers) but these constraints have been removed and, with the new major version, we will be releasing just one container image for all the storage options.
In addition to addressing some technical limitations we also started adding some new major features, like a GitOps implementation that can be used to store the application data.
We have also introduced a new client library for the application that relies on Kiota, an exciting technology developed by Microsoft as an open source tool that allows us to generate client SDKs from OpenAPI definitions.
Contributing Guide
https://github.com/Apicurio/apicurio-registry/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/Apicurio/apicurio-registry/blob/main/CODE_OF_CONDUCT.md
Adopters
N/A
Contributing or Sponsoring Org
https://www.redhat.com
Maintainers file
https://github.com/Apicurio/apicurio-registry/blob/main/pom.xml#L38-L70
IP Policy
Trademark and accounts
Why CNCF?
Community and Ecosystem Support. Neutral Governance. Increased Visibility. Interoperability and Standards. Marketing and Recognition. Graduation Path. Legal and Intellectual Property Support.
Benefit to the Landscape
This question can be resolved by mentioning the multiple reasons why a project like Apicurio Registry is a good “Cloud Native” fit, like the ones described below. Another big benefit to the landscape is the close integration with an existing project like Strimzi.
Cloud Native 'Fit'
A schema registry like Apicurio Registry is considered a good fit for cloud-native architectures for several reasons:
In summary, a schema registry like Apicurio Registry is well-suited for cloud-native architectures because it addresses the challenges associated with the dynamic, decentralized, and scalable nature of microservices-based applications, providing a robust foundation for data interoperability and evolution.
Cloud Native 'Integration'
Apicurio Registry has a “native” clear integration with Strimzi in various ways.
Cloud Native Overlap
This project does not have an overlap with any other CNCF project.
Similar projects
https://github.com/confluentinc/schema-registry
Landscape
https://landscape.cncf.io/?selected=apicurio-registry
Business Product or Service to Project separation
Even though there is a Red Hat product based on Apicurio Registry, we acknowledge the importance of maintaining independence and transparency. Our approach involves emphasizing the clear distinction between the upstream project and downstream products or services.
The project itself, referred to as the upstream, is maintained as an open-source endeavor with a distinct identity. We commit to keeping it separate from any specific Red Hat product or service, ensuring its autonomy. Any downstream products or services developed by Red Hat based on the project will have their own organizational structure and development processes. We recognize the significance of avoiding a direct overlap between the project and any commercial offerings.
While Red Hat is currently a significant contributor and maintainer, we recognize the importance of ensuring the project's independence.
We actively encourage and welcome contributions from external contributors. We understand the need for diverse perspectives and are committed to fostering an open environment where regular contributors can become maintainers, ensuring a broader range of opinions and contributions.
Project presentations
No
Project champions
No response
Additional information
No response