Hello! I’d like to request for the listing of the Airbyte k8s operator charm. This is one of two Airbyte charms being requested for listing but I will submit two separate requests. (Update: the other request can be found here)
Airbyte is an open-source data integration platform designed to centralize and streamline the process of extracting and loading data from various sources into data warehouses, lakes, or other destinations.
This operator provides the Airbyte server, and consists of Python scripts which wraps the versions distributed by airbyte.
Thanks @ali-kelkawi for the review request! @mbeierl can you please help with this review? You can go through and tick off the items on the checklist and post the result in this thread. This prior listing request could serve as an example of how to go about it. Please ping @review-coordinators for any questions.
@ali-kelkawi have the items above (especially the typo’d link) been resolved? I took a quick look just now and it seems fine, so either it’s fixed or I’m looking in the wrong place.
If you can confirm that the issues @dimaqq has in the checklist above are resolved, we should be good for listing, I believe.
Thanks again for the thorough review. I’ve submitted this request to have the charm ownership be transferred to our team. Could you please let me know what link you are referring to in CONTRIBUTING.md you are referring to? The CONTRIBUTING.md file is generally specific to Github and does not make its way to the charm docs, so it should be fine for any links on there to be local to Github.
It appears that Canonical is moving to a practice where charms authored by Canonical should only use artefacts (here container images) that are also built by Canonical.
Current charm PR uses external (airbyte) container images.
cc @jameinel who may be able to provide details about charm maturity level where this practice becomes a hard requirement and/or how to apply for an exemption.