Local setup for testing federation

Support Developer Support
1

I’m a new developer here. I just went through the setup guide and things are going well. I followed the development setup instructions and I have an active server now running. The guide was mostly straight forward but it leaves off at this “so now I have a server” place. Before I start developing I want to play around with this but I don’t know what best practices are for some very important things. Specifically:

I have this node running on localhost on a VM on an isolated machine. Is it okay to create accounts on it where their names are going to look like @127.0.0.1 ?

More importantly is it okay to interact with production pods? If not which pods am I supposed to be interacting with for development and testing purposes?

I may have some more follow up questions as I explore more development resources, but at this point I’m going to hold off on interacting with the rest of the ecosystem until I know what the rules of the road are.

Thanks!

2

You can create accounts for development using whatever hostname you want to, as long as it resolves to your local machine. I, for example, have set up my local DNS to resolv any hostname with the .local TLD to resolv to localhost, which means I can run pods at poda.local and podb.local for local federation testing, for example.

While you technically could interact with actual pods, it doesn’t make much sense. If you’d deliver a post, we’d try to fetch the profile, and well, fetching from 127.0.0.1 does not end well for production pods. So you’d end up nowhere. Even if delivery would work, it still would be a one-way-only connection, as you’d never get something back.

If you want to do local federation testing, it’s best to either start two diaspora instances on different pods, or to start two instances of your VM and have them talk to each other. In the first case, make sure that the url key in the diaspora.yml includes the port as well, so that the diaspora handle (the username@host thing) includes the pod as well. In the second case, you’d need some kind of internal network for the two VMs, so that they are connected to each other, and then set the url to the IP that is reachable from the other VM.

Note that changing the url in the config requires you to drop the db and create it again ( bin/rake db:drop db:create db:migrate), because the hostname parts of diaspora handles are hardcoded in the database.

That all being said, having multiple diaspora nodes talking to each other is usually not required for diaspora* development, unless you actually want to work on something related to the federation layer. So a single local pod using 127.0.0.1 as hostname should be totally fine for most development tasks, without the need of communicating with other pods.

Since this is an important question, I changed the title to have this post related to a local federation testing setup, to make searching easier for future developers. If you have other questions, feel free to simply open a new thread. :slight_smile:

3 Likes
3

Just one more thing about federation-development: When you want multiple dev pods federate with each others, you would need to change some default settings in the diaspora.yml, because default-development settings would end in deadlocks otherwise. You need to either start more than one unicorn process or disable single process mode and start a sidekiq for background processing (note: the defaults in the diaspora.yml are the defaults for production, where federation obviously isn’t a problem, but development has other defaults).

1 Like
4

Thank’s for the prompt replies. Yes, I’d like to test things with data from other pods but I was worried about, for lack of a better expression, “contaminating” other pods. If someone creates a public pod running code from the head of development branch is that equally okay?

With respect to federation testing, do you have to create orthogonal users and databases so that you don’t have the two servers manipulating the same data at the same time?

Those are follow on questions which are a bit off topic though. I’m unblocked on moving forward with running for test purposes etc. Thanks again for the informative and fast reply!

5

If you want to test federation related source then yes, it’s better to host two instances yourself and passing messages in between them. You most likely only get any valuable and reliable test results when there is a bidirectional communication happening.

We have a lot of production pods running the development source! That’s a good way to catch regressions early. :wink: We usually design federation changes to be compatible with the last few stable versions, so there shouldn’t be any issues.

Oh, yeah, totally. Not only for concurrency issues, but as I mentioned earlier, stuff like full diaspora handles including the hostname part is hardcoded into the database. You’d end up in a giant mess when two pods who exchange data with each other write into the same database.

6

How to use automated test suite for federation of diaspora* pods?
(https://github.com/cmrd-senya/diaspora_federation_behavior)
As linked to in the wiki?
(https://wiki.diasporafoundation.org/The_Teamboard#Federation_behavior_testing)