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

matrix-synapse: create and connect to local postgresql db #31223

Merged
merged 4 commits into from Feb 5, 2018

Conversation

corngood
Copy link
Contributor

@corngood corngood commented Nov 4, 2017

Motivation for this change

A better default configuration for matrix-synapse when database_type = "psycopg2". Postgresql will be enabled, the role/database will be created, and matrix-synapse will connect using the unix socket.

TODO:

  • default to postgres based on stateVersion?
  • tests
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@corngood
Copy link
Contributor Author

corngood commented Nov 4, 2017

@Ralith This is still a bit messy, but I'd appreciate your thoughts.

Copy link
Contributor

@Ralith Ralith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is that the user still has to manually enable postgres, but no longer has to manually configure the database by hand on a new HS, right? That's definitely appealing. Has this been tested live?

logConfigFile = pkgs.writeText "log_config.yaml" cfg.logConfig;
mkResource = r: ''{names: ${builtins.toJSON r.names}, compress: ${boolToString r.compress}}'';
mkListener = l: ''{port: ${toString l.port}, bind_address: "${l.bind_address}", type: ${l.type}, tls: ${boolToString l.tls}, x_forwarded: ${boolToString l.x_forwarded}, resources: [${concatStringsSep "," (map mkResource l.resources)}]}'';
# TODO: finish this and put it in lib somewhere
toYaml = value:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't yaml a superset of JSON? That's how we're getting away with toJSON elsewhere.

createHome = true;
shell = "${pkgs.bash}/bin/bash";
uid = config.ids.uids.matrix-synapse;
uid = config.ids.uids."${user}";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't config.ids.uids a static table? I don't think this is useful, and it brings into question the whole dynamic user name option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I suppose it is. I didn't actually expose the user name, I was just trying to avoid duplication. i'll put it back the way it was.

{ name = "matrix-synapse";
gid = config.ids.gids.matrix-synapse;
{ name = group;
gid = config.ids.gids."${group}";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment on uid.

--lc-collate=C \
--lc-ctype=C \
--template=template0 \
${cfg.database_name}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these db setup commands guaranteed to be idempotent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They will fail if you remove db-created without dropping the db/role. It's not a very elegant solution, but it's what's used in other similar modules.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er, right, not sure how I managed to forget the guard file even though it's right there.

@corngood
Copy link
Contributor Author

corngood commented Nov 4, 2017

Yeah, that's the idea. Postgres doesn't need to be enabled, but you do need to switch database_type. Perhaps postgres is a better default, but then we're getting into seriously breaking changes. Maybe base it on system.stateVersion?

@corngood
Copy link
Contributor Author

corngood commented Nov 4, 2017

And yeah, I'm using it on my home server. I switched my VPS to this config, shut down matrix-synapse, ran synapse_port_db, and it seems to be working properly.

The database setup is based on how other PG dependants (gitlab, mattermost) do it.

user = cfg.database_user;
database = cfg.database_name;
};
}."${cfg.database_type}";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong to me, but it's useful and seems to work. Is there a better way?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It didn't even occur to me you could do this. I'm no Nix language expert, so no strong feelings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, an alternative is to have two different options for two databases, I guess. Maybe defining with mkIf, so that you cannot set the wrong one.

I am not sure that would be better.

@Ralith
Copy link
Contributor

Ralith commented Nov 4, 2017

Defaulting based on stateVersion sounds nice to me. IMO sqlite-by-default is user-hostile even in environments that can't magic up a postgres instance without any extra effort.

Copy link
Contributor

@Ralith Ralith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm generally in favor of this, and I don't see any obvious issues in the approach. It doesn't strike me as noticeably messier than what's already there, either; as far as I'm concerned, trusting that it works, it's okay to merge as soon as you're happy with it.

@corngood
Copy link
Contributor Author

corngood commented Nov 4, 2017

I'm thinking it's ok to use stateVersion >= 18.03 at this point. I see other breaking changes like this that were made after .version was updated, but before release.

@corngood corngood changed the title WIP: matrix-synapse: create and connect to local postgresql db matrix-synapse: create and connect to local postgresql db Nov 4, 2017
@corngood
Copy link
Contributor Author

corngood commented Nov 4, 2017

I made the stateVersion change, and added it to the release notes. I also wrote a test that ensures it can start up with either db using a trivial config.

server_postgres = server;

server_sqlite = args: server args // {
system.stateVersion = "17.09";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better for this to just explicitly turn on sqlite? Who knows what other side effects this specific stateVersion might come to have over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess I originally intended to verify that it was using the correct db for each stateVersion, but I didn't actually test for it. I suppose the stateVersion logic is pretty simple, and it would be more intuitive to explicitly test the backends.

@corngood
Copy link
Contributor Author

@fpletz I noticed you approved the changes this conflicts with, so would you mind taking a look at this before I rebase?

@Mic92
Copy link
Member

Mic92 commented Nov 25, 2017

@GrahamcOfBorg test matrix-synapse

Copy link

@GrahamcOfBorg GrahamcOfBorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failure for system: x86_64-linux

Merge failed

@Mic92
Copy link
Member

Mic92 commented Nov 25, 2017

@corngood can you rebase?

@corngood
Copy link
Contributor Author

Yeah, just did. Testing locally now.

I wonder if I can do this:

@GrahamcOfBorg test matrix-synapse

@corngood
Copy link
Contributor Author

@fpletz You merged the last matrix-synapse change, so would you mind taking a look? Thanks

@corngood
Copy link
Contributor Author

corngood commented Jan 7, 2018

