OpenNMS

The provisioning GUI in the webapp presents the wrong services to add to an interface when creating requisitions

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Duplicate
  • Affects Version/s: 1.10.0
  • Fix Version/s: 1.10.1
  • Component/s: Web UI - Admin
  • Security Level: Default (Default Security Scheme)
  • Labels:

Description

When creating a new requisition under Admin/Manage Provisioning Requisitions, then the services pulldown on the interface components displays the wrong list of services.

The list currently only displays the services defined in the same provisioning requisitions foregin source's list of defined services. This pulldown should display the larger list of services defined globally, or it would not be possible to add a specific service to a specific node, without the general scanning at import time trying to add it to all nodes in the requisition.

Adding the service specifically by editing the XML works fine.

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. NMS-5178 Unable to manually provision service via GUI without first defining detector

  • Blocker - Blocks development and/or testing work, production could not run.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Bug - A problem which impairs or prevents the functions of the product. NMS-5218 Adding a self defined service in provision group is not working.

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jeff Gehlbach added a comment -

Demoting to Major since multiple workarounds exist. It's working as designed, and the design seemed like a good idea, but now that people are beginning to use it I'm seeing that we failed to think all the way through the problem

Show
Jeff Gehlbach added a comment - Demoting to Major since multiple workarounds exist. It's working as designed, and the design seemed like a good idea, but now that people are beginning to use it I'm seeing that we failed to think all the way through the problem
Hide
Permalink
Alexander Hoogerhuis added a comment -

Ah, no. The baviour was different in late 1.8 and up to some point in 1.9.x as far as I can tell. The pulldown would give the full list of defined services. This is something that has changed somewhat recently.

Show
Alexander Hoogerhuis added a comment - Ah, no. The baviour was different in late 1.8 and up to some point in 1.9.x as far as I can tell. The pulldown would give the full list of defined services. This is something that has changed somewhat recently.
Hide
Permalink
Ronny Trommer added a comment - - edited

I'm stumbled also over this issue. The 1.10 use-case seems to be:

You can assign a service manually just if you've a detector for it.

So the simple-WebUI-only workflow is. Go to the foreign-source definition and create a detector with the name you want. Don't care about the implementing class - it doesn't matter. Go back to the node, assign your service do NOT synchronize and go back to the foreign-source definition and delete it, then synchronize - so easy

From my personal point of view it could be easier if we can select from all services we already have. Most of the time the user wants to assign a service if detection isn't possible or not necessary.

If you want more flexibility, we could kick out the drop down field and replace it with an autocompletion textfield.

Just my 2 cents

Show
Ronny Trommer added a comment - - edited I'm stumbled also over this issue. The 1.10 use-case seems to be: You can assign a service manually just if you've a detector for it. So the simple-WebUI-only workflow is. Go to the foreign-source definition and create a detector with the name you want. Don't care about the implementing class - it doesn't matter. Go back to the node, assign your service do NOT synchronize and go back to the foreign-source definition and delete it, then synchronize - so easy From my personal point of view it could be easier if we can select from all services we already have. Most of the time the user wants to assign a service if detection isn't possible or not necessary. If you want more flexibility, we could kick out the drop down field and replace it with an autocompletion textfield. Just my 2 cents
Hide
Permalink
zhangzhijun added a comment -

Yes, i totally agree with Alexander Hoogerhuis. I met the same issue when selecting the self-defined services in drop-down list of services. it is working as well in 1.8.x release. It is a very important feature for self-defined service which is the entry of rrd graph.

Show
zhangzhijun added a comment - Yes, i totally agree with Alexander Hoogerhuis. I met the same issue when selecting the self-defined services in drop-down list of services. it is working as well in 1.8.x release. It is a very important feature for self-defined service which is the entry of rrd graph.
Hide
Permalink
Benjamin Reed added a comment -

duplicate of NMS-5178

Show
Benjamin Reed added a comment - duplicate of NMS-5178

People

  • Assignee:
    Seth Leger
    Reporter:
    Alexander Hoogerhuis
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: