There has been some talk recently about moving the ovirt.org wiki to a dedicated VM in the PHX data-center. I would like to open this up to some discussion. Here is the current situation as far as I could gather, more info and comment are welcome. What do we have now ------------------- MediaWiki (Which version? eedri told me its a rather old one) PHP (Which version?) MySQL 5.1 All running in a single (?) 'large' OpenShift gear. Our OpenShift account is classified as 'silver' (is it?) thereby granting us gears with 6GB storage instead of 1GB) Why do we want to migrate? -------------------------- We occasionally have a problem where the site goes down. This seems to be caused by one of: 1. The OpenShift gear runs out of space 2. The MySQL DB gets stuck with no errors in the logs (Does restarting it resolve it?) Why not to migrate? ------------------- 1. Migrating the wiki to PHX VM will make the infra team have to manage the wiki hosting infrastructure. While one may claim that this is not complicated and that this work needs to also be done when the wiki is hosted on OpenShift, there are still many things that the OpenShift maintainers do for us such as: - Keeping the webservers updated - Managing selinux - Enablign automatic scale-up 2. There are security concerns with having a public-facing (outdated?) PHP application running on a VM in the same network where our build and CI servers run. (I might be too paranoid here, having had one of my own sites defaced recently, but OpenShift makes it easy to create a new gear and git push the code to get back up and running, with our own VM, forensics and cleanup might be more complicated) Known infra issues with existing configuration ---------------------------------------------- 1. The MySQL DB was setup without 'innodb_file_per_table' turned on, this can impact DB performance. To resolve this, one need to dump and import the entire DB. Things we can try (Besides migrating) ------------------------------------- 1. Place ovirt.org behind a caching reverse-proxy CDN like cloudflare, that can mask some of our downtime. 2. Dump and import the DB to rebuild and optimize the DB files 3. Rebuild the wiki in a new gear to get rid of possibly accumulating cruft 4. Upgrade the MySQL to 5.5 (Or whatever latest supported by OpenShift) 5. Upgrade MediaWiki 6. Add a redundant MySQL/Wiki server using MySQL replication 7. Trim the wiki history (AFAIK MediaWiki saves every edit ever, but one can maybe use export/import to get rid of some) 8. Try to come up with a way to spread the Wiki across multiple OpenShift gears 9. Tune DB parameters (is it possible to do on OpenShift?) I eagerly await your comments, Regards, Barak.
--=-DvBECKhlQMWW2/tJYDKS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le lundi 20 octobre 2014 =C3=A0 11:05 -0400, Barak Korren a =C3=A9crit :
There has been some talk recently about moving the ovirt.org wiki to a de= dicated VM in the PHX data-center. I would like to open this up to some discussion. Here is the current situation as far as I could gather, more info and com= ment are welcome. =20 What do we have now ------------------- MediaWiki (Which version? eedri told me its a rather old one) 1.18 ( or 1.19 )
PHP (Which version?) 5.3.3
MySQL 5.1 All running in a single (?) 'large' OpenShift gear. yes
Our OpenShift account is classified as 'silver' (is it?) thereby granting= us gears with 6GB storage instead=20 of 1GB)=20 yes. I think we even already have 10G
Why do we want to migrate? -------------------------- We occasionally have a problem where the site goes down. This seems to be= caused by one of: 1. The OpenShift gear runs out of space 2. The MySQL DB gets stuck with no errors in the logs (Does restarting it= resolve it?)
Why not to migrate? ------------------- 1. Migrating the wiki to PHX VM will make the infra team have to manage t= he wiki hosting infrastructure.=20 While one may claim that this is not complicated and that this work ne= eds to also be done when the wiki=20 is hosted on OpenShift, there are still many things that the OpenShift=
it usually was out of memory issue. besides the problem, one reason to go to a more traditional setup for me is that, being traditional, we have more freedom. For example, installing varnish directly, having access to log without a middleman, ease of backup. And the capacity to use vanilla mediawiki. maintainers do for us such as:
- Keeping the webservers updated
there is just yum upgrade -y to do. I do not see that much as a hindrance.
- Managing selinux
There is nothing to manage, selinux work out of the box on RHEL. Also, due to the nature of openshift, the policy will only protect the host, but you would still be able to access network and this kind access. While with our own setup, we can have a tailored policy or firewall.
- Enablign automatic scale-up
We have no scale up for that, and due to mediawiki itself, we either have to patch it to not use the filesystem ( people suggested to use s3 ), or wait until fs is shared on openshift.=20
2. There are security concerns with having a public-facing (outdated?) PH= P application running on a VM in=20 the same network where our build and CI servers run. (I might be too p= aranoid here, having had one of my own sites defaced recently, but OpenShift makes it easy to create a ne= w gear and git push the code to=20 get back up and running, with our own VM, forensics and cleanup might = be more complicated)=20
I do not see how openshift will be easier. We can make a snapshot of the VM in ovirt too, afaik, so the forensic wouldn't be harder ( and in fact, would preserve the memory, which is rather important ).
Known infra issues with existing configuration ---------------------------------------------- 1. The MySQL DB was setup without 'innodb_file_per_table' turned on, this= can impact DB performance. To=20 resolve this, one need to dump and import the entire DB. =20 Things we can try (Besides migrating) ------------------------------------- 1. Place ovirt.org behind a caching reverse-proxy CDN like cloudflare, th= at can mask some of our downtime. 2. Dump and import the DB to rebuild and optimize the DB files we need to have a bit more space to operate, that's the issue.=20
3. Rebuild the wiki in a new gear to get rid of possibly accumulating cru= ft 4. Upgrade the MySQL to 5.5 (Or whatever latest supported by OpenShift) We can't do that easily.=20
5. Upgrade MediaWiki We would have to rediff some of the patchs, I would rather start from scratch.
6. Add a redundant MySQL/Wiki server using MySQL replication Not working due to gears isolation. IE, 2 gears cannot communicate that easily. This would be doable with a special embedded cartridge.
7. Trim the wiki history (AFAIK MediaWiki saves every edit ever, but one = can maybe use export/import to get rid of some) =20 Why drop history, that's like dropping git history :/
8. Try to come up with a way to spread the Wiki across multiple OpenShift= gears Rather hard to do, especially since we are not root.
9. Tune DB parameters (is it possible to do on OpenShift?) No, since the mysql is managed by openshift we are not root.
I eagerly await your comments,
I still think the easiest way is to host our own setup. --=20 Michael Scherer Open Source and Standards, Sysadmin --=-DvBECKhlQMWW2/tJYDKS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJUR/UuAAoJEE89Wa+PrSK9vwsQAKk3vb4q105VK+TUpYH/SdnU Emn/y3y6zaBNnE0UudOzXp2LhIxCdao7Yri59PnsKM9gjPZJkMPdTwjFuw8S67sm 8MdNCZDz1AkSqHAh2TQyA+iY4L6BOHQQlbSGfxhDH1+ewGhbWVDELNzyvNmUJz01 Y5edB0YVeCeQ7GrGzlF4494edDUnFURQHogVu5tFwqtAzPguruKSsVsuaZMK1SQO H8y0BvBrWUkVsh9y11PbByKx/GspeQb3Jh+7HAcGwUeCIAcq7cPT1SdZePXsjb9p 9ruyHu/2V91W8KuQ7eVCkqAPXwFn+cjJCFwj9XFxks/XlcOSVZibleFjxYiOEGzL QyDozkldM5/FRaqynLtpuxtS0hwRMIS8EZLin36fut0RBTiE2V8I8htzthwk+Kgf IHe9II54wzdcjNvfXt2xMvqSURP0siTj6P20SxLnLTtMR/es14x/ugIbYiMP2HE+ AZQBTUlke6vSumKp0AlOsK5WN/uv6tcRplz3A/YQATs8xdZA1q8Leeeg8Nx96yRt +UsxQwFMf6ecsKKXxFNi1WcV1IlniOJdMEkFXsRmd3LKUYvdHPs2YE1RqFszcp4I E0jHV8quh0gB/9qlkuLrhRt211bV456ZHaGLCT4/uBWEDrScOh+RIkavd/iwX3jQ W8hBxZuklseO/W71vK8s =+no9 -----END PGP SIGNATURE----- --=-DvBECKhlQMWW2/tJYDKS--
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/2014 11:19 AM, Michael Scherer wrote:
I still think the easiest way is to host our own setup.
Two notes: * While there is definitely increased work for the Infra team in bringing it back from OpenShift, it also takes away some of the work being done to keep the OpenShift instance running well. * We can always move back about as easily, such as when service features are at parity. One of my concerns about OpenShift is that it now doesn't fit into the rest of the Infra scheme. If we're maintaining everything with Foreman/Puppet, for example, wouldn't it be a bit easier to bring the wiki server in to the same scheme? It's like the problems we have with linode01.ovirt.org -- it's outside of the rest of the process Infra uses, so it's more likely problems will build up there until they get noticed. - - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs Er8AniDXc74R7QYk7s62s+nxZ1sTnn37 =IgIn -----END PGP SIGNATURE-----
----- Original Message -----
From: "Karsten Wade" <kwade@redhat.com> To: infra@ovirt.org Sent: Wednesday, October 22, 2014 9:44:00 PM Subject: Re: Moving the wiki
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2014 11:19 AM, Michael Scherer wrote:
I still think the easiest way is to host our own setup.
Two notes:
* While there is definitely increased work for the Infra team in bringing it back from OpenShift, it also takes away some of the work being done to keep the OpenShift instance running well.
* We can always move back about as easily, such as when service features are at parity.
One of my concerns about OpenShift is that it now doesn't fit into the rest of the Infra scheme. If we're maintaining everything with Foreman/Puppet, for example, wouldn't it be a bit easier to bring the wiki server in to the same scheme?
It's like the problems we have with linode01.ovirt.org -- it's outside of the rest of the process Infra uses, so it's more likely problems will build up there until they get noticed.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs Er8AniDXc74R7QYk7s62s+nxZ1sTnn37 =IgIn -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
At Barak's request, I wanted to outline what should be the next phase for oVirt.org, which may render this discussion moot. At least, the discussion of shifting away from OpenShift, based on MediaWiki. We may want to migrate away for other reasons, but this will probably not be one of them. oVirt.org is currently a MediaWiki site, and as such has a lot of (expected) user collaboration. But that collaboration is not terribly organized, and has no version control whatsoever. This makes it impossible for a group like Content Services to scrape documentation content into their process, and the end-user experience is also sub-optimal. As an alternative, the OSAS design team wants oVirt.org to move over to Middleman-based when we revamp the site later this year. This would mean that content would be stored on GitHub as markdown (MD) or HTML files, and then Middleman would be used to edit content locally as well as deploy onto the production site. This is currently how projectatomic.io handles Clearly, moving from a wiki to something static like a Middleman/GitHub solution is drastic, but Garrett LeSage and Tuomas Kuosmanen have come up with an idea: prose.io is a third-party WYSIWYG editor that ties directly in to GitHub repos. We will have links on the new oVirt.org site for each page or section of a page that would open up the source content for that page/section in prose.io, where a user could then edit the content and save it with a simple GUI that would bypass the complexity of git commands. Depending on the user's permissions, the edited content would be deployed immediately on the site or held as a pull request for later approval. An alternative to prose.io that Garrett has also proposed is bolting on an admin UI for editing blog posts using various existing components (mainly for rich editing), so the entire thing could be done via a browser-based interface (only available when running in development).
From a user perspective, the experience is no different than using a wiki. If we use prose.io, will have to have a GitHub account, but for our users, that's not much or a hurdle, since they would have to have a MediaWiki account on oVirt.org anyway.
There are issues to narrow down with this plan (like how do oVirt.org users add new pages?), but so far, it feels like a good solution and a positive step away from MediaWiki. Peace, Brian -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC
--Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/28, Brian Proffitt wrote: >=20 >=20 > ----- Original Message ----- > > From: "Karsten Wade" <kwade@redhat.com> > > To: infra@ovirt.org > > Sent: Wednesday, October 22, 2014 9:44:00 PM > > Subject: Re: Moving the wiki > >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > On 10/22/2014 11:19 AM, Michael Scherer wrote: > > > I still think the easiest way is to host our own setup. > >=20 > > Two notes: > >=20 > > * While there is definitely increased work for the Infra team in > > bringing it back from OpenShift, it also takes away some of the work > > being done to keep the OpenShift instance running well. > >=20 > > * We can always move back about as easily, such as when service > > features are at parity. > >=20 > > One of my concerns about OpenShift is that it now doesn't fit into the > > rest of the Infra scheme. If we're maintaining everything with > > Foreman/Puppet, for example, wouldn't it be a bit easier to bring the > > wiki server in to the same scheme? > >=20 > > It's like the problems we have with linode01.ovirt.org -- it's outside > > of the rest of the process Infra uses, so it's more likely problems > > will build up there until they get noticed. > >=20 > > - - Karsten > > - -- > > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > > http://TheOpenSourceWay.org \ http://community.redhat.com > > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > >=20 > > iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs > > Er8AniDXc74R7QYk7s62s+nxZ1sTnn37 > > =3DIgIn > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > >=20 >=20 > At Barak's request, I wanted to outline what should be the next phase for= oVirt.org, which may render this discussion moot. At least, the discussion= of shifting away from OpenShift, based on MediaWiki. We may want to migrat= e away for other reasons, but this will probably not be one of them. >=20 > oVirt.org is currently a MediaWiki site, and as such has a lot of (expect= ed) user collaboration. But that collaboration is not terribly organized, a= nd has no version control whatsoever. This makes it impossible for a group = like Content Services to scrape documentation content into their process, a= nd the end-user experience is also sub-optimal. >=20 > As an alternative, the OSAS design team wants oVirt.org to move over to M= iddleman-based when we revamp the site later this year. This would mean tha= t content would be stored on GitHub as markdown (MD) or HTML files, and the= n Middleman would be used to edit content locally as well as deploy onto th= e production site. This is currently how projectatomic.io handles=20 >=20 > Clearly, moving from a wiki to something static like a Middleman/GitHub s= olution is drastic, but Garrett LeSage and Tuomas Kuosmanen have come up wi= th an idea: prose.io is a third-party WYSIWYG editor that ties directly in = to GitHub repos. We will have links on the new oVirt.org site for each page= or section of a page that would open up the source content for that page/s= ection in prose.io, where a user could then edit the content and save it wi= th a simple GUI that would bypass the complexity of git commands. Depending= on the user's permissions, the edited content would be deployed immediatel= y on the site or held as a pull request for later approval. >=20 Feels strange to me having a project outside gerrit, that means having to setup and manage user acces also on github. Is there a way to use gerrit as base repo and only replicate to github as we currently do with other projects? Is the requirement of a web ui a strict one? Because I really like the idea of having the docs managed as code (reviews, git history and even ci) > An alternative to prose.io that Garrett has also proposed is bolting on a= n admin UI for editing blog posts using various existing components (mainly= for rich editing), so the entire thing could be done via a browser-based i= nterface (only available when running in development).=20 >=20 > From a user perspective, the experience is no different than using a wiki= =2E If we use prose.io, will have to have a GitHub account, but for our use= rs, that's not much or a hurdle, since they would have to have a MediaWiki = account on oVirt.org anyway.=20 >=20 > There are issues to narrow down with this plan (like how do oVirt.org use= rs add new pages?), but so far, it feels like a good solution and a positiv= e step away from MediaWiki. >=20 > Peace, > Brian >=20 > --=20 > Brian Proffitt >=20 > Community Liaison > oVirt > Open Source and Standards, Red Hat - http://community.redhat.com > Phone: +1 574 383 9BKP > IRC: bkp @ OFTC > _______________________________________________ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUXKlsAAoJEEBxx+HSYmnD1lwIAItpTkWEH/R2yK3E+Cuq1YLc didExpJ5pDYP+OyuAxkZGjidVOS5EoFk4uoKYpgX5aBwSk1Y7OZ/kZ4rSJ7PoEly 3dP4xmXCyXIAvl3eS47PLvy4wNogGprNqzmUdfZ1V9wuuIpQLtUsatjd4ozFBY6c accpNB0/5n4cAxrP+W79zO7aHEL8gDSHJLMNQYaFJn2+Wk6fnIGJy0n06w4nw5H7 w6zN55XwMJQoR6Z8wGQULd3otVFXuDkHVso+N7MaAZUH/SaoaFo/Hn8stEpxbaCD uBU0SCwFVDOijydmVjmnaQiE8woQxeS2Pf6cUMH3t8Fu+CtzH7yPATmvMVqqMA8= =twIq -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi--
Right now, the focus on GitHub-based solution is a direct result of planning to use Prose.io; that's the only repo system that Prose.io works with, as far as I know. And, to answer your other question, a Web-based GUI is critical to making this work. Otherwise will will introduce git (or gerrit) commands and functions into the website-editing process, which would create a much higher barrier to entry. That said, it does appear that Garrett is working on a home-grown solution similar to Prose.io as I metnioned earlier, which *may* be able to work with alternate repos, such as Bitbucket or even gerrit. BKP ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Brian Proffitt" <bproffit@redhat.com> Cc: infra@ovirt.org Sent: Friday, November 7, 2014 6:13:48 AM Subject: Re: Moving the wiki
On 10/28, Brian Proffitt wrote:
----- Original Message -----
From: "Karsten Wade" <kwade@redhat.com> To: infra@ovirt.org Sent: Wednesday, October 22, 2014 9:44:00 PM Subject: Re: Moving the wiki
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2014 11:19 AM, Michael Scherer wrote:
I still think the easiest way is to host our own setup.
Two notes:
* While there is definitely increased work for the Infra team in bringing it back from OpenShift, it also takes away some of the work being done to keep the OpenShift instance running well.
* We can always move back about as easily, such as when service features are at parity.
One of my concerns about OpenShift is that it now doesn't fit into the rest of the Infra scheme. If we're maintaining everything with Foreman/Puppet, for example, wouldn't it be a bit easier to bring the wiki server in to the same scheme?
It's like the problems we have with linode01.ovirt.org -- it's outside of the rest of the process Infra uses, so it's more likely problems will build up there until they get noticed.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs Er8AniDXc74R7QYk7s62s+nxZ1sTnn37 =IgIn -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
At Barak's request, I wanted to outline what should be the next phase for oVirt.org, which may render this discussion moot. At least, the discussion of shifting away from OpenShift, based on MediaWiki. We may want to migrate away for other reasons, but this will probably not be one of them.
oVirt.org is currently a MediaWiki site, and as such has a lot of (expected) user collaboration. But that collaboration is not terribly organized, and has no version control whatsoever. This makes it impossible for a group like Content Services to scrape documentation content into their process, and the end-user experience is also sub-optimal.
As an alternative, the OSAS design team wants oVirt.org to move over to Middleman-based when we revamp the site later this year. This would mean that content would be stored on GitHub as markdown (MD) or HTML files, and then Middleman would be used to edit content locally as well as deploy onto the production site. This is currently how projectatomic.io handles
Clearly, moving from a wiki to something static like a Middleman/GitHub solution is drastic, but Garrett LeSage and Tuomas Kuosmanen have come up with an idea: prose.io is a third-party WYSIWYG editor that ties directly in to GitHub repos. We will have links on the new oVirt.org site for each page or section of a page that would open up the source content for that page/section in prose.io, where a user could then edit the content and save it with a simple GUI that would bypass the complexity of git commands. Depending on the user's permissions, the edited content would be deployed immediately on the site or held as a pull request for later approval.
Feels strange to me having a project outside gerrit, that means having to setup and manage user acces also on github. Is there a way to use gerrit as base repo and only replicate to github as we currently do with other projects?
Is the requirement of a web ui a strict one? Because I really like the idea of having the docs managed as code (reviews, git history and even ci)
An alternative to prose.io that Garrett has also proposed is bolting on an admin UI for editing blog posts using various existing components (mainly for rich editing), so the entire thing could be done via a browser-based interface (only available when running in development).
From a user perspective, the experience is no different than using a wiki. If we use prose.io, will have to have a GitHub account, but for our users, that's not much or a hurdle, since they would have to have a MediaWiki account on oVirt.org anyway.
There are issues to narrow down with this plan (like how do oVirt.org users add new pages?), but so far, it feels like a good solution and a positive step away from MediaWiki.
Peace, Brian
-- Brian Proffitt
Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605
-- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC
--GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11/07, Brian Proffitt wrote: > Right now, the focus on GitHub-based solution is a direct result of plann= ing to use Prose.io; that's the only repo system that Prose.io works with, = as far as I know. And, to answer your other question, a Web-based GUI is cr= itical to making this work. Otherwise will will introduce git (or gerrit) c= ommands and functions into the website-editing process, which would create = a much higher barrier to entry. >=20 > That said, it does appear that Garrett is working on a home-grown solutio= n similar to Prose.io as I metnioned earlier, which *may* be able to work w= ith alternate repos, such as Bitbucket or even gerrit. >=20 I prefer this solution if it fits. @Garret, can I get an early preview or something? I'd like to start using it asap and solving any issues. We can start with some infra docs or something. btw. Would it be an issue if we host the static pages on gh-pages? I'm trying to push this because I'm writing some infra docs about the phx lab and if ready I'd like to create a prove of concept for the flow. > BKP >=20 > ----- Original Message ----- > > From: "David Caro" <dcaroest@redhat.com> > > To: "Brian Proffitt" <bproffit@redhat.com> > > Cc: infra@ovirt.org > > Sent: Friday, November 7, 2014 6:13:48 AM > > Subject: Re: Moving the wiki > >=20 > > On 10/28, Brian Proffitt wrote: > > >=20 > > >=20 > > > ----- Original Message ----- > > > > From: "Karsten Wade" <kwade@redhat.com> > > > > To: infra@ovirt.org > > > > Sent: Wednesday, October 22, 2014 9:44:00 PM > > > > Subject: Re: Moving the wiki > > > >=20 > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > >=20 > > > > On 10/22/2014 11:19 AM, Michael Scherer wrote: > > > > > I still think the easiest way is to host our own setup. > > > >=20 > > > > Two notes: > > > >=20 > > > > * While there is definitely increased work for the Infra team in > > > > bringing it back from OpenShift, it also takes away some of the work > > > > being done to keep the OpenShift instance running well. > > > >=20 > > > > * We can always move back about as easily, such as when service > > > > features are at parity. > > > >=20 > > > > One of my concerns about OpenShift is that it now doesn't fit into = the > > > > rest of the Infra scheme. If we're maintaining everything with > > > > Foreman/Puppet, for example, wouldn't it be a bit easier to bring t= he > > > > wiki server in to the same scheme? > > > >=20 > > > > It's like the problems we have with linode01.ovirt.org -- it's outs= ide > > > > of the rest of the process Infra uses, so it's more likely problems > > > > will build up there until they get noticed. > > > >=20 > > > > - - Karsten > > > > - -- > > > > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > > > > http://TheOpenSourceWay.org \ http://community.redhat.com > > > > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: GnuPG v1 > > > >=20 > > > > iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs > > > > Er8AniDXc74R7QYk7s62s+nxZ1sTnn37 > > > > =3DIgIn > > > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > > > Infra mailing list > > > > Infra@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > >=20 > > >=20 > > > At Barak's request, I wanted to outline what should be the next phase= for > > > oVirt.org, which may render this discussion moot. At least, the discu= ssion > > > of shifting away from OpenShift, based on MediaWiki. We may want to > > > migrate away for other reasons, but this will probably not be one of = them. > > >=20 > > > oVirt.org is currently a MediaWiki site, and as such has a lot of > > > (expected) user collaboration. But that collaboration is not terribly > > > organized, and has no version control whatsoever. This makes it impos= sible > > > for a group like Content Services to scrape documentation content into > > > their process, and the end-user experience is also sub-optimal. > > >=20 > > > As an alternative, the OSAS design team wants oVirt.org to move over = to > > > Middleman-based when we revamp the site later this year. This would m= ean > > > that content would be stored on GitHub as markdown (MD) or HTML files= , and > > > then Middleman would be used to edit content locally as well as deploy > > > onto the production site. This is currently how projectatomic.io hand= les > > >=20 > > > Clearly, moving from a wiki to something static like a Middleman/GitH= ub > > > solution is drastic, but Garrett LeSage and Tuomas Kuosmanen have com= e up > > > with an idea: prose.io is a third-party WYSIWYG editor that ties dire= ctly > > > in to GitHub repos. We will have links on the new oVirt.org site for = each > > > page or section of a page that would open up the source content for t= hat > > > page/section in prose.io, where a user could then edit the content and > > > save it with a simple GUI that would bypass the complexity of git > > > commands. Depending on the user's permissions, the edited content wou= ld be > > > deployed immediately on the site or held as a pull request for later > > > approval. > > >=20 > >=20 > > Feels strange to me having a project outside gerrit, that means having > > to setup and manage user acces also on github. Is there a way to use > > gerrit as base repo and only replicate to github as we currently do > > with other projects? > >=20 > > Is the requirement of a web ui a strict one? Because I really like the > > idea of having the docs managed as code (reviews, git history and even > > ci) > >=20 > > > An alternative to prose.io that Garrett has also proposed is bolting = on an > > > admin UI for editing blog posts using various existing components (ma= inly > > > for rich editing), so the entire thing could be done via a browser-ba= sed > > > interface (only available when running in development). > > >=20 > > > From a user perspective, the experience is no different than using a = wiki. > > > If we use prose.io, will have to have a GitHub account, but for our u= sers, > > > that's not much or a hurdle, since they would have to have a MediaWiki > > > account on oVirt.org anyway. > > >=20 > > > There are issues to narrow down with this plan (like how do oVirt.org= users > > > add new pages?), but so far, it feels like a good solution and a posi= tive > > > step away from MediaWiki. > > >=20 > > > Peace, > > > Brian > > >=20 > > > -- > > > Brian Proffitt > > >=20 > > > Community Liaison > > > oVirt > > > Open Source and Standards, Red Hat - http://community.redhat.com > > > Phone: +1 574 383 9BKP > > > IRC: bkp @ OFTC > > > _______________________________________________ > > > Infra mailing list > > > Infra@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > >=20 > > -- > > David Caro > >=20 > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > >=20 > > Tel.: +420 532 294 605 > > Email: dcaro@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > >=20 >=20 > --=20 > Brian Proffitt >=20 > Community Liaison > oVirt > Open Source and Standards, Red Hat - http://community.redhat.com > Phone: +1 574 383 9BKP > IRC: bkp @ OFTC --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUXLIrAAoJEEBxx+HSYmnDtB4H/RgMa4Y0EAMwNMJjEQ7hh9Yt ojTsjz/h2f3Xnf1ap6hhuWcVDh8UuPApeBbxTUzrceYHjfoe4d9fwcYApHJS/ZPA YQSKtyY4tlNGHkuWuI7p1Ax1QUQx8svStTR32DX+j9pc3bQDU/TizNpqt2G1mFfA YS1VaLa8PZDgVkGxOf1mQRNNg60KVACp8dvJjYYoSatN6dURXoo+ei9eOk9L7BSQ 74mg/+6h494RFqdm/hggrPOdXE86U5BuSb7FePu+aGqnvmS370CooPUjgb/KWYR3 HmWs9+5UBcjnpNsumMf6W9oL6RibYoXRcf5qtlnTXhbFfTfsjT/kZhTPPyX5jAk= =ylRs -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7--
participants (5)
-
Barak Korren -
Brian Proffitt -
David Caro -
Karsten Wade -
Michael Scherer