Reduce number of PRs needed to update charts

[ostromart]

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]

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

[richardwxn]

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

[incfly]

Let's merge installer and operator first.

…

On Fri, Nov 22, 2019, 4:54 PM Xinnan Wen ***@***.***> 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 <#19146?email_source=notifications&email_token=AAMVXB6ELXYSFT5MLBDTGK3QVB5LHA5CNFSM4JQXSBAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7IWDI#issuecomment-557746957>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMVXB3Q6E2QTKYI6UGXFJLQVB5LHANCNFSM4JQXSBAA> .

[howardjohn]

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]

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]

@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

[howardjohn]

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

[jmazzitelli]

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

• [kiali] use kiali operator to install and manage kiali installer#556
• [kiali] use kiali operator to install and manage kiali operator#622

[sdake]

@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]

@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]

@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 :-)