Re: Moving the wiki

2014-11-07 Thread David Caro
On 10/28, Brian Proffitt wrote:
 
 
 - Original Message -
  From: Karsten Wade kw...@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 RD

Tel.: +420 532 294 605
Email: dc...@redhat.com
Web: www.redhat.com
RHT Global #: 82-62605


pgpLf3N7VVpz3

Re: Moving the wiki

2014-11-07 Thread Brian Proffitt
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 dcaro...@redhat.com
 To: Brian Proffitt bprof...@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 kw...@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

Re: Moving the wiki

2014-11-07 Thread David Caro
On 11/07, Brian Proffitt wrote:
 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.
 

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
 
 - Original Message -
  From: David Caro dcaro...@redhat.com
  To: Brian Proffitt bprof...@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 kw...@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

Re: Moving the wiki

2014-10-22 Thread Michael Scherer
Le lundi 20 octobre 2014 à 11:05 -0400, Barak Korren a écrit :
 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)
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 
 of 1GB) 
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?)

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.

 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

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. 

 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) 

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 
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
we need to have a bit more space to operate, that's the issue. 

 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)
We can't do that easily. 

 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)  
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.
-- 
Michael Scherer
Open Source and Standards, Sysadmin


signature.asc
Description: This is a digitally signed message part
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: Moving the wiki

2014-10-22 Thread Karsten Wade
-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