Opened 12 years ago
Last modified 12 years ago
#845 new
improve the GMOC SNAPP, Portal, and protected UI interfaces to meet current experimenter needs
| Reported by: | chaos@bbn.com | Owned by: | mrmccrac@grnoc.iu.edu |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | GMOC | Version: | SPIRAL4 |
| Keywords: | Cc: | sedwards@bbn.com | |
| Dependencies: |
Description
Make improvements to the GMOC SNAPP user interface to support current use cases for mesoscale operators and experimenters.
Change History (5)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Update to status based on 2012-01-03 meeting between Mitch McCracken of GMOC, Sarah Edwards of GPO, and Chaos Golubitsky of GPO.
Action items
Status symbols:
| Color | Meaning |
| Color(green,green)? | This item is done to everyone's satisfaction. |
| Color(gold,gold)? | The next action on this item has been assigned to a particular person who is working on it. |
| Color(orange,orange)? | This item is blocked pending another item, which is still in progress. |
| Color(red,red)? | The next action on this item is unassigned or unknown. We should figure it out at the next call. |
1. Improve reliability of data submission and of the database
1a. Investigate reliability issues as they arise
No next action (wait for something to go wrong).
1b. data submission server should reject submissions with unreasonable timestamps
Status: Camilo configured gmoc-db to reject data whose reported current timestamp is more than 5 minutes off. We're going to run like that for a few weeks, and, if things look good, start rejecting data whose reported current timestamp is more than 45 seconds off.
Next action: Color(red,TBD)? We should revisit at the next meeting whether it is reasonable to tighten the accuracy gap at which data is rejected.
2. Make the pages concise and friendly for new users
This is GRNOC ticket 3039.
2a. Make the portal UI more concise and friendly
Next action is probably for someone to make a concrete list of changes to the portal UI for the function we all now understand it to have. Color(orange,Blocked on 2b.)? We will revisit this once we're done with item 2b.
2b. Improve the protected web UI to be more useful for experimenters
Next action: Color(red,TBD)? Iterate about next actions at a future meeting.
3. Write documentation of portal and search functions which is accessible to nonexperts
This is GRNOC ticket 3040.
3a. descriptions of submitted stats
Next action: Color(gold,Sarah)? will mock up a wiki page for this
3b. brief overviews of how to use pages
Task: "how to use the portal"/"how to use SNAPP"/"how to use protected data UI" brief overviews
Next action: Color(orange,Blocked on 2.)? This will want to wait on other changes.
4. Portal should support a list of aggregates which have reported recently
Use case: an experimenter or operator wants to see a simple overview of which aggregates are currently reporting data, in order to see what aggregates are available or to detect a monitoring outage. (This could be an "index" or "status" tab of the portal, showing a list of sites/hosts which are currently reporting, and possibly also hosts which had been reporting until recently but have now stopped.)
Next action: Color(red,TBD)? Discuss at a future meeting whether Mitch can set this up. Is there a GRNOC ticket?
5. Flexibly handle complex datagroup names in display
This is GRNOC ticket 3041.
Task: flexibly handle datagroup names which contain multiple pieces of information, in both data selection and data display. (Note: this is the problem we started defining on jabber last week. The solution may involve using tags for what we believe they were originally intended for, or may involve submission of relational data.)
Next action: Color(gold,Mitch)? will look at the existing data in GMOC's database and report on what if anything needs to change from a submission standpoint to make this easy to do.
6. Support FOAM sliver name mappings
This is GRNOC ticket 3042.
Use case: i am looking at a FOAM-controlled flowvisor (e.g. tulum.gpolab.bbn.com). I want to see all slivers active on that flowvisor, identified by GENI slice name. (Note: This use case combines fv_slice_status data for the flowvisor slice to get stats, with foam_sliver_status data for the FOAM sliver to get the FV slice to GENI slice name mapping. It requires the equivalent of a database JOIN, which we don't think can be supported in the general case (though we'll ask), but we think is needed for the specific case of monitoring FOAM-controlled flowvisors, which is a critical case in the mesoscale right now.)
6a. Refactor FOAM monitoring to contain better support for sliver name mappings
Next action: Color(gold,Chaos)? will refactor the FOAM monitoring code to get all relevant data from FOAM and the flowvisor known to FOAM, and report it all as foam_ variables. The datagroup will be named after the FOAM sliver urn, and will have tags for any other relational data we want to pass along.
6b. Expand database handling of long fields to support FOAM slivers and other uses
- Instead of the datagroup and tag fields being limited to 255 chars each in GMOC's SQL database, they should be larger, more like 1024 chars so we are unlikely to run into length limit problems again for some time.
- When submitters overflow these fields, the server should handle the attempt gracefully.
- The badly-formed data currently in gmoc-db for the gpolab site should be cleaned out.
Next action: Color(gold,Mitch)? will make these changes.
7. Support plnode sliver data overlay graph use case
This is GRNOC ticket 3043.
Use case: i am looking at a plnode (e.g. bain.gpolab.bbn.com). I want to see a graph containing tx_bytes (an element of plnode_sliver_network) for each sliver on the plnode, identified by sliver name. (Note: this may involve using tags to choose arbitrary data to display on one line graph.)
We think we are very close to being able to do this using the "Overlay" graph option from SNAPP searches.
Next action: Color(red,TBD)?: Discuss at the next meeting:
- Camilo configured the database to expire any data groups which have not reported recently. We should make sure we have a record of what value is being used for "recently", and that it is a good value.
- Configure the overlay graph option to sort data groups in the legend by the magnitude of each data_group's contributed value to the data.
8. Support GENI slice status page or search
Use case: i am interested in a GENI slice (e.g. urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+arosenOFslice). I want to see PLC and FOAM aggregates (including plnode and FV data) for everything relevant to this slice, in a reasonably viewable fashion.
Next action: Color(red,TBD)?: Camilo has added statistics to the per-slice protected UI. We should look at that and see where we are.
9. Setup/improve test and software release infrastructure for gmoc-db submission
This item is for miscellaneous tasks related to making sure there is a good test and release infrastructure in place for data submission software. Deprecating the GPO /tango pages in favor of GMOC pages does not depend on the completion of this item.
9a. Configure a cross-site staging environment for data submission
GMOC should maintain a staging host for use in API and UI development work. GPO should submit live data from staging or dedicated-to-monitoring gpolab hosts, to the GMOC staging host.
Next action: Color(gold,Mitch)? will verify the state of the gmoc-db2 site, and then ask Chaos to migrate hosts to it.
9b. Find a good way to distribute data submission software
GPO now has RPM and debian packages for monitoring each of a number of aggregates used in the early mesoscale (PlasticSlices/MonitoringRecommendations). Determine how GMOC's measurement_sender script should be integrated into these packages so sites don't have to obtain measurement_sender by hand to install the software.
Next action:
- Color(gold,Mitch)? will investigate options for hosting packages at GMOC.
- Color(gold,Chaos)? will raise the question of whether any of this code is of interest for GENI rack vendors and should be packaged with that in mind, at the next monitoring meeting.
9c. Evaluate the GPO-sourced tango-monitor RPMs for IU use
Next action: Color(gold,Mitch)? will look at the GPO's tango-monitor-myplc RPM and assess what changes IU would need in order to use this RPM on their systems and in the core.
10. Evaluate the mechanism for authorized data submission from sites
The current process for submitting site authorization credentials is documented for site operators at GENIMetaOps/SiteCredentials. This process should be updated, and we should evaluate whether it is scalable for GENI racks which might use the data submission API.
Next action: Color(gold,Mitch)? will propose an approach at the next meeting.
comment:3 Changed 12 years ago by
Update to status based on 2012-01-17 meeting between Mitch McCracken of GMOC, Sarah Edwards of GPO, and Chaos Golubitsky of GPO.
Action items
Status symbols:
| Color | Meaning |
| Color(green,green)? | This item is done to everyone's satisfaction. |
| Color(gold,gold)? | The next action on this item has been assigned to a particular person who is working on it. |
| Color(orange,orange)? | This item is blocked pending another item, which is still in progress. |
| Color(red,red)? | The next action on this item is unassigned or unknown. We should figure it out at the next call. |
1. Improve reliability of data submission and of the database
1a. Investigate reliability issues as they arise
No next action (wait for something to go wrong).
1b. data submission server should reject submissions with unreasonable timestamps
Status: Camilo configured gmoc-db to reject data whose reported current timestamp is more than 5 minutes off. We're going to run like that for a few weeks, and, if things look good, start rejecting data whose reported current timestamp is more than 45 seconds off.
Next action: Color(gold,Mitch)? will investigate the current code, make sure he knows how to tighten this threshold, and make sure he doesn't want to make any other changes.
2. Make the pages concise and friendly for new users
This is GRNOC ticket 3039.
2a. Make the portal UI more concise and friendly
Next action is probably for someone to make a concrete list of changes to the portal UI for the function we all now understand it to have. Color(orange,Blocked on 2b.)? We will revisit this once we're done with item 2b.
2b. Improve the protected web UI to be more useful for experimenters
GPO will probably drive what we want this UI to look like, though we will all discuss it.
Next action: Color(red,TBD)? Iterate about next actions at a future meeting.
3. Write documentation of portal and search functions which is accessible to nonexperts
This is GRNOC ticket 3040.
3a. descriptions of submitted stats
We discussed whether there should be standardization of naming of stats across aggregates. Mitch does not believe GMOC has written a document laying this out, so GPO should work on that.
Next actions:
- Color(gold,Sarah)? will mock up a wiki page for the existing stats
- Color(gold,Mitch)? will verify whether GMOC has written a standard in the past
- Color(gold,Chaos and Sarah)? will mock up a general proposal for a standard
3b. brief overviews of how to use pages
Task: "how to use the portal"/"how to use SNAPP"/"how to use protected data UI" brief overviews
Next action: Color(orange,Blocked on 2.)? This will want to wait on other changes.
4. Portal should support a list of aggregates which have reported recently
Use case: an experimenter or operator wants to see a simple overview of which aggregates are currently reporting data, in order to see what aggregates are available or to detect a monitoring outage. (This could be an "index" or "status" tab of the portal, showing a list of sites/hosts which are currently reporting, and possibly also hosts which had been reporting until recently but have now stopped.)
Next action: Color(gold,Mitch)? will make a ticket and work on creating this listing.
5. Flexibly handle complex datagroup names in display
This is GRNOC ticket 3041.
Task: flexibly handle datagroup names which contain multiple pieces of information, in both data selection and data display. (Note: this is the problem we started defining on jabber last week. The solution may involve using tags for what we believe they were originally intended for, or may involve submission of relational data.)
Next action: Color(gold,Mitch)? will look at the existing data in GMOC's database and report on what if anything needs to change from a submission standpoint to make this easy to do.
6. Support FOAM sliver name mappings
This is GRNOC ticket 3042.
Use case: i am looking at a FOAM-controlled flowvisor (e.g. tulum.gpolab.bbn.com). I want to see all slivers active on that flowvisor, identified by GENI slice name. (Note: This use case combines fv_slice_status data for the flowvisor slice to get stats, with foam_sliver_status data for the FOAM sliver to get the FV slice to GENI slice name mapping. It requires the equivalent of a database JOIN, which we don't think can be supported in the general case (though we'll ask), but we think is needed for the specific case of monitoring FOAM-controlled flowvisors, which is a critical case in the mesoscale right now.)
6a. Refactor FOAM monitoring to contain better support for sliver name mappings
Next action: Color(gold,Chaos)? will refactor the FOAM monitoring code to get all relevant data from FOAM and the flowvisor known to FOAM, and report it all as foam_ variables. The datagroup will be named after the FOAM sliver urn, and will have tags for any other relational data we want to pass along.
6b. Expand database handling of long fields to support FOAM slivers and other uses
- Instead of the datagroup and tag fields being limited to 255 chars each in GMOC's SQL database, they should be larger, more like 1024 chars so we are unlikely to run into length limit problems again for some time.
- When submitters overflow these fields, the server should handle the attempt gracefully.
- The badly-formed data currently in gmoc-db for the gpolab site should be cleaned out.
Next action: Color(gold,Mitch)? will make these changes, but may need to iterate with Chaos on the third item.
7. Support plnode sliver data overlay graph use case
This is GRNOC ticket 3043.
Use case: i am looking at a plnode (e.g. bain.gpolab.bbn.com). I want to see a graph containing tx_bytes (an element of plnode_sliver_network) for each sliver on the plnode, identified by sliver name. (Note: this may involve using tags to choose arbitrary data to display on one line graph.)
We think we are very close to being able to do this using the "Overlay" graph option from SNAPP searches.
Next actions:
- Color(gold,Mitch)? will double-check and make sure we have a record of the threshold for expiring old data from SNAPP (he thinks its 30 days).
- Color(gold,Mitch)? will configure the overlay graph option to sort data groups in the legend by the magnitude of each data_group's contributed value to the data.
8. Support GENI slice status page or search
Use case: i am interested in a GENI slice (e.g. urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+arosenOFslice). I want to see PLC and FOAM aggregates (including plnode and FV data) for everything relevant to this slice, in a reasonably viewable fashion.
Next action: Color(red,TBD)?: Camilo has added statistics to the per-slice protected UI. We should look at that and see where we are.
9. Setup/improve test and software release infrastructure for gmoc-db submission
This item is for miscellaneous tasks related to making sure there is a good test and release infrastructure in place for data submission software. Deprecating the GPO /tango pages in favor of GMOC pages does not depend on the completion of this item.
9a. Configure a cross-site staging environment for data submission
GMOC should maintain a staging host for use in API and UI development work. GPO should submit live data from staging or dedicated-to-monitoring gpolab hosts, to the GMOC staging host.
Chaos tried to use the staging site this morning on gpolab host tau-verde, and got a 500 error.
Next action:
- Color(gold,Mitch)? will debug the submission problems to gmoc-db2, working with Chaos.
9b. Find a good way to distribute data submission software
GPO now has RPM and debian packages for monitoring each of a number of aggregates used in the early mesoscale (PlasticSlices/MonitoringRecommendations). Determine how GMOC's measurement_sender script should be integrated into these packages so sites don't have to obtain measurement_sender by hand to install the software.
Mitch has learned that GMOC is willing to host static files related to monitoring, but does not want to host an RPM or Debian package repository. Chaos has learned that GPO can include measurement_sender in our package, but we need to deal with the legal details of exactly how to do this.
Next action:
- Color(gold,Chaos)? will figure out what we need to do legally in order to include measurement_sender in our package.
- Color(gold,Mitch)? will create a web directory for hosting files.
- Color(gold,Chaos)? will raise the question of whether any of this code is of interest for GENI rack vendors and should be packaged with that in mind, at the next monitoring meeting. (This didn't happen, and perhaps should happen at the next monitoring call.)
9c. Evaluate the GPO-sourced tango-monitor RPMs for IU use
Mitch looked at the GPO's tango-monitor-myplc RPM to assess what changes IU would need in order to use this RPM on their systems and in the core. He thinks the RPM is fine as is. GMOC needs to sign RPMs in order to use them, but they would need to sign with their own key even if we also signed the RPM, so Mitch doesn't believe that matters. He thinks our RPM is fine for IU use.
10. Evaluate the mechanism for authorized data submission from sites
The current process for submitting site authorization credentials is documented for site operators at GENIMetaOps/SiteCredentials. This process should be updated, and we should evaluate whether it is scalable for GENI racks which might use the data submission API.
Mitch changed GENIMetaOps/SiteCredentials to placeholder text. He is continuing to work with GMOC on defining a good approach.
Next action: Color(gold,Mitch)? will propose an approach at the next meeting.
11. Submission of relational and event data using the GMOC API
Currently, the GMOC API should have provisions for using it to submit relational data to the GMOC database. As of now, we do not know if the code is ready to use, and there are not any helper scripts to use with it. In addition, we think the code expects that the full set of relations for a given site (or a given host? or the entire world?) will be submitted every time that site submits data.
We have the following questions about recommending this for use (and perhaps migrating some of the tango-monitor code to use it where appropriate):
- Color(gold,Mitch)? will investigate how ORCA data is currently being collected, and will send a URL if he can.
- Does it make sense to submit all data for a given site every time you submit data?
- Chaos argues that collecting data and submitting all data for a host at a fixed interval, would be similar to how hosts are handling time-series data submission.
- Sarah argues that partial submission would be preferred.
- Mitch is concerned about submitting data per host rather than per-aggregate (or per-site), because of fears that it will be unclear who owns a particular piece of data. Color(gold,Mitch)? will investigate whether the current expectation is that all data will be resubmitted per host or per-site or per-aggregate or what.
- If data is to be collected and submitted in bulk, what is the local data storage format for the data which will be submitted? (This is analogous to how RRD is the local data storage format for time-series data, but RRD seems like a much more obvious choice than anything we've thought of in the relational data realm.)
- If the relations table is used for event data too, then events will expire when new data is submitted. We presumably want GMOC to keep old events when new data is received, the same way it keeps old time-series data when new data is received.
- Color(gold,Sarah)? will schedule a call to discuss this topic in more detail.
comment:4 Changed 12 years ago by
Update to status based on 2012-01-31 meeting between Mitch McCracken of GMOC, Sarah Edwards of GPO, and Chaos Golubitsky of GPO. (Sorry this update is late.)
Action items
Status symbols:
| Color | Meaning |
| Color(green,green)? | This item is done to everyone's satisfaction. |
| Color(gold,gold)? | The next action on this item has been assigned to a particular person who is working on it. |
| Color(orange,orange)? | This item is blocked pending another item, which is still in progress. |
| Color(red,red)? | The next action on this item is unassigned or unknown. We should figure it out at the next call. |
1. Improve reliability of data submission and of the database
1a. Investigate reliability issues as they arise
No next action (wait for something to go wrong).
1b. data submission server should reject submissions with unreasonable timestamps
Status: Color(green,DONE)?: Camilo configured gmoc-db to reject data whose reported current timestamp is more than 5 minutes off. We ran with that for awhile, and then Mitch tightened the threshold to 45 seconds. I believe the tighter threshold caught one more aggregate which had previously been reporting, and i'm working with that AM owner to fix their clock.
The GRNOC ticket for tightening the threshold is 3214.
2. Make the pages concise and friendly for new users
This is GRNOC ticket 3039.
Status: Deferred. We agreed at the 2012-01-31 meeting to defer this until later, since we don't have exact steps defined which should be taken.
3. Write documentation of portal and search functions which is accessible to nonexperts
3a. descriptions of submitted stats
We discussed whether there should be standardization of naming of stats across aggregates. Mitch does not believe GMOC has written a document laying this out, so GPO should work on that.
Next actions:
- Color(gold,Sarah)? will mock up a wiki page for the existing stats
- Color(gold,Chaos and Sarah)? will mock up a general proposal for a standard
3b. brief overviews of how to use pages
This is GRNOC ticket 3040.
Task: "how to use the portal"/"how to use SNAPP"/"how to use protected data UI" brief overviews
Next action: Color(gold,Mitch)? will draft a brief document on the GENI wiki linking to the experimenter portal, the campus portal, the SNAPP UI, and information about how to access the experimenter portal using openid.
4. Portal should support a list of aggregates which have reported recently
This is GRNOC ticket 3219.
Use case: an experimenter or operator wants to see a simple overview of which aggregates are currently reporting data, in order to see what aggregates are available or to detect a monitoring outage. (This could be an "index" or "status" tab of the portal, showing a list of sites/hosts which are currently reporting, and possibly also hosts which had been reporting until recently but have now stopped.)
Next action: Color(gold,Mitch)? will work on this when time permits. No target date yet.
5. Flexibly handle complex datagroup names in display
This is GRNOC ticket 3041.
Task: flexibly handle datagroup names which contain multiple pieces of information, in both data selection and data display. (Note: this is the problem we started defining on jabber last week. The solution may involve using tags for what we believe they were originally intended for, or may involve submission of relational data.)
Next action: This item is Color(orange,blocked)? on item 11, to get relational data submission working.
6. Support FOAM sliver name mappings
This is GRNOC ticket 3042.
Use case: i am looking at a FOAM-controlled flowvisor (e.g. tulum.gpolab.bbn.com). I want to see all slivers active on that flowvisor, identified by GENI slice name. (Note: This use case combines fv_slice_status data for the flowvisor slice to get stats, with foam_sliver_status data for the FOAM sliver to get the FV slice to GENI slice name mapping. It requires the equivalent of a database JOIN, which we don't think can be supported in the general case (though we'll ask), but we think is needed for the specific case of monitoring FOAM-controlled flowvisors, which is a critical case in the mesoscale right now.)
6a. Refactor FOAM monitoring to contain better support for sliver name mappings
Status: Chaos refactored the FOAM monitoring code to get all relevant data from FOAM and the flowvisor known to FOAM.
Next action: Color(gold,Chaos)? will refactor the FOAM monitoring code to report all FOAM info as foam_ variables. The datagroup will be named after the FOAM sliver urn. We will try to use relational data submission to deal with relational data, and eventually take advantage of that here.
6b. Expand database handling of long fields to support FOAM slivers and other uses
- Instead of the datagroup and tag fields being limited to 255 chars each in GMOC's SQL database, they should be larger, more like 1024 chars so we are unlikely to run into length limit problems again for some time: Color(green,done)?: Mitch increased the length limits to 512 characters, the longest which is likely to be available for awhile.
- The badly-formed data currently in gmoc-db for the gpolab site should be cleaned out: Color(green,done)?
- When submitters overflow these fields, the server should handle the attempt gracefully.
Next action: Color(gold,Mitch)? will modify the code so that submissions of too-long data are handled gracefully, but there is not a target date.
7. Support plnode sliver data overlay graph use case
This is GRNOC ticket 3043.
Use case: i am looking at a plnode (e.g. bain.gpolab.bbn.com). I want to see a graph containing tx_bytes (an element of plnode_sliver_network) for each sliver on the plnode, identified by sliver name. (Note: this may involve using tags to choose arbitrary data to display on one line graph.)
Status:
- We think we are very close to being able to do this using the "Overlay" graph option from SNAPP searches.
- In the 2012-01-31 meeting, we agreed that "expire old data from SNAPP after 30 days" is not what we want to do. Eventually, we will need an option to limit SNAPP views by whether there is active data during the time period, or we'll be overwhelmed by e.g. a listing of all slivers which have ever existed on an aggregate. However, for this particular use case in the short term, sorting the data will be sufficient.
- Color(gold,Mitch)? will configure the overlay graph option to sort data groups in the legend by the magnitude of each data_group's contributed value to the data. This is GRNOC ticket 3221.)
8. Support GENI slice status page or search
Use case: i am interested in a GENI slice (e.g. urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+arosenOFslice). I want to see PLC and FOAM aggregates (including plnode and FV data) for everything relevant to this slice, in a reasonably viewable fashion.
Status: As of 2012-01-31, we think most of this is there in the experimenter portal, except that data submission is guessing slice URNs rather than having them provided. When submitters are providing slice URNs, that should take care of this.
Next action: Color(orange,blocked)?: This will wait on some of the relational data work to clean up slice URN submission.
9. Setup/improve test and software release infrastructure for gmoc-db submission
This item is for miscellaneous tasks related to making sure there is a good test and release infrastructure in place for data submission software. Deprecating the GPO /tango pages in favor of GMOC pages does not depend on the completion of this item.
9a. Configure a cross-site staging environment for data submission
GMOC should maintain a staging host for use in API and UI development work. GPO should submit live data from staging or dedicated-to-monitoring gpolab hosts, to the GMOC staging host.
Status:
- Submission and retrieval are done: Three GPO hosts are submitting data to the staging host, GPO's server is retrieving that data again, and GPO nagios is alerting on it, so we should detect problems.
- It would probably be useful for both Chaos and Mitch for gmoc-db2 to have a copy of SNAPP on it, so it could be used to stage SNAPP changes.
Next action:
- Color(gold,Mitch)? will setup SNAPP on gmoc-db2, or report back if this is too hard.
9b. Find a good way to distribute data submission software
GPO now has RPM and debian packages for monitoring each of a number of aggregates used in the early mesoscale (PlasticSlices/MonitoringRecommendations). Determine how GMOC's measurement_sender script should be integrated into these packages so sites don't have to obtain measurement_sender by hand to install the software.
Mitch has learned that GMOC is willing to host static files related to monitoring, but does not want to host an RPM or Debian package repository. Chaos has learned that GPO can include measurement_sender in our package.
Next action:
- Color(gold,Chaos)? will finalize the tango-monitor RPM and debian packages, and provide them to Mitch.
9c. Evaluate the GPO-sourced tango-monitor RPMs for IU use
Status: Color(green,DONE)?. Mitch looked at the GPO's tango-monitor-myplc RPM to assess what changes IU would need in order to use this RPM on their systems and in the core. He thinks the RPM is fine as is. GMOC needs to sign RPMs in order to use them, but they would need to sign with their own key even if we also signed the RPM, so Mitch doesn't believe that matters. He thinks our RPM is fine for IU use.
10. Evaluate the mechanism for authorized data submission from sites
The current process for submitting site authorization credentials is documented for site operators at GENIMetaOps/SiteCredentials. This process should be updated, and we should evaluate whether it is scalable for GENI racks which might use the data submission API.
Status: Color(green,DONE)?: The new process is similar to the old process, except that the credential will be submitted to GMOC's NOC rather than to a person. Mitch has gotten the appropriate keys and updated the page.
11. Submission of relational and event data using the GMOC API
Currently, the GMOC API should have provisions for using it to submit relational data to the GMOC database. As of now, we do not know if the code is ready to use, and there are not any helper scripts to use with it. In addition, we think the code expects that the full set of relations for a given site (or a given host? or the entire world?) will be submitted every time that site submits data.
We've decided on the following path forward:
- We will work on submitting relational data from one GPO host to GMOC in staging:
- Color(gold,Chaos)? will work, using GPO's staging pgeni testbed (pgeni1), on collecting some relational data for submission.
- Color(gold,Sarah)? will work on packaging collected relational data into the XML submission format.
- Color(gold,Mitch)? will work on setting up live API receipt of slice data on staging (gmoc-db2)
- Then we'll push that to production:
- Color(gold,Mitch)? will setup the same capability on gmoc-db
- Color(gold,Chaos)? will duplicate the staging code on the GPO's production pgeni testbed
- After that, we'll add a second host:
- Color(gold,Chaos)? will submit sliver data from the FOAM monitoring test host tau-verde to gmoc-db2
- Color(gold,Mitch)? will debug and modify the database until simultaneous submission from two hosts at the same site works
comment:5 Changed 12 years ago by
Update on item 11: relational data:
- Before GEC, Mitch wrote a perl module,
GMOC::ExchangeAPI, for packaging information into the relational schema and submitting it via HTTPS. Chaos installed that on pgeni1.gpolab.bbn.com (GPO staging ProtoGENI) to submit slice names to gmoc-db2, and on pgeni.gpolab.bbn.com (GPO production ProtoGENI) to submit slice names to gmoc-db. This appears to be working. - Next steps:
- Color(gold,Chaos)? will make a proposal for what data we'd like to submit for a couple of types of slivers, so we can test that out.
- Color(gold,Mitch)? will make a couple of UI improvements related to the relational data submission (GMOC ticket
3561).
Action items
Status symbols:
1. Improve reliability of data submission and of the database
1a. Investigate reliability issues as they arise
No next action (wait for something to go wrong).
1b. data submission server should reject submissions with unreasonable timestamps
Status: Color(gold,In progress)?: Camilo configured gmoc-db to reject data whose reported current timestamp is more than 5 minutes off. We're going to run like that for a few weeks, and, if things look good, start rejecting data whose reported current timestamp is more than 45 seconds off.
2. Make the pages concise and friendly for new users
Color(gold,Ticketed)?: This is GRNOC ticket 3039.
2a. Make the portal UI more concise and friendly
Next action is probably for someone to make a concrete list of changes to the portal UI for the function we all now understand it to have. Color(orange,Blocked on 2b.)? We will revisit this once we're done with item 2b.
2b. Improve the protected web UI to be more useful for experimenters
Next action: Camilo has taken a first cut at this. We will continue to iterate with Mitch.
3. Write documentation of portal and search functions which is accessible to nonexperts
Color(gold,Ticketed)?: This is GRNOC ticket 3040.
3a. descriptions of submitted stats
Next action: Color(gold,Sarah)? will mock up a wiki page for this
3b. brief overviews of how to use pages
Task: "how to use the portal"/"how to use SNAPP"/"how to use protected data UI" brief overviews
Next action: Color(orange,Blocked on 2.)? This will want to wait on other changes.
4. Portal should support a list of aggregates which have reported recently
Use case: an experimenter or operator wants to see a simple overview of which aggregates are currently reporting data, in order to see what aggregates are available or to detect a monitoring outage. (This could be an "index" or "status" tab of the portal, showing a list of sites/hosts which are currently reporting, and possibly also hosts which had been reporting until recently but have now stopped.)
Next action: Color(gold,Mitch)? will try setting this up, but is focusing on portal stuff right now, so no target date.
5. Flexibly handle complex datagroup names in display
Color(gold,Ticketed)?: This is GRNOC ticket 3041.
Task: flexibly handle datagroup names which contain multiple pieces of information, in both data selection and data display. (Note: this is the problem we started defining on jabber last week. The solution may involve using tags for what we believe they were originally intended for, or may involve submission of relational data.)
Next action: Color(gold,Chaos)? will mock up what she thinks a good solution would look like visually.
6. Support FOAM sliver name mappings
Use case: i am looking at a FOAM-controlled flowvisor (e.g. tulum.gpolab.bbn.com). I want to see all slivers active on that flowvisor, identified by GENI slice name. (Note: This use case combines fv_slice_status data for the flowvisor slice to get stats, with foam_sliver_status data for the FOAM sliver to get the FV slice to GENI slice name mapping. It requires the equivalent of a database JOIN, which we don't think can be supported in the general case (though we'll ask), but we think is needed for the specific case of monitoring FOAM-controlled flowvisors, which is a critical case in the mesoscale right now.)
Next action:
foam_variables. The datagroup will be named after the FOAM sliver urn, and will have tags for any other relational data we want to pass along. Target date: end of December.7. Support plnode sliver data overlay graph use case
Use case: i am looking at a plnode (e.g. bain.gpolab.bbn.com). I want to see a graph containing tx_bytes (an element of plnode_sliver_network) for each sliver on the plnode, identified by sliver name. (Note: this may involve using tags to choose arbitrary data to display on one line graph.)
We think we are very close to being able to do this using the "Overlay" graph option from SNAPP searches.
Next action:
8. Support GENI slice status page or search
Use case: i am interested in a GENI slice (e.g. urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+arosenOFslice). I want to see PLC and FOAM aggregates (including plnode and FV data) for everything relevant to this slice, in a reasonably viewable fashion.
Next action: Camilo has added statistics to the per-slice protected UI. We should look at that and see where we are.