Broker Federation

[Martin Ritchie <ri...@apache.org>]

Hi all,

I've posted my design thoughts for federation in the Java Broker under
this page:

http://cwiki.apache.org/confluence/display/qpid/ClusteringHA

I'm interested to see what everyone thinks. I know Gordon is working
in this area on the C++ and it would be good to make any configuration
for the C++ broker also work with the Java. In fact I was hoping to
have very minimal configuration so users don't have to worry to much
about configuration

Having read the page on how the C++ broker operates I'm not entirely
sure I follow how it works:
The qpid-route tool doesn't seem to have any authentication details
nor does it seem to talk about the creation of the 'link's that the
Federation design talks to. Is there a bit of information missing?

I think that we should look to use the Java client for the two
components described on the wiki, as extensive testing has already
been performed on it and that it can already implement a number of the
key features. Failover/Reconnection, message filtering (Selectors).
Now it is true that this may be a rather heavy weight solution,
especially as the Message Objects are incompatible. However, we are
already beginning to suffer from having a too many clients. The .NET
client for example is suffering as a result of bug fixes that have
been discovered and resolved in the Java not being check in the .NET.
As the two share a common history it is highly likely that any bug the
Java has the .NET will share.

For this reason it would seem crazy to add yet another client albeit a
cut down version that has basic protocol functionality. Utilising the
existing Java client gives us an initial implementation from which we
can perform benchmarking. It also means any speed gains we develop
will also apply to the client that our end users work with.

By utilising the current client it will also allow us to federate
mixed environment brokers C++ and Java as the Java broker doesn't yet
speak 0-10 to be compatible with the 0-10 C++ broker.

Thoughts


Martin
-- 
Martin Ritchie

Re: Broker Federation

[Ted Ross <tr...@redhat.com>]

Martin Ritchie wrote:
> On 29/04/2008, Ted Ross <tr...@redhat.com> wrote:
>   
>> Gordon Sim wrote:
>>
>>     
>>> Martin Ritchie wrote:
>>>
>>>       
>>>> Having read the page on how the C++ broker operates I'm not entirely
>>>> sure I follow how it works:
>>>> The qpid-route tool doesn't seem to have any authentication details
>>>>
>>>>         
>>> No, it doesn't yet handle configuration of authentication details for
>>>       
>> connections between brokers. That should be added soon I hope.
>>     
>>  I'm looking at this right now.
>>
>>  Rather than supply login credentials in the "connect" operation, I'm
>> leaning toward configuring each broker with a single identity that's used
>> for all inter-broker authentication.  This way we could use more
>> sophisticated mechanisms like X.509 certs or Kerberos principals.
>>
>>  Role-based access policy could then be used to determine which management
>> users are permitted to manipulate federation links.
>>     
>
> Does the C++ broker's SASL support x.509 certs / Kerberos or is this
> something else that needs to be added?
The C++ broker uses the CMU Cyrus SASL library so it should be able to 
support pretty much any SASL-compatible security mechanism.  The clients 
currently only support ANONYMOUS and PLAIN, this is work that needs to 
be done.
> It would be good to make the two brokers interoperate here.
Agree.
> Do you have JIRAs/Designs for all the pieces of work that you are doing here?
>   
No, but I will be happy to submit a Jira for each proposed piece of work.
> Have you thought about how/if ACLs on Broker A would be propagated to
> Broker B? Is this sort of common configuration something that should
> be done manually rather than enforcing it via the software?
>   
To be clear, I have no plans to do any access-control work in the 
immediate future.  Perhaps some jiras should be raised to get the 
access-control discussions going.  I'll be happy to contribute here.
> Cheers
>
> Martin
>   

Re: Broker Federation

[Martin Ritchie <ri...@apache.org>]

On 29/04/2008, Ted Ross <tr...@redhat.com> wrote:
> Gordon Sim wrote:
>
> > Martin Ritchie wrote:
> >
> > > Having read the page on how the C++ broker operates I'm not entirely
> > > sure I follow how it works:
> > > The qpid-route tool doesn't seem to have any authentication details
> > >
> >
> > No, it doesn't yet handle configuration of authentication details for
> connections between brokers. That should be added soon I hope.
> >
>  I'm looking at this right now.
>
>  Rather than supply login credentials in the "connect" operation, I'm
> leaning toward configuring each broker with a single identity that's used
> for all inter-broker authentication.  This way we could use more
> sophisticated mechanisms like X.509 certs or Kerberos principals.
>
>  Role-based access policy could then be used to determine which management
> users are permitted to manipulate federation links.

Does the C++ broker's SASL support x.509 certs / Kerberos or is this
something else that needs to be added? It would be good to make the
the two brokers interoperate here. Do you have JIRAs/Designs for all
the pieces of work that you are doing here?

Have you thought about how/if ACLs on Broker A would be propagated to
Broker B? Is this sort of common configuration something that should
be done manually rather than enforcing it via the software?

Cheers

Martin

>  -Ted
>
>


-- 
Martin Ritchie

Re: Broker Federation

[Ted Ross <tr...@redhat.com>]

Gordon Sim wrote:
> Martin Ritchie wrote:
>> Having read the page on how the C++ broker operates I'm not entirely
>> sure I follow how it works:
>> The qpid-route tool doesn't seem to have any authentication details
>
> No, it doesn't yet handle configuration of authentication details for 
> connections between brokers. That should be added soon I hope.
I'm looking at this right now.

Rather than supply login credentials in the "connect" operation, I'm 
leaning toward configuring each broker with a single identity that's 
used for all inter-broker authentication.  This way we could use more 
sophisticated mechanisms like X.509 certs or Kerberos principals.

Role-based access policy could then be used to determine which 
management users are permitted to manipulate federation links.

-Ted

Re: Broker Federation

[Gordon Sim <gs...@redhat.com>]

Martin Ritchie wrote:
> I'm interested to see what everyone thinks. I know Gordon is working
> in this area on the C++ and it would be good to make any configuration
> for the C++ broker also work with the Java. In fact I was hoping to
> have very minimal configuration so users don't have to worry to much
> about configuration

Sound like a good idea. Let us know what you think the ideal 
configuration would be like and we can see how best to make c++ support 
the same thing (or as much of it as possible).

> Having read the page on how the C++ broker operates I'm not entirely
> sure I follow how it works:
> The qpid-route tool doesn't seem to have any authentication details

No, it doesn't yet handle configuration of authentication details for 
connections between brokers. That should be added soon I hope.

> nor does it seem to talk about the creation of the 'link's that the
> Federation design talks to. Is there a bit of information missing?

The qpid-route tool sets up the link and establishes a bridge over it. 
Its a convenience tool that attempts to simplify common tasks. You can 
get full control over links and bridges directly using the management CLI.