Description

joelanford

opened on Aug 20, 2024

Issue body actions

Goals:

1. Eliminate current and prevent future side effects of dependency imports when importing APIs. (for example: see https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#no-functions)
2. Put up barriers to breaking changes. Once we reach v1.0.0, we MUST avoid breaking changes.

Breaking changes include:

1. Anything that causes the go-apidiff job to fail. (see separate issues related to moving non-API Go code to an internal tree). The APIs will remain exported, so the go-apidiff job will ensure that our Go code defining the APIs is not breaking from a Go perspective.
2. Anything that would cause Kubernetes clients to experience a breaking change when interacting with instances of our CRD via the Kubernetes apiserver.

Activity

1. joelanford

   added

   epic

   v1.0Issues related to the initial stable release of OLMv1Issues related to the initial stable release of OLMv1

   on Aug 20, 2024
2. joelanford

   added this to OLM v1on Aug 20, 2024
3. joelanford commented on Sep 17, 2024

   

   joelanford

   on Sep 17, 2024

   MemberAuthor

   More actions

   To enshrine goal (1) in our codebase, we could implement a test that enforces a specific set of imports. Any future PR that wants to import a new import path would need to also modify our list of allowed import paths in our API.

   I would anticipate that that list would start out as k8s.io/apimachinery.

   Perhaps https://golangci-lint.run/usage/linters/#depguard would help.
4. LalatenduMohanty

   removed

   epic

   on Oct 1, 2024
5. LalatenduMohanty commented on Oct 1, 2024

   

   LalatenduMohanty

   on Oct 1, 2024

   Member

   More actions

   As discussed in the community meeting we are changing this to an issue (from an epic) and will make it part of #1253
6. LalatenduMohanty

   changed the title [-][epic] Establish home for v1.0.0 Go APIs[/-] [+]Establish home for v1.0.0 Go APIs[/+] on Oct 1, 2024
7. LalatenduMohanty

   removed

   v1.0Issues related to the initial stable release of OLMv1Issues related to the initial stable release of OLMv1

   on Oct 1, 2024
8. camilamacedo86 commented on Mar 4, 2025

   

   camilamacedo86

   on Mar 4, 2025

   Contributor

   More actions

   Hi @joelanford @LalatenduMohanty

   We have the crd-diff and the go-apidiff
   Also, we already combined all in a repo, so we still need this issue?
   Has anything else more than we need to do here?
9. acornett21 commented on Mar 4, 2025

   

   acornett21

   on Mar 4, 2025

   Contributor

   More actions

   I think dependent callers that need the API's will have trouble pulling in this mono-repo, IMO the API's should their own repo with as few deps as possible so they can be consumed easily and with low friction. That was another ask for this issue.
10. camilamacedo86 commented on Mar 4, 2025

    

    camilamacedo86

    on Mar 4, 2025

    Contributor

    More actions

    Hi @acornett21,

    Thank you for your input! Just to clarify, are you suggesting decoupling the APIs from this repository and placing them in a separate project specifically for APIs?

    If someone imports operator-framework/operator-controller, they will only get what is explicitly exposed—primarily the APIs. Any code that isn’t relevant to external users is kept within the internal/ directories. Given this, I don’t see a strong motivation to remove the APIs from this repo at this moment. I think we could closet this one ( if that is the go ) and wait until there’s a clear need to do so before making that decision

    However, I might be missing something. Let me know if I’ve misunderstood your point!.
11. acornett21 commented on Mar 4, 2025

    

    acornett21

    on Mar 4, 2025

    Contributor

    More actions

    Hi @camilamacedo86 Yes correct that is what I'm suggesting. And correct an importer does not have access to the /internal packages, but by forcing them to import the entire repo, this also forces them to import/take all of this projects dependencies, which is less then desirable and can cause conflicts for a consumer. If a caller needs k8's API's/CRD's they only use the API dependency which has minimal dependencies, same with OpenShift API.

    The ask here would be what is similarly in place for OLMv0 with API repo

    Reacted by Camila Macedo
12. LalatenduMohanty commented on Mar 17, 2025

    

    LalatenduMohanty

    on Mar 17, 2025

    Member

    More actions

    @acornett21 I was under an impression that mono repo would resolve this issue. But if it is not (as you mentioned in your comment) I would keep it separate from the monorepo epic.
13. acornett21 commented on Mar 17, 2025

    

    acornett21

    on Mar 17, 2025

    Contributor

    More actions

    @LalatenduMohanty This issue isn't about the monorepo at all, it's about the API's, so my take is that it's already separate.

    Reacted by Lalatendu Mohanty and Camila Macedo
14. github-actions commented on Aug 4, 2025

    

    github-actionsBot

    on Aug 4, 2025 – with GitHub Actions

    More actions

    Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.
15. github-actions

    added

    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.

    on Aug 4, 2025
16. github-actions commented on Sep 4, 2025

    

    github-actionsBot

    on Sep 4, 2025 – with GitHub Actions

    More actions

    This issue has been closed due to inactivity.
17. github-actions

    closed this as not plannedon Sep 4, 2025
18. acornett21 commented on Sep 4, 2025

    

    acornett21

    on Sep 4, 2025

    Contributor

    More actions

    @joelanford Should this be re-opened?
19. camilamacedo86

    reopened this on Nov 7, 2025
20. camilamacedo86

    added

    lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.Indicates that an issue or PR should not be auto-closed due to staleness.

    and removed

    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.Denotes an issue or PR has remained open with no activity and has become stale.

    on Nov 7, 2025
21. acornett21 commented on Nov 10, 2025

    

    acornett21

    on Nov 10, 2025

    Contributor

    More actions

    Has there been any thoughts/discussion on this? If there isn't either

    • a go mod in the /api directory
    • a new standalone repo

    It makes consumers that need/want to build automation around v1 installs very difficult, due to dependency challenges/limitations.
22. joelanford commented on Nov 17, 2025

    

    joelanford

    on Nov 17, 2025

    MemberAuthor

    More actions

    Can you provide specific examples of the problem with the current structure of the API Go library? I know we've talked about potential problems at a high level, but it would be good to have something measurable to know if we are actually fixing or improving something.
23. acornett21 commented on Nov 17, 2025

    

    acornett21

    on Nov 17, 2025

    Contributor

    More actions

    The issue with the current structure is that any application that wants to pull in just the /api package, can't. A dependent app can only pull in the entire repo, meaning that the dependent app is beholding to operator-controller and all of it's dependencies. This means

    • Larger dependency footprint (unnecessarily).
    • Dependency Conflicts.
    • Potential for more CVE's.

    The only package that I see the /api package dependent on is apimachinery, having to take helm and operator-registry and other large dependencies just doesn't make sense.

Issue actions