On 27/08/11 00:56, Pearl Liang via RT wrote:
Thank you. Please see below comment and questions:
------
> A couple of clarifications may help here:
> 1) The purpose of matahari is not to configure QMF/Qpid, but to
> configure the entire system. For example, starting and stopping
> network
> interfaces, services, virtual machines or entire boxes.
> 2) QMF does not run atop matahari. Matahari runs atop QMF, which
> itself
> runs atop Apache Qpid (which is the AMQP implementation).
>
> The reason for a separate port is that end users may want to run a
> vanilla AMQP service on their hosts which is logically separate from
> the
> matahari AMQP bus. We cannot force generic users of AMQP to have their
> services coexist with ours (for instance, they may require a different
> implementation of AMQP), so we request a separate port so that our
> specific usage of AMQP can remain logically separate.
Thanks for the clarification. My question; how often should IANA expect
such requests? Is a discovery mechanism in order in the baseline AMQP
protocol? If someone else comes out with some other function that runs
atop AMQP but needs a different implementation, are we going to see
another request?
I understand the desire to conserve port numbers, but I think that AMQP
might be something of a red herring here; we can't speak for everyone
else in the world who might someday create a service on top of it.
However, I imagine that people will continue to create new services just
as they always have, and that some of these new services will require
port number assignments, just as they always have. That these services,
to the extent possible, run on top of existing transport protocols
rather than inventing new, buggy and probably inflexible protocols would
seem to be a Good Thing.
A server configuration system is an entirely different *service* from an
Enterprise Service Bus message queue. Aside from performing entirely
different functions for (possibly) entirely different sets of users,
they have different configurations, security policies and QoS
requirements. The fact that the two can (at one level) share a common
message format is not the salient point.
For example there are, from my extremely cursory inspection, at least
around 40 ports assigned to applications that use HTTP as a transport.
Off the top of my head, IPP (RFC2910) is one example that actually has a
Well-Known port assigned. Since HTTP supports virtual servers, arbitrary
headers and, thanks to its stateless nature, reverse proxies, we may
conclude that the reason for these assignments is unrelated to any
technical deficiencies in the protocol.
The purpose of separate port assignments is presumably because it makes
no sense for a WWW server to need to know about and account for the
possible existence of an IPP server on the same box (or vice-versa). Nor
would it make sense for network equipment to be unable to distinguish
between them without doing deep packet inspection. Similar constraints
exist in the case of an ESB message queue server and a system
configuration/control application. Given the widespread deployment of
application-layer AMQP messaging in large-scale Enterprise applications,
a remote configuration tool for servers that prevents existing services
running unmodified would be entirely useless.
Also, there exist protocols to manage device configuration, such as
NETCONF[1]. Have you considered making use of it?
[1] RFC
6241<http://tools.ietf.org/html/rfc6241>
Netconf is designed for configuration of network switches/routers and is
structured to be isomorphic with a Cisco-style command line. The
following is from
http://www.netconfcentral.org/netconf_docs
It is designed to be a replacement for Command Line Interface (CLI)
based programmatic interfaces, such as Perl + Expect over Secure
Shell (SSH). The CLI is also used by humans, which increases the
complexity and reduces the predictability of the API for real
application usage.
NETCONF is usually transported over the SSH protocol, using the
'netconf' sub-system (similar to the 'sftp' sub-system). and in many
ways it mimics the native proprietary CLI over SSH interface
available in the device. However, it uses structured schema-driven
data, and provides detailed structured error return information,
which the CLI cannot provide.
This does not fit well with the goals of the Matahari project (arbitrary
configuration of general-purpose servers on multiple platforms).
Further, Apache Qpid was chosen because it provides a mature, stable
implementation of AMQP. There appear to be no Open implementations of
Netconf with a comparable level of maturity (YUMA was first released
only last year and appears to still be undergoing major changes).
regards,
Zane.