Discussion:
[Plone-docs] Plone deployment manual
T. Kim Nguyen
2011-07-27 04:22:28 UTC
Permalink
Hello again - apologies if it seems I am barraging the list.

As part of the monthly PloneEdu calls we've been coming up with ideas on how to build resources for (primarily) educational institutions using Plone. One of those ideas is to create documentation relating to how educational institutions have deployed Plone: the server environment, cacheing, authentication, load balancing, and so on.

(While PloneEdu's mission is specifically education related, a lot of what we do is of general use to any organization using Plone).

In my completely unscientific method of looking around for "plone deployment manual", "plone deployment guide", "how to deploy Plone", I have found some resources here and there, but nothing pulling it all together in one place, presumably on plone.org/documentation.

Content that would be useful in such a manual:

- the above bits and pieces of a production stack

- sample configurations (buildouts, squid.cfg, pound.cfg, httpd.conf, ssl.conf, etc.)

- case studies of deployments (by "deployment" I refer specifically to the server setup)

- forms for accepting new deployment case studies submitted

Has this already been done? If not, does this seem like a good idea, and if so, how to proceed?

Kim
Dylan Jay
2011-07-27 05:11:08 UTC
Permalink
Post by T. Kim Nguyen
Hello again - apologies if it seems I am barraging the list.
As part of the monthly PloneEdu calls we've been coming up with
ideas on how to build resources for (primarily) educational
institutions using Plone. One of those ideas is to create
documentation relating to how educational institutions have deployed
Plone: the server environment, cacheing, authentication, load
balancing, and so on.
(While PloneEdu's mission is specifically education related, a lot
of what we do is of general use to any organization using Plone).
In my completely unscientific method of looking around for "plone
deployment manual", "plone deployment guide", "how to deploy Plone",
I have found some resources here and there, but nothing pulling it
all together in one place, presumably on plone.org/documentation.
- the above bits and pieces of a production stack
- sample configurations (buildouts, squid.cfg, pound.cfg,
httpd.conf, ssl.conf, etc.)
- case studies of deployments (by "deployment" I refer specifically to the server setup)
- forms for accepting new deployment case studies submitted
Has this already been done? If not, does this seem like a good
idea, and if so, how to proceed?
My opinion (and keep in mind it is just my opinion) is that the place
for this and all future development manual work should be

http://plone.org/documentation/manual/plone-community-developer-documentation

which is edited via reST and sphinx and github as per these
instructions http://plone.org/documentation/manual/plone-community-developer-documentation/introduction/writing

NOTE: at the time of writing this that document is out of date and the
secondary copy at readthedocs is now more up to date.
http://collective-docs.readthedocs.org/en/latest/introduction/writing.html
. We're working on fixing this so the plone.org version would be
updated nightly.

My suggestion is we deprecate all other developer manuals and KB
articles which overlap with the collective developer manual and
concentrate on cleaning up and making this manual both clean, easy to
understand and comprehensive.

With regard to deployment I'd suggest we enhance the "hosting" section
of this manual

http://collective-docs.readthedocs.org/en/latest/hosting/index.html


Note: these comments don't apply to the users manual or other kinds of
documentation.
Post by T. Kim Nguyen
Kim
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
T. Kim Nguyen
2011-07-28 14:15:56 UTC
Permalink
Thanks Dylan.

I'm afraid that contributors (including me) will be scared off by the fairly complex learning and setup required to add to this documentation (Sphinx, collective commit rights, svn, restructured text) as opposed to editing a Plone page (or equivalent).

Is the http://collective-docs.readthedocs.org/en/latest/hosting/index.html documentation updated the same way?

Kim
My opinion (and keep in mind it is just my opinion) is that the place for this and all future development manual work should be
http://plone.org/documentation/manual/plone-community-developer-documentation
which is edited via reST and sphinx and github as per these instructionshttp://plone.org/documentation/manual/plone-community-developer-documentation/introduction/writing
NOTE: at the time of writing this that document is out of date and the secondary copy at readthedocs is now more up to date.
http://collective-docs.readthedocs.org/en/latest/introduction/writing.html. We're working on fixing this so the plone.org version would be updated nightly.
My suggestion is we deprecate all other developer manuals and KB articles which overlap with the collective developer manual and concentrate on cleaning up and making this manual both clean, easy to understand and comprehensive.
With regard to deployment I'd suggest we enhance the "hosting" section of this manual
http://collective-docs.readthedocs.org/en/latest/hosting/index.html
Note: these comments don't apply to the users manual or other kinds of documentation.
Alex Clark
2011-07-28 14:59:13 UTC
Permalink
Hi,
Post by T. Kim Nguyen
Thanks Dylan.
I'm afraid that contributors (including me) will be scared off by the fairly complex learning and setup required to add to this documentation (Sphinx, collective commit rights, svn, restructured text) as opposed to editing a Plone page (or equivalent).
Is the http://collective-docs.readthedocs.org/en/latest/hosting/index.html documentation updated the same way?
Yup, and this is exactly why we've been stalled on documentation for
years now. We have two competing camps who have very strong preferences
about how they contribute/edit documentation[1]. The c-docs are the only
"excitement" we've seen lately IMHO.

The good news though, is that GitHub actually supports TTW editing. So
in the case of the hosting docs Dylan just mentioned, one could edit
them TTW by going here:


*
https://github.com/collective/collective.developermanual/blob/master/source/hosting/apache.txt


Of course, you'd have to be familiar with restructured text, but that is
a fair compromise IMHO (I.e. you don't have to understand Sphinx or
collective commit rights at least.)

Anyway, if we want to encourage folks to contribute docs on plone.org by
using Plone, then we should be doing a much better job at managing
plone.org. Maybe the connexions thing could solve or address this
somehow (by lightening the plone.org/PHC load.) *shrug*



Alex




[1] I feel pretty strongly that the FWT should grab some sane set of
documentation from the various offerings and ship it, versioned, with
each major release of Plone. But I've not gotten enough buy in to
consider an actual PLIP (where I'd happily do the work.)
Post by T. Kim Nguyen
Kim
My opinion (and keep in mind it is just my opinion) is that the place for this and all future development manual work should be
http://plone.org/documentation/manual/plone-community-developer-documentation
which is edited via reST and sphinx and github as per these instructionshttp://plone.org/documentation/manual/plone-community-developer-documentation/introduction/writing
NOTE: at the time of writing this that document is out of date and the secondary copy at readthedocs is now more up to date.
http://collective-docs.readthedocs.org/en/latest/introduction/writing.html. We're working on fixing this so the plone.org version would be updated nightly.
My suggestion is we deprecate all other developer manuals and KB articles which overlap with the collective developer manual and concentrate on cleaning up and making this manual both clean, easy to understand and comprehensive.
With regard to deployment I'd suggest we enhance the "hosting" section of this manual
http://collective-docs.readthedocs.org/en/latest/hosting/index.html
Note: these comments don't apply to the users manual or other kinds of documentation.
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
--
Alex Clark · http://aclark.net
T. Kim Nguyen
2011-07-28 23:32:48 UTC
Permalink
I seem to have stepped into a minefield. :) =20

I come in peace! I was just sharing my reaction to how I would have =
to install a bunch of software on a computer, and learn a bunch of ne=
w things ("new" meaning "not Plone"), and, yes, I'm a techie but I st=
ill want to do as little extra work as possible. Dylan, it's not tha=
t I or other technical contributors CAN'T learn restructured text, bu=
t that we'd have to use git or svn or Sphinx, and those tools are not=
as easy to use as Plone or cnx.org. =20

Ideally, contributors would have as low a barrier as possible, to avo=
id discouraging them from contributing. When I contribute a "how to"=
to my own site (uwosh.edu/ploneprojects) I don't even want to have t=
o THINK, so I have a link on the site that takes me to the how to fol=
der's createObject call. That's what I mean by making it super super=
easy... frictionless, superconducting, K-Y for process. :)

