Weak regex for volume port Fact

[tux-o-matic]

The regex used to feed the volume port Fact can't always parse completely the output of the 'gluster volume status' command.
gluster.rb L 48

volume_ports[vol] = status.scan(/^Brick [^\t]+\t+(\d+)/).flatten.uniq.sort

I suspect that it might happen when the brick name is long enough to be formatted into two lines.

The end result is an empty Fact in Puppet

[skpy]

Can you provide an example brick name that isn't working correctly?

[tux-o-matic]

If I test with 'gluster volume status brick_name', the complete URL (FQDN and brick name) can in some of my environments be 55 characters long. That leads to a new line in the bash table format. If the Ruby code for the fact depends on the same formatting then the regex can't handle it.

[jyaworski]

@tux-o-matic could you give an example of it failing?

Also, this comes close to https://bugzilla.redhat.com/show_bug.cgi?id=1033369, although unrelated.

[tux-o-matic]

@jyaworski "close but unrelated", it's a bug like millions of others about string length, not even related to Gluster.

I'm not big on Ruby regex so it's hard for me to say how it could handle line return when a brick name is too long.
But if the brick name given to 'bricks' under 'gluster::volumes' uses the FQDN, then the rest of the path doesn't have to be that long to break the parsing.

Taking an example from RedHat's doc

# gluster volume status test-volume
Status of volume: test-volume
Gluster process                        Port    Online   Pid
------------------------------------------------------------
Brick arch:/export/rep1                24010   Y       18474
Brick arch:/export/rep2                24011   Y       18479
NFS Server on localhost                38467   Y       18486
Self-heal Daemon on localhost          N/A     Y       18491

Here you'll the brick URL fits nicely in one line, but add a longer path or a FQDN and the shell table will force a line return to respect the cell's character width.