Setting up a production demo server for OFN newbies and prospective local instance owners to use

Hello everyone :slight_smile:

As more and more interest is being gathered for the OFN platform we’re finding that there are more requests for a demo version that can be presented or played with.

At the moment the only option to do this is to use staging servers in Australia, or in the UK. This doesn’t really meet the defined need though, because:

  • These new users are playing with versions that include new features or functionality and all the bugs and broken bits that come with that.

  • The dev teams using the staging server are on these occasions unable to use the staging server for testing the things they’re working on.

After talking about this with the AU team, we thought there was a need for the global community to have a demo production version of the platform available for anyone to use, and this would be paid for out of the core commons funding.

If we set it up similarly to an AU staging server then it would be a cost to run of about $20-40AUD per month depending on the specs. We’d set it up so that any new release would be deployed automatically.

@maikel are you able to provide a quick estimate on how many hours you would need to set up the instance on the new server and set up the automatic release deployment (ie. pinging GitHub as we discussed today)?

@lin_d_hop I also wonder whether setting this up with the UK would be an option, rather than in AU? Not sure what the pros and cons are either way, AU or UK teams setting up and owning it. But I thought it would be worth throwing it out there for others if they’d like to own the demo version. :slight_smile:

@Kirsten @MyriamBoure is this something that could be funded out of the core commons bucket?

1 Like

@pmackay Probably has the best idea of how long it takes to get a server up and running. He has been working on that lately. Here are some conservative guesses:

  • 1h hiring a new server and registering, setting up the domain

  • 1h preparing the ofn-install configuration

  • 1h running ofn-install and dealing with little issues

  • 1h fixing an unknown bug in ofn-install

  • 3h implementing / configuring a minimal webserver to listen to Github release events (e.g.

  • 1h fetch new version from Github and execute post-receive hook from shell

  • 1h add Github webhook and basic testing


Couldnt this be done with Buildkite somehow? So as to use existing toolchain?

Couldnt this be done with Buildkite somehow? So as to use existing toolchain?

Yes, possible. Buildkite supports building tags. We would just need to make sure that it’s a newer release tag. The downside is that the demo server will depend on our CI server and Buildkite. Two otherwise not needed servers. Still a good idea for a low-priority server.

I’d like to make sure I understand this proposal (which seems like a great idea to me). So if we had this global staging server (like a global sandpit for playing in - right?) how would people interested get there. So I mean - would we change the platform on the Canadian instance so that people only go there once they have decided to use OFN and start trading? So - how would we make sure that users get to the right platform for playing, and then to the right platform for using? (apologies if this is obvious to everyone else).

Theresa, this proposal is in response to the many requests we’re receiving for somewhere where potential new instances or platform development contributors (e.g. Spain and La Poste and Germany) for somewhere to play with the software as a user. Thus it’s more for new potential uses, rather than trialling for existing local instance users. So you wouldn’t provide a link to your potential new enterprises to use this, you would direct them to the Canadian instance.

However, you raise an interesting point on the concept of trial accounts on production versions.

Would this get paid for out of the global commons pot? If so, and Aus manages that pot, should you guys own it? On the flip side, it could be a server that others have access to as well.

What locale might be best to use?

Would this logically live at

Hum… I guess that could be useful, if we can afford it… or else we should just agree which staging servers we could use, like I’m super happy to invite anyone to the French staging as we just use it to test new versions, we never empty the database, but… it’s in French :wink: I don’t know about UK, how is the UK staging work? Could it be used for those kind of tests?

Trial accounts on production servers are unavoidable, it’s a trade off to accept: either your new user test in another instance (staging, demo, whatever) but then he has to fill in again all his data in the production server if he decides to move forward. Either you accept he tests directly on production so that he can build up his project while testing and only has to launch when ready. I personally think the second option is more user friendly…

For me the demo server really is only used for the people who want to create an instance, so new country or company willing to make a white label deployment. So if we had an English Speaking staging server whose database is not emptied, we could use this for those type of test without having to deploy more energy and money. IMHO… but of course if we don’t have that then maybe we need a demo instance… I guess the locals are not so important for those tests also…

The only problem with this @MyriamBoure is that the software version on staging is normally not production-equivalent, which means that they will encounter new things not yet live and possibly/probably buggy. By having a standalone demo instance that is the latest release and nothing half done then it’s a true reflection of what is currently available feature-wise.

I wonder also, whether it would be useful in other ways as well…thoughts?

We believe it should be paid for out of the global commons pot, yes. But as far as I’m aware this pot of funds isn’t solely managed by the Australian team, correct @MyriamBoure and @Kirsten?

Also, we’re open to the locale being anywhere, and I think that domain sounds like a good idea.

I would keep this demo / sandbox instance separated from staging environments since staging is needed to test and develop new stuff. And their DB should be erased and seeded from scratch every time you test something different.

I see it as something useful for people that want to try OFN before opening a new instance, not the users directly.

But… we need to:

  • keep the sandbox in sync with production (provisioning, code and DB migrations)
  • agree on which locale / TZ should be
  • never erase the DB
  • share the cost of the mainainance between all the members

There is another option, maybe. We already have the provisioning process almost automated, we could move it forward and add an easy way to create ad hoc demo instances deployed in some small cloud environment.

In that way if a new possible instance want to try it out they just need to create an account in that cloud environment and hand it over to us in some way so we can provision and deploy a small instance there. Or maybe we can find an even easier way but this depend on how often people will ask this. This has other PRO and CON of course… but mainly they pay for cloud costs (3$ maybe…)

We have the provisioning process almost automated

@enricostn That sound exciting! Are you talking about the LXC you proposed?

Simplifying the process of setting up an instance seems more decentralized than having a global try-out-playground. Furthermore the australian servers are really slow to use from germany which does not contribute to the excitement of testers. Setting up a local instance also has the benefit that you can simply keep all customizations and data once you decide to use it for real.

The provisioning process is (kind of almost) automated with ansible thanks to @pmackay. The “only thing” that is missing is to somehow make the results of an ansible run reusable. In theory it could be as simple as renting a 3$/month vps (or using one of a friend) and executing a single command like: docker/lxc run ofn:latest

IMHO the ease of deployment is one of the reasons why e.g. wordpress is so successful – just 2cts

ping @maikel @elf-pavlik @almereyda @NorthernColorado Is this possible?

Nope. I refer to the current Ansible playbooks. LXC is something that we propose only for development environments, not production. IMHO the current deployment process on a VPS for production and staging is easy enough, although could be even better of course. The only thing I really miss is consistent seed data (taxonomies, etc) but we’re working on that too.