Alex, yes I could just forge ahead but I know the only efforts that w=
ork long term are those that gain wide acceptance. It would be self =
defeating for the Plone community to have competing documentation pro=
cesses and venues.

How about this: I will take a portion of the Plone user manual and ge=
t it into cnx.org, then show y'all what I think are the cool things o=
ne can do with it there.

About hosting documentation (which, to quibble, doesn't have quite th=
e same meaning to me as "deployment") I was also thinking about a rep=
o for configuration files. Is there such a thing already? I think i=
t should be outside the documentation, since documentation such as ma=
nuals/guides are linear.

=09Kim
Hi,
=20
Post by T. Kim Nguyen
Thanks Dylan.
=20
I'm afraid that contributors (including me) will be scared off by =
the fairly complex learning and setup required to add to this documen=
tation (Sphinx, collective commit rights, svn, restructured text) as =
opposed to editing a Plone page (or equivalent).
Post by T. Kim Nguyen
=20
Is the http://collective-docs.readthedocs.org/en/latest/hosting/in=
dex.html documentation updated the same way?
=20
=20
Yup, and this is exactly why we've been stalled on documentation fo=
r=20
years now. We have two competing camps who have very strong prefere=
nces=20
about how they contribute/edit documentation[1]. The c-docs are the=
only=20
"excitement" we've seen lately IMHO.
=20
The good news though, is that GitHub actually supports TTW editing.=
So=20
in the case of the hosting docs Dylan just mentioned, one could edi=
t=20
=20
=20
*=20
https://github.com/collective/collective.developermanual/blob/maste=
r/source/hosting/apache.txt
=20
=20
Of course, you'd have to be familiar with restructured text, but th=
at is=20
a fair compromise IMHO (I.e. you don't have to understand Sphinx or=
=20
collective commit rights at least.)
=20
Anyway, if we want to encourage folks to contribute docs on plone.o=
rg by=20
using Plone, then we should be doing a much better job at managing=
=20
plone.org. Maybe the connexions thing could solve or address this=
=20
somehow (by lightening the plone.org/PHC load.) *shrug*
=20
=20
=20
Alex
=20
=20
=20
=20
[1] I feel pretty strongly that the FWT should grab some sane set o=
f=20
documentation from the various offerings and ship it, versioned, wi=
th=20
each major release of Plone. But I've not gotten enough buy in to=
=20
consider an actual PLIP (where I'd happily do the work.)
=20
=20
=20
Post by T. Kim Nguyen
=20
=09Kim
=20
=20
=20
Post by T. Kim Nguyen
=20
=20
My opinion (and keep in mind it is just my opinion) is that the p=
lace for this and all future development manual work should be
Post by T. Kim Nguyen
=20
http://plone.org/documentation/manual/plone-community-developer-d=
ocumentation
Post by T. Kim Nguyen
=20
which is edited via reST and sphinx and github as per these instr=
uctionshttp://plone.org/documentation/manual/plone-community-develope=
r-documentation/introduction/writing
Post by T. Kim Nguyen
=20
NOTE: at the time of writing this that document is out of date an=
d the secondary copy at readthedocs is now more up to date.
Post by T. Kim Nguyen
http://collective-docs.readthedocs.org/en/latest/introduction/wri=
ting.html. We're working on fixing this so the plone.org version woul=
d be updated nightly.
Post by T. Kim Nguyen
=20
My suggestion is we deprecate all other developer manuals and KB =
articles which overlap with the collective developer manual and conce=
ntrate on cleaning up and making this manual both clean, easy to unde=
rstand and comprehensive.
Post by T. Kim Nguyen
=20
With regard to deployment I'd suggest we enhance the "hosting" se=
ction of this manual
Post by T. Kim Nguyen
=20
http://collective-docs.readthedocs.org/en/latest/hosting/index.ht=
ml
Post by T. Kim Nguyen
=20
=20
Note: these comments don't apply to the users manual or other kin=
ds of documentation.
Post by T. Kim Nguyen
=20
=20
------------------------------------------------------------------=
------------
Post by T. Kim Nguyen
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help ofte=
n.
Post by T. Kim Nguyen
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
=20
=20
--=20
Alex Clark =B7 http://aclark.net
=20
=20
-------------------------------------------------------------------=
-----------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often=
.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Dylan Jay
2011-07-29 01:46:06 UTC
Permalink
Post by T. Kim Nguyen
I seem to have stepped into a minefield. :)
I come in peace! I was just sharing my reaction to how I would have
to install a bunch of software on a computer, and learn a bunch of
new things ("new" meaning "not Plone"), and, yes, I'm a techie but I
still want to do as little extra work as possible. Dylan, it's not
that I or other technical contributors CAN'T learn restructured
text, but that we'd have to use git or svn or Sphinx, and those
tools are not as easy to use as Plone or cnx.org.
Ideally, contributors would have as low a barrier as possible, to
avoid discouraging them from contributing. When I contribute a "how
to" to my own site (uwosh.edu/ploneprojects) I don't even want to
have to THINK, so I have a link on the site that takes me to the how
to folder's createObject call. That's what I mean by making it
super super easy... frictionless, superconducting, K-Y for process. :)
yes I understand your reaction. I'd say however that encouraging
people to contribute is not our biggest problem. Already anyone can
submit a KB article using plone. And many have done so. So already
this problem is solved.

