search

istio / istio

Connect, secure, control, and observe services.
https://istio.io
Apache License 2.0
36.16k stars 7.79k forks source link

Reduce number of PRs needed to update charts #19146

Closed ostromart closed 4 years ago

ostromart commented 5 years ago

Right now it's six per change after a branch is cut. Simplest solution would be to merge installer and operator repos. Another alternative is to automate periodically updating the sha to last know good builds. The latter will be non-trivial because changes in charts often require manual changes to profiles and tests in operator.

howardjohn commented 5 years ago

I think the best end state is to merge the repos, and automate operator -> istio dep update.

richardwxn commented 5 years ago

@howardjohn when are we going to merge the repos? do we have any plan yet?

incfly commented 5 years ago

Let's merge installer and operator first.

On Fri, Nov 22, 2019, 4:54 PM Xinnan Wen notifications@github.com wrote:

@howardjohn https://github.com/howardjohn when are we going to merge the repos? do we have any plan yet?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/istio/istio/issues/19146?email_source=notifications&email_token=AAMVXB6ELXYSFT5MLBDTGK3QVB5LHA5CNFSM4JQXSBAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7IWDI#issuecomment-557746957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMVXB3Q6E2QTKYI6UGXFJLQVB5LHANCNFSM4JQXSBAA .

howardjohn commented 5 years ago

I don't think there is any current plans, we just need to move everything over. I think @costinm is against this so we may want to discuss at an env wg meeting and get consensus

sdake commented 5 years ago

Merging repositories is not particularly easy - although I am happy to do the work if we can come up with a proper directory structure that works for people.

We need to preserve history...

@costinm I am not sure what the concern is. At present, the developers have a lot of work to do to even get to the point of being able to test a PR - the syncing process is error-prone and unnecessary. We trade some isolation of concerns off for the ability to work properly on the repository. I don't understand the motive to have separate repositories for each component - it really just makes development far more difficult and raises the bar to new contributors - where we want to be lowering the bar.

Quick 1 AUD in the postal service to someone that is not a maintainer that can tell me how a change from installer makes it into istio/istio...

Cheers -steve

howardjohn commented 5 years ago

@sdake my understanding of what would need to be done:

Would be great for someone to tell me what is missing

edit: I have another idea, will send an RFC later

howardjohn commented 5 years ago

Please take a look at https://docs.google.com/document/d/16t19vnwG2Rf6U_c6LxCdT3fXFfhjQYg7GAKeCykHOTY @sdake @ostromart

jmazzitelli commented 5 years ago

I'm watching this PR - when complete, it would help me immensely to getting the kiali operator in. :+1:

sdake commented 5 years ago

@howardjohn a proposal for monorepo: https://docs.google.com/document/d/1sA7icak2OPwTrl-nXfNr2I1_QcJQfoEMPkpdTOOlEZ0/edit#

This leaves out the transition process. WIll wait on TOC approval or rejection before authoring a design document. I welcome co-authors (if you want to contribute to the design of the monorepo transition @howardjohn)

Cheers -steve

sdake commented 5 years ago

@sdake my understanding of what would need to be done:

  • Copy all the charts over with some git command that preserves the history
  • Rewire all the stuff in operator that calls the istio/installer repo. Mostly this stuff can be delete I think, since it was mostly about syncing
  • Now we have 2 copies of things -- what the operator "imported" before, and the actual installer. We should reconcile these so there is one copy
  • Add back some/all of the installer tests so we keep our coverage

Would be great for someone to tell me what is missing

edit: I have another idea, will send an RFC later

I've done a repo merge a few times. The process involves a lot of git format-patch and git am with sed intermixed:)

See: https://github.com/sdake/vertical for an implementation of repo merging that was functional the last time we had this multiple repository issue :)

sdake commented 5 years ago

@istio/technical-oversight-committee Hi gang. We will need a decision on a monorepo. I have scheduled this for the next TOC call (december 6th). The existing cost of a multiple repos does not generate any defendable benefit.

Strangely it has been about two years since the last multirepo to monorepo merge if this is approved :-)