Isolate playground.xwiki.org in its own VM

Infrastructure
,
#1

Hi everyone,

I would like to propose to stop having playground.xwiki.org as a subwiki of the xwiki.org instance and instead move it to its own VM.

We are still discussing the detail of the technical solution, but what is important is that it means the following changes:

Pro:

  • the pages in the playground wiki won’t appear in the global search
  • one less complex thing to take care of during xwiki.org upgrades
  • much easier to reset playground every day
  • much easier to have a much more up to date XWiki version on playground
  • it will be possible to allow playground users to do more things (like write scripts) since it will be isolated
  • the playground instance won’t impact the rest of xwiki.org in terms of performances

Cons:

  • you won’t be able to use your xwiki.org account to edit playground pages (but I don’t see how this would be an important feature)

Here is my +1.

2 Likes
#2

Not really a cons but it will also have some other impacts:

  • the search will be limited to playground.xwiki.org (so not result from other xwiki.org resources)
  • notifications will be only related to playground as the profile will be entirely separated

Also from an organisation point of view, it also means we might rely a bit more on XWiki SAS infra team for playground and on their tooling to reset it, update it etc. We (xwiki.org committers) used to have a bit more a direct hand on it by ssh-ing to the machines related to xwiki.org and performing maintenance stuff.

Still +1 for doing this as it will mean a more protected playground and more up to date.

#3

The technical solution is off topic IMO. The current technical solution we are discussing with XWiki SAS infra means less work for us, but we can always decide to take care it ourself in a dedicated VM, and it would still not change anything to this proposal.

#4

+1 thanks

#5

+1 Thanks

#6

If we want to keep the domain, I think there is a problem with cookies: Currently cookies on xwiki.org are valid for all subdomains. This will certainly create a mess if a logged in users from the main wiki visits the playground and vice-versa with logins on one side being invalidated by visiting the other site.

I’m +1 to isolating playground, but then we also need to properly isolate the domain, in particular if we want to give users more rights on playground this could also be a security issue.

#7

Yes, it would definitely be better to be more explicit about the domains in xwiki.org configuration. Note that playground.xwiki.org is far from being the only *.xwiki.org service which does not lead to the xwiki.org XWiki instance, so that’s something that needs to be done, isolation of playground or not.

#8

Unfortunately, you cannot configure cookies this way. You cannot indicate that a cookie should be sent to a configured list of subdomains but not others. If you want to share a cookie between two subdomains, you also share the cookies with all other subdomains. See, e.g., this answer on Stack Overflow.

#9
  • It also means more work to upgrade playground.xwiki.org whenever there’s a new LTS, since it’s another full instance to upgrade (AFAIR that was the main reason we made playground a subwiki - I think we had playground as a separate wiki at some point). Also note that xwiki.org has no downtime thanks to the cluster setup. Would we have the same for playground or would we loose this?

I don’t see how it can be easier than now since it’s automatic with a cron. Maybe you mean something else?

It’s the opposite for me. It’s harder since it requires another upgrade and thus more time. Also IMO we don’t need/want to use a stable version, we want to use the LTS for it as we want to show something stable and what users would get when downloading the LTS. BTW I vaguely remember that we had or discussed having playground on myxwiki.org too to test the latest versions. Have you considered this too? We could decide to only propose the latest version to try out.

Last, do we know how many people use playground and whether it’s used for real (and not for spam)? Maybe there’s no real need for it, especially since xwiki is quite easy to install with the demo package or with XWiki SAS’s cloud instances that can be used to test XWiki.

Do we want to do this? Isn’t that risky from a security POV, knowing that giving script rights increases the risk factor?

Thanks

#10

Sorry to step in:

Oh… I lost a page I created there for another topic (Shouldn't headings always be block-level elements?)… is there a public wiki we can use to show examples of issues etc?

#11

As we are mostly late to updates I used the playground several times to check whether bugs/findings exist in current and unmodified versions. For me it is a bigger deal to install a fresh and current xwiki.

I would like to have the playground as lts version or in the latest release. That’s no great difference for me. It only affects my reports in jira so you can decide what you would like the most.

1 Like
#12

Well the technical discussion we had so far was to reuse XWiki SAS infra team tooling to keep the instance up to date. Now even if we don’t rely on that, it’s actually easy to reset the snapshot with a script that would automatically download the latest LTS, since here we don’t care at all about keeping data, so it’s easier to upgrade it alone than to upgrade it along with all the other wikis.

#13

Yes, the point here is to automate the reset to whatever is the currently available version. So there is no upgrade work.

#14

Note: I would be surprised that the XWiki SAS infra tooling supports updating a cluster with no downtime (but I could be wrong). Now, maybe we’re ok to loose that feature (although it’s certainly a good one to have and if we can keep it, we should, since it impacts the feeling our users have about XWiki).

#15

It’s definitely not something critical for playground.

#16

I don’t fully agree. If someone uses the playground and it crashes on them, it reflects on the quality of XWiki. If the playground is not available or slow, the same happens.

#17

Hi everyone,

the date for next upgrade is become closer. Apparently nobody is against that we move playground, so I propose that we progress on that. Note that we can always change our mind in the future: we still have the scripts and all the infra to put it back in xwiki.org if needed.

#18

Well I wasn’t happy about the proposal as shown above and now I see that I won’t be able to use it as I used to, because you need to re-register on it every day you want to use it :frowning:

1 Like