Hey Jakub,
yeah I was going to mention the --argument approach myself, but that
wasn't *really* the thrust of my argument, there are a whole bunch of
things that have had a lot of really good work put in to them, but
precisely zero documentation. it seems such a shame to me. Qpid is a
great project, but there isn't such a strong culture of documenting
things, which I personally feel sells the project rather short. Now if
you have the time and energy to follow the mailing list, jira, source
code then you might stand a fighting chance and lord knows I've reverse
engineered a few things myself, but I'm afraid a few things have started
to push my buttons recently, so I felt it was worth making a stand with
my "users" hat on :-)
Just because it's *technically* possible for you and I and a few others
to work around this by being creative with --arguments doesn't mean that
we shouldn't have some due process to formally deprecate features that
we'd like to remove and *document* the alternatives.
"But any scripts using the old parameters will need to be modified. " is
precisely my point, there's likely to be quite a few people faced with
"imagine my surprise when......"
I don't actually have an issue with "The best would be to use only the
--argument options for everything " if it was proposed on the user list,
voted on and deprecated over a couple of releases. It's more the
"surprise" effect of changing things in a breaking way without giving
sufficient notice that I have the real issue with (and did I mention
documentation :-)
Frase
On 11/04/14 22:38, Jakub Scholz wrote:
I believe you will still be able to use them through the --argument option,
which allows you to to define whatever parameter, or? But any scripts using
the old parameters will need to be modified.
The qpid-config tool has a bit strange interface, as some of the options
are accessible directly and some require the use of the --argument option.
The best would be to use only the --argument options for everything, as
that seems to allow quite a lot of flexibility for configuring objects and
properties the qpid-config it self has no idea about.
Jakub
On Fri, Apr 11, 2014 at 7:37 PM, Justin Ross <[email protected]> wrote:
Fraser, you're right. I think this request is just going to the wrong
place. This change cannot go to trunk until the legacystore is deprecated
and then removed. Even then, it may be worth keeping the options around in
a less visible fashion to support deployments with the older store.
On Fri, Apr 11, 2014 at 1:29 PM, Fraser Adams <
[email protected]
wrote:
OK so I'm going to bite.
is legacystore as its name suggests going to be deprecated? At the moment
there seems to be two stores, neither of which seem to have any
documentation that a user might reasonably use in order to figure out how
on earth to get persistence to work with qpidd. Well that was the case a
few weeks ago when I last looked, if it has improved then I apologise for
the rant :-)
I'd personally prefer holding fire on removing things from qpid-config
and
invest the energy in getting the documentation for qpidd persistence
into a
decent state (including something on the whys and wherefores of
legacystore
and linearstore).
Moreover removing these options will instantly prevent this and
subsequent
versions of qpid-config from being able to control these parameters on an
older broker (have you considered use cases where users have a mixed
economy of brokers? that's pretty common in my experience).
I personally think it's a bit unfriendly to be removing features without
providing a deprecation notice (and the intention of this work should
have
been posted on to the user list). I might have missed it but I don't
recall
seeing anything about this on the user list or on a Jira?
Sorry if this seems a bit shirty :-) for context I have a very large
federated system and generally there are a couple of different versions
despite my best intentions, I've been bitten in the past by qpid-config
changes.
I don't generally use persistence with qpidd myself, so parochially I'm
not affected, but I do think that there's a principal here with respect
to
the wider community.
Regards,
Frase
On 11/04/14 17:36, Ernie Allen wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20262/
-----------------------------------------------------------
Review request for qpid, Gordon Sim and Ted Ross.
Repository: qpid
Description
-------
Remove the two parameters --file-size and --file-count from qpid-config
Currently, qpid-config allows specifying qpid.file_count and
qpid.file_size queue declare options, via --file-count / --file-size
command line options. These options become obsolete in 3.0 due to
linearstore, that does not offer/require similar parameters.
Removing refereces to file-size / file-count in the broker will be in a
separate patch.
Diffs
-----
/trunk/qpid/tools/src/py/qpid-config 1586666
Diff: https://reviews.apache.org/r/20262/diff/
Testing
-------
qpid-config --help | grep file-
<no output>
Thanks,
Ernie Allen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
