What is the purpose of keeping separate branches for sokol and core?

[lexsys27]

As I can see the difference is in the group variables files and a single template file.

One may create two example files for different network types. Then parameterize template so it will be the same for both networks and put the configuration to the variables file. That way only one branch is needed which is easier to maintain and integrate with terraform provisioning.

Is there any reason for maintaining two additional branches that I am not aware of?

[igorbarinov]

We have them in two branches because of very different purposes and security implications of two networks.
Core - production network, changes are rare and should be considered with care.
Sokol - test network, changes in some files, e.g. list of bootnodes, are frequent, should be approved before merging

I'd prefer to keep files in two separate branches

[lexsys27]

Sorry, I have a little background in this domain and the reasoning is still unclear for me.

Does my guess that changes are limited to the configuration only hold true?

Can you describe the workflow around these two branches? Are they deployment branches so deployment to core environment goes from the first one and to sokol from the second one?

Is it some kind of mechanism distributing configuration about the state of the network among users?

[igorbarinov]

It's about change management, not technical requirements.

Each PR to Core branch should be discussed and approved by a wider set of change managers

[lexsys27]

Got it. So there are two separate areas in this issue - technical and change management.

Possible technical solution:

1. group_vars/sokol is managed in the sokol branch
2. group_vars/core is managed in the core branch
3. master has no network-related configuration

Change management process stays the same.

[igorbarinov]

@phahulin thoughts?

[phahulin]

@lexsys27
I have few questions:

1. just to clarify - what do you mean by "group_vars/sokol is managed in the sokol branch" - so sokol contains only group_vars/sokol but not group_vars/core, core - the other way round, and master contains neither?

2. a typical case of our workflow is the one you see now: on sokol we have upgraded parity to 1.9, while core still runs on 1.8. Upgrade to 1.9 required some changes in config files (template file you mentioned). How can this case be taken care of if we unite all branches? will we need to introduce new variables each time something changes? write ifs in templates? What I think is a good thing about having separate branches is that you can implement new features in master/sokol and be sure that core is left intact

[lexsys27]

1. correct
2. I would implement the changes in master and merge/rebase them to sokol. Update sokol variables. master is untouched. When ready merge changes from master to core and update core variables.

This way you have consistent flow of changes from master to sokol and core. You still control the time when changes are applied and can do all review process. Also you keep variables local to branch.

This mental model is easier to understand - for me, at least :) And it is pretty flexible. For example, if I want to run validator for core and validator + explore for sokol I just grab configs from both branches and put two nodes into the sokol group and one node into the core group. Now I need to clone the repo two times and manage deployments from two different directories.

[phahulin]

I don't see the difference with the current model then...

Let's take an example:
so, initially somewhere in config.j2 we have

opt = "val"

Now parity is upgraded to 1.10 and opt needs to be changed from val to newval.

What we do now:

1. on master - change it (no changes in sokol, core)

- opt = "val"
+ opt = "newval"

2. merge to sokol (no changes in core)
3. observe sokol for some time to see if it's ok
4. merge to core

What will the workflow look like in the new scenario?

[ArseniiPetrovich]

According to the above and referenced discussions, we have decided to leave the current scheme with separation of branches.