Our biggest problem IMO is of consolidation, ie letting someone
contribute documentation to the right place so there aren't multiple
different out of date versions of the same advice in different places.
So we want people to THINK because not thinking of how they can
combine or improve others efforts has got us to the current state of
documentation we are in today.

Admittedly the c.docs is heading in the same way of having multiple
places talking about the same topics but we'll clean that up soon
enough :)

The goal is one developer manual which you can read end to end and it
makes sense and doesn't contradict itself or repeat itself. And yet is
still reasonably easy to contribute to.

The other aspect is we want core developers to document their own
apis. Core developers are already using git/svn. Sphinx makes is
incredibly easy to include docs from code into our manual. I've
already done this for several of the GS module level docs (which I had
to add). The easier we make this for them the better. The system is
broken if we expect non-developers to document developers code because
they won't.
Post by T. Kim Nguyen
Alex, yes I could just forge ahead but I know the only efforts that
work long term are those that gain wide acceptance. It would be
self defeating for the Plone community to have competing
documentation processes and venues.
How about this: I will take a portion of the Plone user manual and
get it into cnx.org, then show y'all what I think are the cool
things one can do with it there.
sure, can't do any hard with regard to the users manual but you might
want to talk to the people who maintain the users manual. I've lost
track of who that is.
Post by T. Kim Nguyen
About hosting documentation (which, to quibble, doesn't have quite
the same meaning to me as "deployment") I was also
I was suggesting renaming hosting to deployment.
Post by T. Kim Nguyen
thinking about a repo for configuration files. Is there such a
thing already? I think it should be outside the documentation,
since documentation such as manuals/guides are linear.
yes there is zopeskel. Also those at the sauna sprint are working on
improving these aspects of zopeskel now I believe.
Post by T. Kim Nguyen
Kim
Post by Alex Clark
Hi,
Post by T. Kim Nguyen
Thanks Dylan.
I'm afraid that contributors (including me) will be scared off by
the fairly complex learning and setup required to add to this
documentation (Sphinx, collective commit rights, svn, restructured
text) as opposed to editing a Plone page (or equivalent).
Is the http://collective-docs.readthedocs.org/en/latest/hosting/index.html
documentation updated the same way?
Yup, and this is exactly why we've been stalled on documentation for
years now. We have two competing camps who have very strong
preferences
about how they contribute/edit documentation[1]. The c-docs are the only
"excitement" we've seen lately IMHO.
The good news though, is that GitHub actually supports TTW editing. So
in the case of the hosting docs Dylan just mentioned, one could edit
*
https://github.com/collective/collective.developermanual/blob/master/source/hosting/apache.txt
Of course, you'd have to be familiar with restructured text, but that is
a fair compromise IMHO (I.e. you don't have to understand Sphinx or
collective commit rights at least.)
Anyway, if we want to encourage folks to contribute docs on
plone.org by
using Plone, then we should be doing a much better job at managing
plone.org. Maybe the connexions thing could solve or address this
somehow (by lightening the plone.org/PHC load.) *shrug*
Alex
[1] I feel pretty strongly that the FWT should grab some sane set of
documentation from the various offerings and ship it, versioned, with
each major release of Plone. But I've not gotten enough buy in to
consider an actual PLIP (where I'd happily do the work.)
Post by T. Kim Nguyen
Kim
Post by Dylan Jay
My opinion (and keep in mind it is just my opinion) is that the
place for this and all future development manual work should be
http://plone.org/documentation/manual/plone-community-developer-documentation
which is edited via reST and sphinx and github as per these
instructionshttp://plone.org/documentation/manual/plone-community-developer-documentation/introduction/writing
NOTE: at the time of writing this that document is out of date
and the secondary copy at readthedocs is now more up to date.
http://collective-docs.readthedocs.org/en/latest/introduction/writing.html
. We're working on fixing this so the plone.org version would be
updated nightly.
My suggestion is we deprecate all other developer manuals and KB
articles which overlap with the collective developer manual and
concentrate on cleaning up and making this manual both clean,
easy to understand and comprehensive.
With regard to deployment I'd suggest we enhance the "hosting" section of this manual
http://collective-docs.readthedocs.org/en/latest/hosting/index.html
Note: these comments don't apply to the users manual or other kinds of documentation.
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
--
Alex Clark · http://aclark.net
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Encolpe Degoute
2011-07-29 14:32:35 UTC
Permalink
I tried to start such a job with the zopeskel.unis project
You can find deployement explaination here:
- https://github.com/collective/zopeskel.unis/tree/master/docs

And sample for configuration here:
-
https://github.com/collective/zopeskel.unis/tree/master/zopeskel/unis/templates/unis_plone4_buildout/profiles/etc
-
https://github.com/collective/zopeskel.unis/tree/master/zopeskel/unis/templates/unis_plone4_buildout/profiles/modules

It's done in ReST to be displayed in github, but it can be done in other
markdown system:
https://github.com/collective/zopeskel.unis/wiki/Debian-Squeeze

Regards
Post by T. Kim Nguyen
Hello again - apologies if it seems I am barraging the list.
As part of the monthly PloneEdu calls we've been coming up with ideas on how to build resources for (primarily) educational institutions using Plone. One of those ideas is to create documentation relating to how educational institutions have deployed Plone: the server environment, cacheing, authentication, load balancing, and so on.
(While PloneEdu's mission is specifically education related, a lot of what we do is of general use to any organization using Plone).
In my completely unscientific method of looking around for "plone deployment manual", "plone deployment guide", "how to deploy Plone", I have found some resources here and there, but nothing pulling it all together in one place, presumably on plone.org/documentation.
- the above bits and pieces of a production stack
- sample configurations (buildouts, squid.cfg, pound.cfg, httpd.conf, ssl.conf, etc.)
- case studies of deployments (by "deployment" I refer specifically to the server setup)
- forms for accepting new deployment case studies submitted
Has this already been done? If not, does this seem like a good idea, and if so, how to proceed?
Kim
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Loading...