Thread: Expanded information template
All, I've expanded the template for information about clustering projects: http://wiki.postgresql.org/wiki/Clustering#Template_for_information Over the next couple of weeks, I'll be trying to fill out this template for existing projects I know. If any of the project members themselves can get the additional information, that's great. --Josh Berkus
On 3/3/10, Josh Berkus <josh@agliodbs.com> wrote: > I've expanded the template for information about clustering projects: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > Over the next couple of weeks, I'll be trying to fill out this template > for existing projects I know. If any of the project members themselves > can get the additional information, that's great. The main point of the Clustering exercise was to be more attractive to big companies. I suspect one aspect they care about is whether the products they use are commercially supported. Currently it's quite unclear which infrastructure projects are commercially supported or which support companies support which products. Are there any plans to make that information more easily available? -- marko
> I've expanded the template for information about clustering projects: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > Over the next couple of weeks, I'll be trying to fill out this template > for existing projects I know. If any of the project members themselves > can get the additional information, that's great. A few questions: Should these pages be under Clustering, e.g. Clustering/Bucardo? In other words, do we also want a more generic page on the wiki for these projects, or should there be one page that follows the clustering template and serves as the default project page? > * Online Provisioning: Yes/No What exactly do you mean by this? > Programming Languages: And this? Thanks! -- Greg Sabino Mullane greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8
Attachment
Hi, On Wed, 3 Mar 2010 09:54:54 -0500, Greg Sabino Mullane <greg@endpoint.com> wrote: > Should these pages be under Clustering, e.g. Clustering/Bucardo? In other > words, do we also want a more generic page on the wiki for these projects, > or should there be one page that follows the clustering template and > serves as the default project page? Existing "entries" are on separate pages, within the "Clustering" category. Not necessarily under a Clustering/ "subdirectory". >> * Online Provisioning: Yes/No I understood this to be the "add and remove nodes on the fly" feature. Josh? >> Programming Languages: The programming language(s) the specific clustering solution is implemented with? Regards Markus Wanner
Marko, > I suspect one aspect they care about is whether the products > they use are commercially supported. Currently it's quite unclear > which infrastructure projects are commercially supported or which > support companies support which products. Oh, good idea. Will add that to the template. >> > * Online Provisioning: Yes/No > > What exactly do you mean by this? Can you add and drop nodes while the cluster is in operation? >> > Programming Languages: > > And this? What programming languages is the clustering/replication system written in? For example, Bucardo would say "Perl". If anyone can think of labels which are clearer, please do. --Josh Berkus
On Wed, Mar 3, 2010 at 2:19 AM, Josh Berkus <josh@agliodbs.com> wrote: > All, > > I've expanded the template for information about clustering projects: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > Over the next couple of weeks, I'll be trying to fill out this template > for existing projects I know. If any of the project members themselves > can get the additional information, that's great. I have Slony partly filled in; some of the description material needs to be filled in, and that'll take a bit longer. http://wiki.postgresql.org/wiki/Slony A thing that would seem useful to add in would be a section that might be called "PostgreSQL Infrastructure" to describe vital things that either: a) The system uses, that are "edges" of PostgreSQL. For instance, several of the trigger-based replication systems use the txid type added in PostgreSQL 8.3 b) The system might benefit from, should it become available. For instance, I'd expect it to simplify Slony-I if we had, available to us, commit timestamps. That could mostly get rid of the need for "Sync" events. The "txid" functionality contributed by the Skype folk eliminated some kludgy bits of Slony-I (as mentioned in a)). ON TRUNCATE triggers should become useful (tho usage hasn't been implemented yet). Having ON DDL triggers (or something of the sort) would make it plausible to automatically capture DDL changes. -- http://linuxfinances.info/info/linuxdistributions.html
> All, > > I've expanded the template for information about clustering projects: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > Over the next couple of weeks, I'll be trying to fill out this template > for existing projects I know. If any of the project members themselves > can get the additional information, that's great. What does this mean? * Triggers/procedures: Yes/No -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
> What does this mean? > > * Triggers/procedures: Yes/No Whether or not they can be used with the cluster. pgPool2, for example, is not really compatible with triggers, at least not easily. Per feedback, I've expanded the template, with comments to clarify the various bits: http://wiki.postgresql.org/wiki/Clustering#Template_for_information I've also finished filling out the Slony-I page, as an example: http://wiki.postgresql.org/wiki/Slony ... except that I've discovered that the Slony license is not anywhere on slony.info. Need to fix that, guys. --Josh Berkus
> Per feedback, I've expanded the template, with comments to clarify the > various bits: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information FWIW, I've updated the Bucardo page, based on the new template. One thing that might be nice to add is which version of Postgres are supported. For example, Bucardo does not support 7.4 at all (unlike some solutions), but does support 8.4 and 9.0 (again, unlike some solutions). -- Greg Sabino Mullane greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8
Attachment
On 3/7/10 2:57 PM, Greg Sabino Mullane wrote: >> Per feedback, I've expanded the template, with comments to clarify the >> various bits: >> >> http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > FWIW, I've updated the Bucardo page, based on the new template. One thing > that might be nice to add is which version of Postgres are supported. > For example, Bucardo does not support 7.4 at all (unlike some solutions), > but does support 8.4 and 9.0 (again, unlike some solutions). Good point, want to add it to the template? --Josh Berkus
> > What does this mean? > > > > * Triggers/procedures: Yes/No > > Whether or not they can be used with the cluster. pgPool2, for example, > is not really compatible with triggers, at least not easily. I'm ont sure what you are saying "not really compatible with triggers". Can you elaborate? > Per feedback, I've expanded the template, with comments to clarify the > various bits: > > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > > I've also finished filling out the Slony-I page, as an example: > > http://wiki.postgresql.org/wiki/Slony > > ... except that I've discovered that the Slony license is not anywhere > on slony.info. Need to fix that, guys. > > > --Josh Berkus >
Josh Berkus wrote: > I've expanded the template for information about clustering projects: > http://wiki.postgresql.org/wiki/Clustering#Template_for_information > Over the next couple of weeks, I'll be trying to fill out this template > for existing projects I know. If any of the project members themselves > can get the additional information, that's great. > Obviously collecting accurate info here is the hard part and I don't want to get in the way of that with formatting trivia. But at some point, at least the "General Info" section here really needs to be turned into a proper MediaWiki template. That not only will make the formatting consistent across all the pages, it will allow adding new fields as needed (they'll just show up as empty for entries that don't fill in a value yet), and it makes a future effort to scrape all this data out into a master table a whole lot easier to accomplish. Brendan Jurd is the resident "Turn this repetitive pile of data into a proper template" wizard for the PG Wiki, cc'ing him here to see if he has any time to help out with this one. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 8 March 2010 13:44, Greg Smith <greg@2ndquadrant.com> wrote: > But at some point, at least the "General Info" section here really needs to > be turned into a proper MediaWiki template. That not only will make the > formatting consistent across all the pages, it will allow adding new fields > as needed (they'll just show up as empty for entries that don't fill in a > value yet), and it makes a future effort to scrape all this data out into a > master table a whole lot easier to accomplish. > > Brendan Jurd is the resident "Turn this repetitive pile of data into a > proper template" wizard for the PG Wiki, cc'ing him here to see if he has > any time to help out with this one. I'd be happy to assist with this. The existing layout seems fairly straightforward and should translate into a template quite smoothly. I'll see about working something up over the next day or so. Cheers, BJ
On 8 March 2010 13:55, Brendan Jurd <direvus@gmail.com> wrote: > On 8 March 2010 13:44, Greg Smith <greg@2ndquadrant.com> wrote: >> But at some point, at least the "General Info" section here really needs to >> be turned into a proper MediaWiki template. That not only will make the >> formatting consistent across all the pages, it will allow adding new fields >> as needed (they'll just show up as empty for entries that don't fill in a >> value yet), and it makes a future effort to scrape all this data out into a >> master table a whole lot easier to accomplish. >> >> Brendan Jurd is the resident "Turn this repetitive pile of data into a >> proper template" wizard for the PG Wiki, cc'ing him here to see if he has >> any time to help out with this one. > > I'd be happy to assist with this. The existing layout seems fairly > straightforward and should translate into a template quite smoothly. > > I'll see about working something up over the next day or so. Well that "next day or so" ended up being rather more like what Earthlings like to call a "month", but I did actually get around to working on this today. The new template is at http://wiki.postgresql.org/wiki/Template:ClusteringProject. I have converted the Slony page http://wiki.postgresql.org/wiki/Slony across to the template; it seemed like a useful subject for the experiment because the page content was very complete and conformed closely to the template. I'm happy to convert the remaining project pages, but I thought I'd stop here, take a breather and request feedback on what I've done so far. Cheers, BJ
Brendan Jurd wrote: > The new template is at > http://wiki.postgresql.org/wiki/Template:ClusteringProject. I have > converted the Slony page http://wiki.postgresql.org/wiki/Slony across > to the template; it seemed like a useful subject for the experiment > because the page content was very complete and conformed closely to > the template. > I just tried to convert the Pgpool-II page, as another example that includes almost all the information there, and that didn't go very well. I think that by targeting a template for the entire page, it has gotten a bit too complicated in terms of how much wiki-fu is needed to use it right now. The main sticking point for me was getting the "General Information" piece filled in correctly, in the middle of the rest of the sections. Couple of possibilities to make this easier, just to give some ideas on what might improve that situation: 1) Put that one first in the template definition, even if it shows up later. 2) Break that out into its own sub-template 3) Is it possible to name the fields rather than rely strictly on order? I'm concerned that we won't be able to add fields to template later anywhere but the end without breaking existing pages. Having some sort of "name=value" orientation would make it more obvious what you were filling in too; if that's not practical, maybe the example to copy should suggest how to use some sort of comment markup to document what field you're filling in? Also, one missing entry from there is "Synchronous Replication?", which is used in that entry and I think should be mentioned in all of them. This is a good example of (3)--that should go after "Online Provisioning" I think, and if you add it to the template now every existing page (just Slony right now) would need to be updated. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 27 March 2010 04:55, Greg Smith <greg@2ndquadrant.com> wrote: > I just tried to convert the Pgpool-II page, as another example that includes > almost all the information there, and that didn't go very well. I think > that by targeting a template for the entire page, it has gotten a bit too > complicated in terms of how much wiki-fu is needed to use it right now. The > main sticking point for me was getting the "General Information" piece > filled in correctly, in the middle of the rest of the sections. Could you elaborate on what it was exactly that you found difficult? It should have been as simple as a straight copy-paste of the wiki source from the Slony page, and then just replace the values in there with whatever was said about pgpool. Maybe I'm too close to the problem, but I don't see any wiki-fu required to use the template ... you just separate the arguments with pipes, right? > Couple of > possibilities to make this easier, just to give some ideas on what might > improve that situation: > > 1) Put that one first in the template definition, even if it shows up later. We can do that, but I'm still pretty fuzzy on how that would help or what problem it would solve. If the order of arguments differs from the order of presentation that seems likely to confuse. > 2) Break that out into its own sub-template We can do that too. But wouldn't that just make the calling syntax more complex (calling one template inside another template is messier than calling one template)? > 3) Is it possible to name the fields rather than rely strictly on order? > I'm concerned that we won't be able to add fields to template later > anywhere but the end without breaking existing pages. Having some sort of > "name=value" orientation would make it more obvious what you were filling in > too; if that's not practical, maybe the example to copy should suggest how > to use some sort of comment markup to document what field you're filling in? > Keywords would be fine ... I'll update the template to use them and fix the Slony page. > Also, one missing entry from there is "Synchronous Replication?", which is > used in that entry and I think should be mentioned in all of them. This is > a good example of (3)--that should go after "Online Provisioning" I think, > and if you add it to the template now every existing page (just Slony right > now) would need to be updated. I'll add it to the template while I'm in there.
Brendan Jurd wrote: > Could you elaborate on what it was exactly that you found difficult? > It should have been as simple as a straight copy-paste of the wiki > source from the Slony page, and then just replace the values in there > with whatever was said about pgpool. > > Maybe I'm too close to the problem, but I don't see any wiki-fu > required to use the template ... you just separate the arguments with > pipes, right? > Accidentally wipe out or insert a new pipe character anywhere--particularly one around the information section where there's a series of "yes|no|yes" type of stuff--and it's nearly impossible to fix that if you don't notice until after a bunch of other editing. That's what I did; ended up accidentally moving one pipe character from one spot to another, didn't catch it immediately, and after half an hour I gave up because I couldn't figure out how to get everything in the right section to recover from that. It was actually displaying the "|" in the text for me at one point for no reason I could figure out. Copying from another full entry is dangerous too, because it's easy to not update every field that way and be left with an inaccurate mix of the two. I'd rather we end up where we can suggest people use the template entry instead and not have that be too difficult. > Keywords would be fine ... I'll update the template to use them and > fix the Slony page. > I think that will be enough to address the main things I found difficult about the current template. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On 29 March 2010 15:38, Greg Smith <greg@2ndquadrant.com> wrote:
> Brendan Jurd wrote:
>> Keywords would be fine ... I'll update the template to use them and
>> fix the Slony page.
>
> I think that will be enough to address the main things I found difficult
> about the current template.
I have switched over to keywords, and updated the Slony page. You can
now enter your arguments in whatever order makes you happy, and also
leave out some arguments without causing mass breakage.
The arguments can be set up as optional in the template; at the moment
the only optional ones are 'usecase', 'drawbacks', 'sponsors',
'support' and 'other'. If any other arguments are omitted from the
template call, you will see an ugly template placeholder for it when
you preview your changes (for example, you might see {{{failover}}} if
you forgot to put in the failover argument).
Cheers,
BJ