Here is a great intro: https://tiki.org/Presentation-Fosdem-2014-show.tiki.org (see PDF)

Please see show.tiki.org for a more detailed description of requirements and architecture.

This is a joint project of the Wishlist Triage Team, assisted by the Infrastructure Team.

Planning has started for Show3

Why

• To facilitate bug reporting and solving
  • It can be quite time consuming to read and understand some of the bug reports (They are often edge cases). Experience shows that if you can demonstrate a bug (and for a regression, pinpoint which commit introduces it), things can get fixed quickly. Even better is demonstrate the issue with data & all on a server which offers SSH (ideally with debug tools). Or that devs can easily dump the data.
• Help with Bug triages
  • Being able tell users that bugs that can be repeated on show will have a higher chance of being resolved. If the user takes the time to help us, then we will take the time to thank them by evaluating the bug clearly demonstrated by the user
• Releases
  • Not only will show.tiki.org help external users but can become a valuable tool for the community especially during release times.

What

• An easy way for any registered tiki.org user to generate a Tiki instance of any version (including from SVN)
• Admin rights are provided, so the instance can be configured uniquely to demonstrate the bug
• This server will host hundreds of Tiki instances, each showing something specific.

Conclusion of dicussion of 2013-07-18 webinar

1- All code commits to doc/devtools/
2- Live with 2 weeks on dev.tiki.org (so July 31st 2013)

User story

1. It is assumed John is already a registered user of tiki.org
2. John goes to dev.tiki.org/show.tiki.org (a wiki page)
3. John is presented with a real simple summary of the basic steps and the web form to get started
4. John fills in simple web form to get a test Tiki
   • Picks version number (ex.: 9.2 or branch and revision number)
   • Enters a subdirectory (optional) that matches his own Tiki, as some bugs might only happen within a subdirectory
   • Instance is created (may take a few minutes) and John receives notification by email
5. In the meantime, John is encouraged on screen to read about the steps that follow.
6. John receives email that the instance is ready. He clicks on link in his email and is directed to complete the next step, which is to configure the new Tiki (a link to john-1.show.tiki.org will be on the page) to demonstrate the issue
7. The email must contain an image telling the user what to enter to get past the htaccess check (otherwise he might wonder what to enter when the prompt appears)
8. Once John is finished configuring his Tiki to demonstrate the issue, he goes back to the original page (dev.tiki.org/show.tiki.org-john)
9. There will be a form on this page for submitting info to the bug tracker. This will be a simplified form that contains only the following questions:
   • What did you do
   • What happened
   • What you expected instead to happen
   • Any additional information
   • In addition, the browser user agent is auto-detected and submitted together with the form
10. As part of the form, John is encouraged to do a Screencast (later on once we are sure JCapture Screencast works well on all browsers we might want to make this mandatory).
11. John clicks submit. If there are any missing fields, this is prevented from going through. Dev bug report tracker item is created and the user gets a watch set automatically for that tracker item.
12. The original wiki page is updated with a link to the tracker item here (this can probably be done through a trackerlist plugin with a search on a new field).
13. The original page is updated with buttons for developers to download (1) mysql dump of various snapshots of instance (2) mysql dump of version (before any configuration) for mysqldiffing purposes (3) dump of code which include the .svn files (anonymous checkout).
14. Whenever a snapshot of instance is created a backend script runs to scan the mysqldump for any hardcoded domain names. If so, it displays a warning on the page (which will be useful for devs) where the hardcoded domain names in the content/prefs are.
15. The URL to this original page is inserted in the bug tracker field for linked show.tiki.org URL, so that when viewing the bug tracker item there is a convenient link to this page.
16. There should also be a button for users to create snapshots which are tarballs of the code and db of the code at any time.
17. Very often, John as well as devs will want to know if the bug has been solved in a future version, therefore, on the original page where all the download dump etc... buttons are, there should also be a drop down/input fields to select a version/branch/revision to test an upgrade to.
18. In fact, this should be explicitly stated as one of the things the user should try.
19. When an upgrade version is selected and triggered, the system will automatically clone a new instance, e.g. 1-rxxxx.john.show.tiki.org or 1-v8_5.john.show.tiki.org and upgrade it to the version specified. As this will take a while the user will get an email when this is complete. The link to the upgraded version will be placed on the page for reference so the user can access it there as well as through the email.
20. The user can then test the upgraded version to see if the bug exists there. The user can only clone one updated version at any one time.

Discussion about User story

