This will take care of padding when
padding is consistent across a range.
However, we still have a problem with a progression like:
01
02
...
98
099
100
Where numbers in the middle start getting padding unexpectedly without a leading digit.
Since the multi-iterator ambition is out,
ditch the expensive set wrangling step.
Now the procedure is:
-Suck nodes into groups, as possible
-Separately for groups and nodes:
-Sort the elements
-Chunk the elements based on 'non-numberical' situation matching
-analyze the iterators to apply [] to shorten the name
-Multi-iterator will cause a discontinuity, and a new ',' delimited name gets constructed
There's too many cases that can go wrong.
Note that with this lower ambition, it would be possible to
significantly streamline the implementation.
Notably, the 'find discontinuities' approach
was selected to *try* to
support multiple iterators,
but since that didn't pan out,
a more straightforward
numerical strategy can
be used from the onset.
If 123abc-abc123 were attempted, it would produce
a strange error
when it encounters a string compare to number.
Detect the scenario and treat it like similar situations.
It has been stated that no one would want to do this
on purpose, and thus it should reject. The rationale
being that if no one wants to do this, but did it
anyway, they presumably made a mistake.
So now such attempts will be blocked.
Keep the dead logic around for now
in case a future opinion changes things back.
Often, it's desired to target odd or even, provide custom increment/step syntax,
but only in the [] context.
Perhaps one day can add n1-n12:2 support, but for now, this is easier to handle.
By default, pyparsing consumes only as much of the
input as matches the grammar. Tell it to consume all
of the noderange and error if there's more string than
matches our grammar.
Expansion of a noderange containing a dynamic group
would erroneously make the dynamic members get promoted
to 'permament' members. Fix this by isolating the
change so that the underlying group config is not changed
just by adding in dynamic nodes.
When a noderange starts with '<' or '>', use the set of all nodes as basis for pagination.
Additionally, provide better feedback to client on noderange parsing issues. Also
implement natural sort in various places after doing it for the pagination.
Noderange syntax now has:
<number : skip first number of nodes matching noderange
>number: provide only number of nodes matching noderange
These operators are intended to be at the end of a noderange. For example:
n1-n8<4>3
That will skip n1-n4 and provide only 3 (n5, n6, n7)
+ operator generates an 'end node' from the nodename to the left
and adding the specified value to the number at the end. This is
as restrictive as the xCAT 2.x perl implementation to ensure best
compatibility.
Enhance noderange to implement:
attribute.name==value (also attribute.name=value) -- strict equality match
attribute.name=~value -- regular expression match
attribute.name!=value -- strict negative match
attribute.name!~value -- negative regular expression match
~nameexpression -- search by node name using regular expression
This also goes a step further by intelligently limiting searches when found to the right of @ or ,-.
On the plugin front, add a one-off description for the 'noderange' attribute.
For the other pieces, make noderange more like any 'extensible' string value
rather than making it special.
Make expansion of groups and rejection of unrecognized elements work.
Additionally, implement dynamic groups. A group may have a 'noderange'
attribute. In this case it is considered to have 'dynamic' members. This
only has meaning in noderange expansion, not in deriving configuration data.
This does not yet add the search by attribute value capabilities and still
doesn't do the pagination or + operators.
Implement [] and - and :. Actually do better than xCAT NodeRange.pm about
multiple numbers in the non-[] sequential range case. Still need to do the things
that requiring wiring up to a config manager (the atom verification as well as
=, =~, and [0] being ~ or / for regex names).
