Hi Detlef, Thorsten, et al,

First, as Thorsten pointed out, a project proposal should set a voting 
timeout period. Since Detlef didn't set one, let me propose that the 
proposal timeout next Wednesday, December 12. Please note that we need a 
consensus for new project creation. As it currently stands, with 
Thorsten's -1, we don't have consensus. Nonetheless, let's continue the 
discussion for the next week. If, by the timeout date, Thorsten or 
anyone else still votes -1, the project proposal will be rejected.

Now on the proposal itself. I support the work proposed. My only 
question is whether or not it should be a project in and of itself, or 
whether we should instantiate an umbrella PostgreSQL agent project, 
under which this work could be performed.

I understand Thorsten's concern of a "project explosion" if we create 
projects for every agent RFE that comes along. However, I don't see a 
problem approving this proposal as a project at this time. We currently 
have only two sponsored projects. This one would be the third. So we're 
not at "explosion" levels yet. If, in the future, we reach the point 
where we feel that the number of projects is getting out of hand, we can 
form some umbrella projects at that point. But for now, I don't think 
that should be required.

Furthermore, projects are expected to be transitory. That is, once 
completed, they shouldn't show up on the list of "active" projects. So 
the number of active projects at any one time shouldn't be unmanageable. 
I volunteer to add a page to the HA Clusters web site listing the 
"active" and "completed" projects sponsored by the community. That 
should help mitigate some of the concern of exploding projects.

Lastly, I think it would be nice to give this work project status in 
order to give more visibility to it, both to the OpenSolaris community 
and to the PostgreSQL community.

That's my long-winded way of saying +1 !

Thanks,
Nick

