10:05 a.m.
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.
1:19 p.m.
--=-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?)
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 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=
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--
1:44 p.m.
-----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-----
4:50 a.m.
----- Original Message -----
From: "Karsten Wade" <kwade(a)redhat.com>
To: infra(a)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
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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs
Er8AniDXc74R7QYk7s62s+nxZ1sTnn37
=IgIn
-----END PGP SIGNATURE-----
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
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
5:13 a.m.
--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(a)redhat.com>
> To: infra(a)ovirt.org
> Sent: Wednesday, October 22, 2014 9:44:00 PM
> Subject: Re: Moving the wiki
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
> -----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
>
_______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
=20
>
iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs
> Er8AniDXc74R7QYk7s62s+nxZ1sTnn37
> =3DIgIn
> -----END PGP SIGNATURE----- =20
=20
At Barak's request, I wanted to outline what should be the next phase for= =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(a)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(a)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--
5:31 a.m.
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(a)redhat.com>
To: "Brian Proffitt" <bproffit(a)redhat.com>
Cc: infra(a)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(a)redhat.com>
> > To: infra(a)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
--
Brian Proffitt
Community Liaison
oVirt
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs
> > Er8AniDXc74R7QYk7s62s+nxZ1sTnn37
> > =IgIn
> > -----END PGP SIGNATURE-----
> >
_______________________________________________
> > Infra mailing list
> > Infra(a)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(a)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(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
5:51 a.m.
--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(a)redhat.com>
> > To: "Brian Proffitt" <bproffit(a)redhat.com>
> > Cc: infra(a)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(a)redhat.com>
> > > > To: infra(a)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
> > >
> > > >
_______________________________________________
> > > > Infra mailing list
> > > > Infra(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > =20
> > > >
iEYEARECAAYFAlRH+vAACgkQ2ZIOBq0ODEHEOwCgnGCFXO7tKVAoCM4YfkM0MYSs
> > > > Er8AniDXc74R7QYk7s62s+nxZ1sTnn37
> > > > =3DIgIn
> > > > -----END PGP SIGNATURE----- =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(a)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(a)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(a)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--
3452
days inactive
3470
days old
6 comments
5 participants
participants (5)
-
Barak Korren -
Brian Proffitt -
David Caro -
Karsten Wade -
Michael Scherer