On Fri, 2014-06-06 at 09:03 -0400, Simo Sorce wrote:
> On Fri, 2014-06-06 at 06:58 -0400, James wrote:
> > On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote:
> > > Ticket 4302 is a request for an enhancement: Move replication topology to
> > > the shared tree
> >
> >
> > One comment to add:
On 06/06/2014 06:12 PM, Dmitri Pal wrote:
On 06/06/2014 09:03 AM, Simo Sorce wrote:
On Fri, 2014-06-06 at 06:58 -0400, James wrote:
On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz
wrote:
Ticket 4302 is a request for an enhancement: Move replication
topology to
the shared tree
One comment
On 06/06/2014 09:03 AM, Simo Sorce wrote:
On Fri, 2014-06-06 at 06:58 -0400, James wrote:
On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology to
the shared tree
One comment to add:
It would be particularly useful if t
On Fri, 2014-06-06 at 06:58 -0400, James wrote:
> On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote:
> > Ticket 4302 is a request for an enhancement: Move replication topology to
> > the shared tree
>
>
> One comment to add:
>
> It would be particularly useful if the interface used to set t
On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote:
> Ticket 4302 is a request for an enhancement: Move replication topology to
> the shared tree
One comment to add:
It would be particularly useful if the interface used to set the
topology is something sane that a single host can use to set
we need to be careful on the process, I have an idea how it could work,
but need to think a bit more about it
I am all ears.
Simo.
We already have several situations (CRL, DNSSEC, cert rotation) where
a single server has to do the job first and all the rest should rely
on that.
We can sim
On 06/05/2014 01:12 PM, Simo Sorce wrote:
On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote:
On 06/05/2014 03:14 PM, Ludwig Krispenz wrote:
On 06/05/2014 02:45 PM, Simo Sorce wrote:
On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
On 06/04/2014 06:04 PM, thierry bordaz wrote:
On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote:
> On 06/05/2014 03:14 PM, Ludwig Krispenz wrote:
> >
> > On 06/05/2014 02:45 PM, Simo Sorce wrote:
> >> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
> >>> On 06/04/2014 06:04 PM, thierry bordaz wrote:
> But this requires th
On 06/05/2014 03:14 PM, Ludwig Krispenz wrote:
On 06/05/2014 02:45 PM, Simo Sorce wrote:
On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
On 06/04/2014 06:04 PM, thierry bordaz wrote:
But this requires that the node database is already initialized (have
the same replicageneration th
On 06/05/2014 02:45 PM, Simo Sorce wrote:
On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
On 06/04/2014 06:04 PM, thierry bordaz wrote:
But this requires that the node database is already initialized (have
the same replicageneration than the others nodes).
If it is not initialized, i
On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
> On 06/04/2014 06:04 PM, thierry bordaz wrote:
> > But this requires that the node database is already initialized (have
> > the same replicageneration than the others nodes).
> > If it is not initialized, it could be done by any masters.
On 06/04/2014 06:04 PM, thierry bordaz wrote:
On 06/04/2014 05:41 PM, Simo Sorce wrote:
On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
On 06/04/2014 10:43 AM, thierry bordaz wrote:
So my proposal would contain the following components
1] Store replication configuration in the shar
On Wed, 2014-06-04 at 18:04 +0200, thierry bordaz wrote:
> On 06/04/2014 05:41 PM, Simo Sorce wrote:
> > On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
> >> On 06/04/2014 10:43 AM, thierry bordaz wrote:
> So my proposal would contain the following components
>
> 1] Store r
On 06/04/2014 05:41 PM, Simo Sorce wrote:
On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
On 06/04/2014 10:43 AM, thierry bordaz wrote:
So my proposal would contain the following components
1] Store replication configuration in the shared tree in a
combination of server and connectio
On Wed, 2014-06-04 at 11:41 -0400, Simo Sorce wrote:
> On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
> > On 06/04/2014 10:43 AM, thierry bordaz wrote:
> > >
> > >>
> > >> So my proposal would contain the following components
> > >>
> > >> 1] Store replication configuration in the shared
On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
> On 06/04/2014 10:43 AM, thierry bordaz wrote:
> >
> >>
> >> So my proposal would contain the following components
> >>
> >> 1] Store replication configuration in the shared tree in a
> >> combination of server and connection view (think w
On Wed, 2014-06-04 at 13:50 +0200, Ludwig Krispenz wrote:
> my question was more where the r/o replicas would be listed. In
> cn=ro-replicas parallel to cn=matsters,
> or should all servers be in cn=masters and have a replication role defined ?
We do not know yet as we do not have read-only repli
On 06/03/2014 05:59 PM, Simo Sorce wrote:
On Tue, 2014-06-03 at 15:47 +0200, Ludwig Krispenz wrote:
On 06/03/2014 02:53 PM, Simo Sorce wrote:
On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote:
Hi Simo,
just for clarification. The plan is to move the repl config into the
shared tree fo
On 06/04/2014 10:43 AM, thierry bordaz wrote:
So my proposal would contain the following components
1] Store replication configuration in the shared tree in a
combination of server and connection view (think we need both) and
map replication configuration to these entries. I would prefer a
On 06/02/2014 10:46 AM, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been some discussion in comments in the ticket, but I'd like
to open the discussion to a wider audience to get an agreement on what
should be imp
On Tue, 2014-06-03 at 15:47 +0200, Ludwig Krispenz wrote:
> On 06/03/2014 02:53 PM, Simo Sorce wrote:
> > On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote:
> >> Hi Simo,
> >>
> >> just for clarification. The plan is to move the repl config into the
> >> shared tree for the main database and
On 06/03/2014 02:53 PM, Simo Sorce wrote:
On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote:
Hi Simo,
just for clarification. The plan is to move the repl config into the
shared tree for the main database and eventually for others like
o=ipaca. Should the topology info live in cn=etc fo
On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote:
> Hi Simo,
>
> just for clarification. The plan is to move the repl config into the
> shared tree for the main database and eventually for others like
> o=ipaca. Should the topology info live in cn=etc for all databases or
> each in the
Hi Simo,
just for clarification. The plan is to move the repl config into the
shared tree for the main database and eventually for others like
o=ipaca. Should the topology info live in cn=etc for all databases or
each in the database it configures ?
If the main database is always replicated I
On 06/02/2014 08:38 AM, Simo Sorce wrote:
On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
However we may want to be able to mark a topology for 'multiple' sets.
For example we may want to have by default the same topology both for
the main database and for the CA data
On Mon, 2014-06-02 at 12:02 -0600, Rich Megginson wrote:
> Why not (selectively) replicate cn=config?
Because we do not want to just replicate cn=config (which would be
pointless anyway given each server has a completely different set of
replication agreements).
We want a much more abstract view
On 06/02/2014 02:46 AM, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been some discussion in comments in the ticket, but I'd like
to open the discussion to a wider audience to get an agreement on what
should be imp
On Mon, 2014-06-02 at 16:53 +0200, thierry bordaz wrote:
> If server parameters are changed (port number, repl_admin or DM
> password) will it trigger the corresponding modification on the
> shared
> tree on the remote server ?
Well in the IPA case we do not have these issues as those parameters
On 06/02/2014 10:46 AM, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been some discussion in comments in the ticket, but I'd like
to open the discussion to a wider audience to get an agreement on what
should be imp
On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > However we may want to be able to mark a topology for 'multiple' sets.
> > For example we may want to have by default the same topology both for
> > the main database and for the CA database.
>
> I think we should sto
On 06/02/2014 04:08 PM, Rob Crittenden wrote:
Simo Sorce wrote:
First of all, very good summary, thanks a lot!
Replies in line.
On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been
Simo Sorce wrote:
> First of all, very good summary, thanks a lot!
> Replies in line.
>
> On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote:
>> Ticket 4302 is a request for an enhancement: Move replication topology
>> to the shared tree
>>
>>
>> There has been some discussion in comments i
On 06/02/2014 02:59 PM, Simo Sorce wrote:
First of all, very good summary, thanks a lot!
Replies in line.
On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote:
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been some discussion in comm
First of all, very good summary, thanks a lot!
Replies in line.
On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote:
> Ticket 4302 is a request for an enhancement: Move replication topology
> to the shared tree
>
>
> There has been some discussion in comments in the ticket, but I'd like
>
Ticket 4302 is a request for an enhancement: Move replication topology
to the shared tree
There has been some discussion in comments in the ticket, but I'd like
to open the discussion to a wider audience to get an agreement on what
should be implemented, before writing a design spec.
The im
35 matches
Mail list logo
