Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

plugin options should be able to accept lists #3

Closed
jhjaggars opened this issue Jul 11, 2011 · 0 comments
Closed

plugin options should be able to accept lists #3

jhjaggars opened this issue Jul 11, 2011 · 0 comments
Assignees
@jhjaggars
Milestone
2.4

Comments

@jhjaggars
Copy link
Contributor

Options passed to plugins are parsed by the wrong option parser. Therefore lists of option parameters such as --myplugin.list_opt=foo,bar,baz will result in only "foo" being available.

Using the "append" option parser should fix this.
@ghost ghost assigned jhjaggars Jul 11, 2011
@ankitkumar2391 ankitkumar2391 mentioned this issue Jul 3, 2017
Closed
bmr-cymru added a commit that referenced this issue Jun 19, 2018
@bmr-cymru
[sosreport] use private plugin list for ThreadPoolExecutor
ab15a0f 
In some cases the concurrent plugins patch will produce output
like the following (with a starting set of plugins of [activemq,
apache, dbus, dhcp, manageiq, openshift, openstack_swift,
puppet]:

  Starting 1/8   activemq        [Running: activemq]
  Starting 2/8   apache          [Running: apache]
  Starting 4/8   dhcp            [Running: apache dhcp]
  Starting 5/8   manageiq        [Running: apache dhcp manageiq]
  Starting 6/8   openshift       [Running: apache openshift]
  Starting 7/8   openstack_swift [Running: apache openshift openstack_swift]
  Starting 8/8   puppet          [Running: apache openshift puppet]

Plugin #3 on the list (dbus) has vanished from the plugin run
list.

The ThreadPoolExecutor class uses itertools.izip() to walk the
passed iterable of arguments. Since this references the same
SoSReport.pluglist list that is being concurrently modified by
the collect_plugin() methods it is possible for the pool iterator
to "lose" an entry (another entry is removed by during the call to
its collect_plugin() method, causing the list indices to shift,
and making the index used in the next iteration of the pool's
map() submission loop point one past the correct next entry.

Avoid this problem by initialising a fresh copy of the pluglist
to pass into the pool.

Signed-off-by: Bryn M. Reeves <bmr@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jhjaggars jhjaggars

Labels
None yet
Projects
None yet
Milestone
2.4
Development

No branches or pull requests
1 participant
@jhjaggars