[28/05/2013 4:33:07 PM] *** Marc Laporte added amette_ger, Pascal St-Jean ***
[28/05/2013 4:33:40 PM] Marc Laporte: Hi guys!
[28/05/2013 4:34:19 PM] Marc Laporte: I am meeting with Pascal and we planning stuff....
[28/05/2013 4:34:37 PM] Marc Laporte: We are wondering what are the next steps for show.tiki.org
[28/05/2013 4:36:24 PM] amette_ger: I'll create a virtual machine on the citadelrock elastichosts account and we'll start building what we defined at tikifest.
[28/05/2013 4:41:52 PM] Marc Laporte: ok, what have you decided with respect to shell scrips, PHP, Tiki Console, etc ?
[28/05/2013 4:55:05 PM] Marc Laporte: who will be working on this?
[28/05/2013 4:56:13 PM] Jean-Marc Libs: Ahh, a server :) amette: ping me when it's created
[28/05/2013 4:57:25 PM] Jean-Marc Libs: Also, this will mostly be piloted from the community server, so I will need some effective sudo access there (which I should have, but don't)
[28/05/2013 4:58:57 PM] Jean-Marc Libs: Does anyone here have functional sudo access on the community server? All I need is a non-empty password there
[28/05/2013 4:59:12 PM] Marc Laporte: I don't
[28/05/2013 4:59:41 PM] Jean-Marc Libs: amette?
[28/05/2013 5:00:27 PM] Marc Laporte: when will the actual coding start?
[28/05/2013 5:01:34 PM] Marc Laporte: Nelson is on vacation and when he will come back, he should have quite a big backlog, so his availibility will be limited. If there are some things we are expecting from him, we should have a clear list. Do you need anything from Nelson?
[28/05/2013 5:03:26 PM] Jean-Marc Libs: A server. A DNS redirection of *.show.tiki.org on that server.
[28/05/2013 5:04:07 PM] Jean-Marc Libs: Can't think of anything else right now
[28/05/2013 5:05:20 PM] Marc Laporte: DNS: I can help with that
[28/05/2013 5:08:46 PM] Marc Laporte: where do I point show.tiki.org?
[28/05/2013 5:10:24 PM] Jean-Marc Libs: To the virtual server amette said he WILL create. You are too impatient, unless the IP address is already known  :)
[28/05/2013 5:11:10 PM] Marc Laporte: creating a virtual machine should be quite fast :)
[28/05/2013 5:37:06 PM] Marc Laporte: So Pascal and I looked at the wiki pages and we think that what is there is quite ambitious
[28/05/2013 5:37:53 PM] Marc Laporte: Some things could be pushed to a phase 2 or phase 3 and we would still have humongous benefits for Tiki
[28/05/2013 5:40:52 PM] Jean-Marc Libs: My plan is certainly to start with the easy bits :)
[28/05/2013 5:50:15 PM] Marc Laporte: Not to redo the discussion of the TikiFest, but we have the following ideas on steps for the "simplest thing that could work". Every week without this tool, we have wasted time for bug tracking and reporting
[28/05/2013 5:50:25 PM] Marc Laporte: Perhaps:
[28/05/2013 5:50:28 PM | Edited 5:57:50 PM] Marc Laporte: 1- Simplest that could possibly work
* I am logged to a Tiki site (dev/show.tiki.org which is on InterTiki?)
* username in URL + random number
* Installs any version/rev
* Answer with a URL 
* Active devs have SSH access
* .htpassword
* List of all instances
* Find a way for admin password
[28/05/2013 5:50:36 PM] Marc Laporte: 2- optional
* Sending notification emails  (user knows to check there in 10 minutes)
* run a profile to do things like activate action log
[28/05/2013 5:50:42 PM] Marc Laporte: 3- Snapshot and upgrade
[28/05/2013 5:50:47 PM] Marc Laporte: 4- Better UI/integration with bug trackers
[28/05/2013 5:51:29 PM] Marc Laporte: We feel that #3 and #4 could be work and delays and they are not essential to getting people reporting bugs efficiently (there are workarounds)
[28/05/2013 5:53:17 PM | Edited 5:53:37 PM] Marc Laporte: For ex.: #3:   Upgrading via the interface would be nice, but it's quite rare that a bug is caused by the actual upgrade script. If someone wants to show a regression, they can ask the system for a 9.4 and a 10.2, configured them both the same, and explain that in the bug tracker
[28/05/2013 5:55:33 PM] Marc Laporte: #4:  We don't need a really good tracking of all Tiki instances created if we have the username in them. It would be better of course to have a tracker with all instance and meta-data, but as long as username is in URL, we should get by
[28/05/2013 5:59:29 PM] Marc Laporte: Nelson is coming back June 1st
[28/05/2013 6:11:06 PM] Jean-Marc Libs: ok, I need to sleep now. Tomorrow is a long day, as was today…
[28/05/2013 6:11:20 PM] amette_ger: yo, sorry guys, had a surprising visitor
[28/05/2013 6:11:28 PM] amette_ger: ok, just quickly
[28/05/2013 6:12:16 PM] amette_ger: We won't need nelson for the first stage, I will create a virtual machine as soon as possible - timeline was end of this month, we are now one week late - sorry, but it took me amazingly long to arrive back in BLN after Canada.
[28/05/2013 6:13:12 PM] amette_ger: Im offline this weekend, so expect the virtual machine somewhen middle next week - I'll let you know Jean-Marc!
[28/05/2013 6:13:24 PM] amette_ger: have a good night! :)
[28/05/2013 6:13:32 PM] Jean-Marc Libs: good night!

