Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal technical Documentation created/updated (Create ADR) #324

Open
jakobmoellerdev opened this issue Nov 11, 2024 · 5 comments
Open
Assignees
Labels
area/ipcei Important Project of Common European Interest

Comments

@jakobmoellerdev
Copy link
Contributor

No description provided.

@github-actions github-actions bot added the area/ipcei Important Project of Common European Interest label Nov 11, 2024
@jakobmoellerdev jakobmoellerdev changed the title Internal technical Documentation created/updated Internal technical Documentation created/updated (Create ADR) Nov 11, 2024
@jakobmoellerdev jakobmoellerdev moved this from 🆕 ToDo to 🏗 In Progress in OCM Backlog Board Nov 11, 2024
@frewilhelm
Copy link

Further questions:

  • Will replication always only work on the latest or on all in spec (SemVer of Component status)?
  • Should a successful replication automatically result in creation of a component and resource CRs?
  • How many replication attempts do you want to keep in replication CR status?

@ikhandamirov
Copy link

ikhandamirov commented Nov 11, 2024

More to follow up on:

  • Extend config type transport.ocm.config.ocm.software to support more options of ocm transfer componentversions?
  • Is it Ok that when replication is triggered the component is re-downloaded from the source registry?
  • Does the replication have to re-run, if transfer options change, but not the component version? If so, the controller needs to be able to detect that change.
  • Does an SRE need to be able to see in the status, which transfer option an individual run was executed with? If so, the transfer options likely need to have a dedicated field in the Spec and in the Status.
  • How to supply --lookup to the controller: via ocmconfig? Or should the Replication CR refer to several source OCMRepositories (in addition to source Component)?
  • Should a Replication support several target OCMRepositories? Alternatively, if a component needs to be replicated to several targets, several respective Replication CRs would need to be created, which likely would be simpler from ops perspective.

@dee0
Copy link

dee0 commented Nov 13, 2024

Hello @frewilhelm

I have a question about the above diagram. In SAC we are hoping to move to OCM-Controller+Flux for deployment and we are anticipating that the deployment controllers would only be on MCP.

However the diagram above appears to show things not working as we hoped. Or perhaps it it not related to our case?

@frewilhelm
Copy link

Hi @dee0, the diagram only shows one possible setup. The setup you are describing is another use-case that will work as well using the kubeconfig fields in Flux to remotely deploy into the runtime clusters.

@jakobmoellerdev
Copy link
Contributor Author

We now move to the review phase as most ADRs are initially created and in phase of constant feedback. We plan to slowly move ahead with the merge after incorporating feedback.

@jakobmoellerdev jakobmoellerdev moved this from 🏗 In Progress to 🔍 Review in OCM Backlog Board Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ipcei Important Project of Common European Interest
Projects
Status: 🔍 Review
Development

No branches or pull requests

4 participants