Thorsten Frueauf wrote:
> Hi Detlef et al,
> 
> in my answer below the suggestion is that HA PostgreSQL would get its 
> own project. And the RFE would be the first to be developed on it.
> 
> I am not seeing why all what you outlined is not possible or not good 
> enough using the HA PostgreSQL project? And unless the RFE you propose 
> would yield into a new separate agent from HA PostgreSQL I think its 
> enough to have one project per agent.
> 
> For other communities this would be a onestop shop to connect to. And I 
> don't think it would weaken any noise.
> 
> Anyway, you have my opinion, may others speak up as well :)
> 
> Greets
>        Thorsten
> 
> Detlef Ulherr wrote:
>> Hi Thorsten et al,
>>
>> I agree on the proposal to not swamp the project page. But I think major
>> enhancements will get more attention if we make them a project. So from
>> my opinion we should place small and medium RFE's in an umbrella
>> project, but major enhancements should get a better marketing by a
>> separate project.
>>
>> I will create the RFE anyway.
>>
>> My case for a project is:
>> 1. it will be a feature enhancement which lines up with the PostgreSQL
>> concepts, and the projects of the PostgreSQL community. Members of the
>> PostgreSQL community expressed  their opinion, that this will be a
>> highly desired feature.
>> 2. It will be a major change and I think it is worth the bigger noise.
>>
>> Detlef
>>
>>
>>
>>
>> Thorsten Frueauf wrote:
>>> Hi Detlef et al,
>>>
>>> I realized that I overlooked the "project proposal" within the subject. 
>>> Since the mail body does not specifically say that this is a project 
>>> proposal with a call for vote, I thought you want to propose and discuss 
>>> an RFE to the HA PostgreSQL agent. Thats why I directly jumped into a 
>>> technical discussion.
>>>
>>> Can you please clarify if you want to propose a specific new OHAC 
>>> project dedicated to "just" this feature enhancement?
>>>
>>> If so, I vote -1 with the following justification (note the -1 vote is 
>>> NOT against the specific feature enhancement, but against dedicating a 
>>> project to it):
>>>
>>> We have 26 agents within OHAC, each of them is expected to live on and 
>>> thus get additional bug fixes and new features of various sizes along 
>>> with new version qualifications moving forward.
>>>
>>> In the very near future we will also see Geo Edition being open sourced, 
>>> later in 2008 we will see the core framework - all adding new bug fixes, 
>>> feature enhancements and complete new features.
>>>
>>> In order to not end up with an unmanageable amount of separate projects, 
>>> which would belong to the same agent, I therefore suggest you propose to 
>>> create one OHAC project for the HA PostgreSQL agent.
>>>
>>> That project could then be the umbrella for all future bug fixes, RFEs 
>>> and version quals belonging to this agent. We could do the same for each 
>>> of the other OHAC agents, whenever the first bug/rfe/qual comes along. 
>>> Of course new agents would get their own new project (like HA Informix 
>>> and HA xVM already got).
>>>
>>> I further suggest you fill an RFE against the HA PostgreSQL agent for 
>>> the enhancement you proposed - that would then get discussed, developed, 
>>> reviewed etc under the HA PostgreSQL project umbrella.
>>>
>>> The project page can then be used to document all necessary parts for 
>>> this and future things. Interested parties can then easily spot news 
>>> within the News section of the project page and choose to contribute.
>>>
>>> This also would give us the opportunity - should the traffic on 
>>> ha-clusters-discuss explode when we have a lot of active projects - to 
>>> open project specific discussion lists on the project page, where 
>>> interested parties can follow more focused.
>>>
>>> For future project proposals I suggest that it should always include the 
>>> necessary informations as documented within 2.2 at
>>> http://opensolaris.org/os/community/ogb/policies/project-instantiation.txt
>>>
>>> The proposal should then call for a vote and set a reasonable timeout 
>>> (like 14 days) when the vote will end.
>>>
>>> Hope this makes sense :)
>>>
>>> Greets
>>>        Thorsten
>>>
>>> Detlef Ulherr wrote:
>>>   
>>>> Hello everyone,
>>>>
>>>> I would like to propose to enhance the functionality of the PostgreSQL
>>>> agent.
>>>>
>>>> Terminology:
>>>>
>>>> I am using the term cluster under two meanings:
>>>>
>>>>    1.
>>>>
>>>>       OHAC Cluster which is the high availability software, here the
>>>>       term cluster is alwaays preceded by OHAC.
>>>>
>>>>    2.
>>>>
>>>>       PostgreSQL cluster which is a set of postgres databases tied
>>>>       together by a set of postmaster processes, in this usage the term
>>>>       cluster is always preceded by PostgreSQL or database.
>>>>
>>>> Currently PostgreSQL 8.2 allows data to be replicated between two
>>>> PostgreSQL databases clusters by shipping it's write ahead logs (WAL
>>>> logs) from a primary active database to a remote standby database cluster.
>>>>
>>>> This implies that only one PostgreSQL database cluster is active and the
>>>> remote database cluster is running in recovery mode and applying the WAL
>>>> logs that were shipped from the primary database.
>>>>
>>>>
>>>> With the current version of the PostgreSQL agent it is only possible to
>>>> use this functionality to ship the logs from a PostgreSQL database
>>>> cluster under OHAC control to a standalone system not under OHAC control.
>>>>
>>>>
>>>> My proposal would be to enhance the agent with two options:
>>>>
>>>>    1.
>>>>
>>>>       The PostgreSQL agent should be able to control a database which is
>>>>       running in recovery mode. In recovery mode, the monitoring has to
>>>>       work on a reduced level. If the recovery mode terminates and the
>>>>       database transfers into ready state, the agent should switch to
>>>>       full monitoring without intervention.
>>>>
>>>>       This will allow the WAL log shipping functionality between two
>>>>       different clusters.
>>>>
>>>>    2.
>>>>
>>>>       The agent should allow the the log shipping between two databases
>>>>       within one OHAC cluster in a shared nothing topology. If the
>>>>       primary database fails, the standby should be converted to a
>>>>       primary without intervention.
>>>>
>>>>       This will allow PostgreSQL to be used under OHAC control if shared
>>>>       storage is either too expensive, or in a OHAC metro cluster where
>>>>       the latency of host based mirroring has a sever impact on database
>>>>       performance.
>>>>
>>>> To make the solution more comprehensive, the modified agent should
>>>> contain example scripts which make it easier to resilver an old primary
>>>> database after a failover while using WAL log shipping.
>>>>
>>>> Combining the log shipping functionality of PostgreSQL and OHAC cluster
>>>> will give us the option to use the rich set of dependencies which may
>>>> span multiple nodes and zones together with a replicating database.
>>>>
>>>>
>>>> Many thanks in advance for considering this proposal.
>>>>
>>>> Regards
>>>> Detlef
> _______________________________________________
> ha-clusters-discuss mailing list
> ha-clusters-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss

-- 
Nicholas Solter, Solaris Cluster Development
http://blogs.sun.com/nsolter

Reply via email to