Other requirements not in user story

Deletion of instances

1. Once issue is confirmed resolved by person reporting, instance is deleted. If the issue is resolved by developer but not confirmed as resolved or reopened by a certain time (e.g. 1 month), the deletion should go ahead anyway.
2. It will be great to be able to show the diff of preferences/settings changed as well (although this info can be gotten by a dev by mysqldiffing).

Some points

1. Having the tiki.org username in the URL is a good way to detect vandals and also to get in touch for a follow-up
2. Any developer can understand the issue rapidly and can have SSH access to the server to investigate, and recuperate the exact instance to their local environment.

Some other suggestions

While it's mainly for showing bugs, it could also be used by community members who are collaborating on a new feature in trunk. They could show it off there (with data that makes it easy to use) and get some help/feedback during the dev phase. For example when Arild was developing the new references feature, he could have received some quick feedback, but setting everything up is often tricky/time consuming for a new feature that doesn't yet have docs and a neat UI.

It could also be used to take screenshots for documentation.

It could also be used as a live demo/documentation of a specific feature. Especially one which is not dogfed on *.tiki.org

If there needs to have an environment for devs to ssh in to check, then it is a separate feature/project: investigate.tiki.org or whatever, rather then show.tiki.org which should not have too many ssh access to developers.

Questions

• Should Xdebug be on the server? (Answer: not for now at least - because developers will be getting dumps)
• We likely don't want these to be indexed (demo.tiki.org neither for that matter). How do we make sure they are excluded? robots.txt or htpasswd? (Answer: we will use htpasswd)

Advanced

• A web-based interface of TRIM would permit power users to test themselves to see if bug was resolved (ex.: reported in 9.0, and testing in 9.1)
• A web-based interface of TRIM would permit power users to duplicate and demonstrate upgrade bugs
• Having dev:SVN-Bisect on the server would be useful
  • Even better if it can be managed via web interface and power users can detect and demonstrate which regression caused a bug
• The recipe for all this will be open source and anyone will be able to reproduce, but it's possible that some things could be specific to the server setup.

Who

• Pascal St-Jean
• Nelson Ko
• Amette
• Jyhem

Limitations

• This won't help to show bugs with a specific version of PHP or MySQL.
  • However, if we develop this with a generic tool like Chef, Juju, Ansible, Puppet or Salt, we could spin up new servers with different configuration and run the same tests

Thinking ahead

The immediate goal is to have the "simplest thing that could possibly work", but in order to converge community efforts, it makes sense that this platform can also be used for any organizations that wants to deploy/maintain a large number of Tiki instances. Ex.:

• the Testing Team projects and
• for a WikiFarm
• for Configuration Management and Systems Orchestration

Scenarios

Each instance has its own virtual server

Benefits

• Each instance can have distinct version of server software (PHP, MySQL), which is useful if this is the bug we are tracking
• Devs can change these without affecting the rest of the dev server
  • This is very important to work on / show an error message of a specific setting (strict mode, php config, etc)

Drawbacks

• We need a dev:Configuration Management and Systems Orchestration tool
• Uses a lot of
  • disk space
  • RAM
  • CPUb

One instance with many Tikis

Benefits

• Uses less disk space
• Quick reporting. No/little setup required, assuming Tiki is pre-configured.

Drawbacks

• Problem scenario must match an existing Tiki setup, to be able to show it.

Related

• http://article.gmane.org/gmane.comp.cms.tiki.devel/29727
• https://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software
• Pre-Dogfood Server
• SVN-Bisect and revision picker on demo.tiki.org (to find/report regressions)
• https://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia-servers-are-configured/
• bug/regression test cases
• https://www.ohloh.net/p/aegirproject