Custom Query (138 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 138)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#27 fixed Ad RSpec: follow node/link/interface ID conventions ibaldin@renci.org ahelsing@bbn.com
Description

Per Tom Lehman's email, can you modify IDs for nodes, links, interfaces, and ports to match the conventions, and better support tools for interoperability?

b) The current format of a node, interface, and link component is:

node component_id="urn:publicid:IDN+geni-orca.renci.org+node+bbnNet.rdf#bbnNet/Domain/vlan" 
interface component_id="urn:publicid:IDN+geni-orca.renci.org+interface+bbnNet.rdf#BbnNet/IBM/G8052/TenGigabitEthernet/1/20/ethernet
link component_id=
    <interface_ref component_id="urn:publicid:IDN+geni-orca.renci.org+interface+bbnNet.rdf#BbnNet/IBM/G8052/TenGigabitEthernet/1/20/ethernet"/>
    <interface_ref component_id="urn:publicid:IDN+ion.internet2.edu+interface+rtr.newy:ae0"/>

The following adjustment would sync up with ProtoGENI practice better, and make it easier to correlate with stitching extension:

the basic rule is to construct the interface component_id by taking the node component_id portion after the "node+", and adding  ":anything-desired".  So a ":" demarc between the node and interface portions.  

Here is an example:

node component_id="urn:publicid:IDN+geni-orca.renci.org+node+bbnNet.rdf#bbnNet/Domain/vlan" 
interface component_id="urn:publicid:IDN+geni-orca.renci.org+interface+bbnNet.rdf#bbnNet/Domain/vlan:IBM/G8052/TenGigabitEthernet/1/20/ethernet
link component_id=
    <interface_ref component_id="urn:publicid:IDN+geni-orca.renci.org+interface+bbnNet.rdf#bbnNet/Domain/vlan:IBM/G8052/TenGigabitEthernet/1/20/ethernet"/>
    <interface_ref component_id="urn:publicid:IDN+ion.internet2.edu+interface+rtr.newy:ae0"/>

Would it be possible to use this format for all node, interface, and link component formations?
#28 fixed configure an always-on IP address for testing VLAN 1750 connectivity to the BBN ExoGENI rack somebody chaos@bbn.com
Description

Configure an IP address which can be used for testing connectivity to the BBN ExoGENI rack on shared OpenFlow-controlled VLAN 1750.

#29 fixed site admins have inconsistent privileges in nagios installations jonmills@renci.org chaos@bbn.com
Description

We attempted to access and view the following nagios installations:

using the following accounts:

  • chaos: a member of xoadmins (admin at all racks)
  • jbs: a member of bbnadmins (site admin at BBN)
  • cgolubit: a recently-created member of bbnadmins (site admin at BBN)

In testing these accounts, we see the following behavior which seems unexpected:

  1. When logged into the BBN rack, the cgolubit account sees the status "cgolubit (guest)", while the jbs account sees the status "jbs (admin)". I would expect those two accounts to have identical behavior.
  2. The service contact list for an arbitrary service contains chaos and jbs (as expected), but does not contain cgolubit. Therefore, if notifications were being sent, cgolubit would not receive them.
  3. The chaos account can login to the RENCI rack and gets status "chaos (admin)". The cgolubit account can login and gets status "cgolubit (user)". However, the jbs account cannot login, seeing the error:
    Your username (jbs) is listed more than once in multisite.mk.
    This is not allowed. Please check your config.
    

Nagios behavior for site admins should be consistent, and ideally should be populated automatically so that new site admins and new sites see reasonable behavior.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.