Resolved conflicts. Can anyone suggest changes or push this along?

@Mic92
Copy link
Member

Mic92 commented Jan 12, 2018

@GrahamcOfBorg test matrix-synapse

Copy link

@GrahamcOfBorg GrahamcOfBorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failure for system: x86_64-linux

Merge failed

@Mic92
Copy link
Member

Mic92 commented Jan 12, 2018

@GrahamcOfBorg test matrix-synapse

Copy link

@GrahamcOfBorg GrahamcOfBorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failure for system: x86_64-linux

                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  5 61.1M    5 3175k    0     0  3175k      0  0:00:19  0:00:01  0:00:18 1625k
 42 9015k   42 3813k    0     0  3813k      0  0:00:02  0:00:01  0:00:01 2050k
 17 6058k   17 1086k    0     0  1086k      0  0:00:05  0:00:01  0:00:04 1065k
  9  916k    9 86669    0     0  86669      0  0:00:10 --:--:--  0:00:10  133k
 45 37.5M   45 16.9M    0     0  8699k      0  0:00:04  0:00:02  0:00:02 6368k
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 35 6058k   35 2146k    0     0  1073k      0  0:00:05  0:00:02  0:00:03 1063k
  7 61.1M    7 4519k    0     0  2259k      0  0:00:27  0:00:02  0:00:25 1529k
 61 9015k   61 5541k    0     0  2770k      0  0:00:03  0:00:02  0:00:01 1936k
 76  916k   76  703k    0     0   703k      0  0:00:01  0:00:01 --:--:--  439k
 65  916k   65  600k    0     0   600k      0  0:00:01  0:00:01 --:--:--  420k
 68 37.5M   68 25.9M    0     0  8850k      0  0:00:04  0:00:03  0:00:01 6998k
100  916k  100  916k    0     0   916k      0  0:00:01  0:00:01 --:--:--  479k

building path(s) ‘/nix/store/xv9xbqmlzxb0b3aai73m13iy0v36r8yg-append-initrd-secrets’
killing process 4537
killing process 4533
killing process 4565
killing process 4588
killing process 4481
error: a ‘aarch64-linux’ is required to build ‘/nix/store/k6q6y9vqnhvzz1ypvw9zb8pnkza2zp7g-append-initrd-secrets.drv’, but I am a ‘x86_64-linux’

@corngood
Copy link
Contributor Author

corngood commented Jan 12, 2018

@Mic92 Any idea about this test failure?

I'll rebase and run tests locally when I have a chance.

Edit: looks like GOB has been posting similar failures on a variety of PRs recently.

@corngood
Copy link
Contributor Author

Ok, I rebased on master, and tests passed locally.

@Mic92
Copy link
Member

Mic92 commented Jan 13, 2018

@corngood this is a bug in the bot. It tries to build the aarch64 build on x86_64.

@corngood
Copy link
Contributor Author

corngood commented Feb 5, 2018

Rebased again... can someone give me some feedback? This will hopefully save people having to do migrations when they discover it's not using the recommended DB.

The documentation and state version will need to be changed if this doesn't make 18.03.

@Ralith
Copy link
Contributor

Ralith commented Feb 5, 2018

Probably wouldn't hurt to add a release note regarding the (stateVersion-guarded) breaking change to defaults. Hopefully someone will merge this before 18.03 releases.

@7c6f434c
Copy link
Member

7c6f434c commented Feb 5, 2018

@GrahamcOfBorg test matrix-synapse

Copy link
Member

@7c6f434c 7c6f434c left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine in general

user = cfg.database_user;
database = cfg.database_name;
};
}."${cfg.database_type}";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, an alternative is to have two different options for two databases, I guess. Maybe defining with mkIf, so that you cannot set the wrong one.

I am not sure that would be better.

@GrahamcOfBorg
Copy link

Success on aarch64-linux (full log)

Partial log (click to expand)

server_sqlite: exit status 0
server_postgres: running command: sync
server_postgres: exit status 0
test script finished in 96.08s
cleaning up
killing server_sqlite (pid 627)
killing server_postgres (pid 638)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/zz4ih0kcjpw8hs6yjv8js8is1a2xwp2l-vm-test-run-matrix-synapse

@7c6f434c 7c6f434c merged commit 176d94f into NixOS:master Feb 5, 2018
@GrahamcOfBorg
Copy link

Failure on x86_64-linux (full log)

Partial log (click to expand)

server_postgres: running command: systemctl --no-pager show "matrix-synapse.service"
server_postgres: exit status 0
server_postgres: running command: systemctl --no-pager show "matrix-synapse.service"
server_postgres: exit status 0
server_postgres: running command: systemctl --no-pager show "matrix-synapse.service"
server_postgres: exit status 0
server_postgres: running command: systemctl --no-pager show "matrix-synapse.service"
server_postgres: exit status 0
building of ‘/nix/store/gv2w80vfbi4ji7c36f6az8c4mzhqmmry-vm-test-run-matrix-synapse.drv’ timed out after 1800 seconds
error: build of ‘/nix/store/gv2w80vfbi4ji7c36f6az8c4mzhqmmry-vm-test-run-matrix-synapse.drv’ failed

@corngood
Copy link
Contributor Author

corngood commented Feb 5, 2018

FYI I just ran the tests locally and they passed on x86_64-linux.

@7c6f434c
Copy link
Member

7c6f434c commented Feb 5, 2018

Yes, I don't always trust borg timeouts, and I would be very surprised if you managed to write a matrix service that genuinely works better on aarch64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants