| 126 | | 9:10m [[BR]] |
| 127 | | |
| 128 | | === T4) GENI I&M Tool Testing Environment === |
| 129 | | 9:10am [[BR]] |
| 130 | | |
| 131 | | Harry Mussman (GPO) [[BR]] |
| 132 | | |
| 133 | | Goals [[BR]] |
| 134 | | * Define a step-by-step process for the GEMINI and GIMI tools sets over Spirals 4, 5 and 6 such that: [[BR]] |
| 135 | | * They deliver useful tools in each spiral [[BR]] |
| 136 | | * They eventually provide tools that can be included in slices built with any type of GENI hosts [[BR]] |
| 137 | | * GENI hosts should include those provided by ExoGENI and InstaGENI racks, as soon as they are available [[BR]] |
| 138 | | |
| 139 | | * Include: [[BR]] |
| 140 | | * User tools for experiment and measurement setup and orchestration [[BR]] |
| 141 | | * Interfaces/protocols between user tools and GENI aggregates [[BR]] |
| 142 | | * Supported GENI aggregates [[BR]] |
| 143 | | |
| 144 | | [[Image(Visio-070512_UseCases_Projects_Figures_Page_01.jpg, 110%)]] [[BR]] |
| 145 | | |
| 146 | | * [http://groups.geni.net/geni/wiki/InstMeasTopic_4.4GENIEnvironment I&M tool testing environment status at GEC13] [[BR]] |
| 147 | | |
| 148 | | Goals for Spiral 4: |
| 149 | | * By the end of Spiral 4, GIMI tools will test/operate in slices built in ORCA/ExoGENI environment [[BR]] |
| 150 | | * By the end of Spiral 4, GEMINI tools will test/operate in slices built in Emulab/protoGENI/InstaGENI environment [[BR]] |
| 151 | | * As much as possible, the two groups will use common user tools and common interfaces/protocols/APIs [[BR]] |
| 152 | | * As much as possible, the two groups will avoid arrangements customized to one environment [[BR]] |
| 153 | | * Both groups will be ready to provide tutorials on their capabilities starting at GEC-14. [[BR]] |
| 154 | | * Not yet defined: support for PlanetLab/InstaGENI environment [[BR]] |
| 155 | | |
| 156 | | [[Image(Visio-070512_UseCases_Projects_Figures_Page_02.jpg, 110%)]] [[BR]] |
| 157 | | |
| 158 | | Goals for Spiral 5: |
| 159 | | * By the end of Spiral 5, GIMI tools will test/operate in slices built in both the Emulab/protoGENI/InstaGENI and ORCA/ExoGENI environments (but not together in one slice) [[BR]] |
| 160 | | * By the end of Spiral 5, GIMI tools will also support measurements at WiMAX sites. [[BR]] |
| 161 | | * By the end of Spiral 5, GEMINI tools will test/operate in slices built in both the Emulab/protoGENI/InstaGENI and ORCA/ExoGENI environments (but not together in one slice) [[BR]] |
| 162 | | * Not yet defined: support for PlanetLab/InstaGENI environment [[BR]] |
| 163 | | |
| 164 | | [[Image(Visio-070512_UseCases_Projects_Figures_Page_03.jpg, 110%)]] [[BR]] |
| 165 | | |
| 166 | | Goals for later: [[BR]] |
| 167 | | * Both GEMINI and GIMI tools will test/operate in slices built with both Emulab/protoGENI/InstaGENI and ORCA/ExoGENI environments. However, this requires stitching functions that are not currently available. [[BR]] |
| 168 | | |
| 169 | | === T8) GENI User Tools and Services === |
| 170 | | 9:20am [[BR]] |
| 171 | | |
| 172 | | Jeanne Ohren (GPO)[[BR]] |
| 173 | | |
| 174 | | Goals [[BR]] |
| 175 | | * Work towards Max Ott's vision for experiment support [[BR]] |
| 176 | | * Provide a way for a GENI user (e.g., experimenter or operator) to access a wide variety of "GENI User Services", where each user service provides an interface (e.g., API or GUI) to the user. Those user services with a GUI (web) interface are often called "portal services".[[BR]] |
| 177 | | * Together, the "GENI User Services" should provide all of the functions the user needs to setup and run their experiment, then gather, analyze and present their measurement data. [[BR]] |
| 178 | | * These services should work together via APIs, etc., to streamline the experiment process. [[BR]] |
| 179 | | |
| 180 | | Tasks [[BR]] |
| 181 | | * Based upon the configuration defined below, the implementation is split into: [[BR]] |
| 182 | | 1) A GENI User Workspace, which is a persistent Linux OS environment dedicated to the user, that serves as a container for multiple user tools [[BR]] |
| 183 | | 2) Multiple GENI User Tools, where each provides a service with an interface or a "portal" to the user. [[BR]] |
| 184 | | * Define, prototype, deploy and operate a GENI User Workspace. [[BR]] |
| 185 | | * Gather the various "user tools" that have been implemented to date, and fit them into GENI User Workspace Service so that GENI I&M users can begin to conveniently conduct experiments or instrument infrastructure. [[BR]] |
| 186 | | * So that the GENI User Workspacet can be hosted on a server dedicated to the user (even the user's laptop), provide on a Virtual Box "portable VM". [[BR]] |
| 187 | | * Use the "GENI User Workspace" to test the GIMI and GEMINI tools, and during their tutorials. [[BR]] |
| 188 | | |
| 189 | | Summary [[BR]] |
| 190 | | * [http://groups.geni.net/geni/wiki/InstMeasTopic_4.8PortalService status at GEC13] [[BR]] |
| 191 | | * [http://groups.geni.net/geni/attachment/wiki/GEC14Agenda/IMDesignTopics/GEC14GENIUserToolsAndServices.pdf User workspace configuration at GEC14 (Spiral 4)] [[BR]] |
| 192 | | |
| 193 | | Discussion [[BR]] |
| 194 | | * Should the GENI User Workspace be supported on a server hosting multiple user workspaces for multiple users? [[BR]] |
| 195 | | * Which tools should be added to the GENI User Workspace? [[BR]] |
| 196 | | * How can we best optimize "user tools" and their interfaces to better meet the needs of GENI users (e.g., experimenters and operators). [[BR]] |
| | 126 | 9:00am [[BR]] |
| 201 | | 9:30am [[BR]] |
| 202 | | |
| 203 | | Harry Mussman (GPO) [[BR]] [[BR]] |
| 204 | | |
| 205 | | Summary [[BR]] |
| 206 | | * Current v0.2 design [http://groups.geni.net/geni/wiki/GEC11InstMeasWorkingSession#a2MeasurementDataObjectDescriptorMDOD references] [[BR]] |
| 207 | | * [http://groups.geni.net/geni/wiki/InstMeasTopic_4.5DescriptorsObjectsRegistriesLookupService status at GEC13] [[BR]] |
| 208 | | |
| 209 | | Review of v0.2 design at GEC13 (Giridhar Manepalli): [[BR]] |
| 210 | | [http://groups.geni.net/geni/attachment/wiki/GEC13Agenda/InstrumentationAndMeasurement/T5%29%20%20MDOD%20Status%20-%20CNRI.pptx slides] [[BR]] |
| 211 | | |
| 212 | | Conclusions: [[BR]] |
| 213 | | |
| 214 | | Good things: [[BR]] |
| 215 | | Excellent start [[BR]] |
| 216 | | Collaborative Specification [[BR]] |
| 217 | | Great Coverage [[BR]] |
| 218 | | Nicely broken down into elements [[BR]] |
| 219 | | Mandatory vs. optional elements identified [[BR]] |
| 220 | | Genuine Use Cases: Gathering, transferring, and sharing [[BR]] |
| 221 | | |
| 222 | | Jensen's proposal (NetKarma): [[BR]] |
| 223 | | Current: Identifiers, Descriptors, Holders [[BR]] |
| 224 | | Proposed: Identification, Lineage/Provenance, Constraints/Security, MDO Description [[BR]] |
| 225 | | |
| 226 | | Zurawski's comments: [[BR]] |
| 227 | | Too many secondary identifiers [[BR]] |
| 228 | | Descriptors should be contextualized [[BR]] |
| 229 | | Variations based on the type of object [[BR]] |
| 230 | | GENI specific descriptions should be clearly marked and separated [[BR]] |
| 231 | | Slight changes to names & enclosing elements recommended [[BR]] |
| 232 | | |
| 233 | | Comments/suggestions based on metadata practices: [[BR]] |
| 234 | | Too many optional elements [[BR]] |
| 235 | | Too many choices given to users [[BR]] |
| 236 | | Users bound to take the path of least resistance [[BR]] |
| 237 | | Keep the scope restricted to only mandatory elements – at least in the beginning [[BR]] |
| 238 | | Try those out. Implement them. [[BR]] |
| 239 | | One size fits all ---- No! [[BR]] |
| 240 | | Capturing descriptions, formats, policies, transactions, etc. in a monolithic fashion [[BR]] |
| 241 | | Register individual components separately [[BR]] |
| 242 | | E.g., Capture legal formats & interpretations in their own records, and reference them here [[BR]] |
| 243 | | E.g., Same with accepted policies [[BR]] |
| 244 | | Identifiers cannot be semantic [[BR]] |
| 245 | | Domain, sub-domain, and object-type are part of an ID [[BR]] |
| 246 | | World view changes frequently [[BR]] |
| 247 | | Non-semantic Ids are worth every penny [[BR]] |
| 248 | | Search engines & registries mask the opaqueness [[BR]] |
| 249 | | After all, IDs are just entities behind the scenes [[BR]] |
| 250 | | Object Type controlled vocabulary enumerates apples and oranges [[BR]] |
| 251 | | Collection, flow, directory, file, database, gui are not mutually exclusive [[BR]] |
| 252 | | Doesn’t help the recipient make any decision looking at the descriptor [[BR]] |
| 253 | | Bundle type & format into format interpretation method [[BR]] |
| 254 | | Covers too many corner cases, e.g., flow-rate [[BR]] |
| 255 | | Expects too many details, e.g., locator (type, access method, etc.) [[BR]] |
| 256 | | |
| 257 | | |
| 258 | | |
| 259 | | Tasks [[BR]] |
| 260 | | * Need to DRAFT simplified v1.0 MDOD schema, for XML file; then review and finalize. [[BR]] |
| 261 | | * Optional: extend MDOD to cover all types of objects, i.e., software images. [[BR]] |
| 262 | | * Optional: extend MDOD schema to define Event Record schema. [[BR]] |
| 263 | | * Do we need MDOD registry? Include in iRODS? [[BR]] |
| 264 | | * Need MDOD creation and editing service. [[BR]] |
| 265 | | * Need Measurement Data Object identifiers (names); sometimes need a persistent, public reference; consider DataCite approach, which uses handle [[BR]] |
| 266 | | |
| 267 | | |
| 268 | | |
| 269 | | Discussion |
| 270 | | * Who will help DRAFT simplified v1.0 MDOD schema, for XML file? [[BR]] |
| 271 | | * GIMI rep?[[BR]] |
| 272 | | * GEMINI rep?[[BR]] |
| 273 | | * Shall we have a breakout meeting on Wed, 7/11? [[BR]] |
| 274 | | * Who will implement MDOD creation and editing service? [[BR]] |
| 275 | | * How will MDOD be included in iRODS? [[BR]] |
| 276 | | |
| | 131 | 9:00am [[BR]] |
| | 132 | |
| | 133 | Harry Mussman (GPO) and Giridhar Manepalli (CNRI) [[BR]] [[BR]] |
| | 134 | |
| | 135 | |
| 289 | | 9:00am [[BR]] |
| 290 | | |
| 291 | | Mike Zink (UMass Amherst) and Anirban Mandal (RENCI) [[BR]] |
| 292 | | |
| 293 | | Tasks [[BR]] |
| 294 | | * Define, prototype, demonstrate and operate a GENI XML Messaging service, starting at GEC13. [[BR]] |
| 295 | | * Support use in GENI by many tools, starting with GIMI I&M tools, who will use it to exchange OMF messages. [[BR]] |
| 296 | | * Define operations plan for XML Messaging service. [[BR]] |
| 297 | | |
| 298 | | |
| 299 | | Summary [[BR]] |
| 300 | | * [wiki:InstMeasTopic_4.6MessagingService status at GEC13] [[BR]] |
| 301 | | * An XMPP server has been setup at UMass Amherst for OMF messages. [[BR]] |
| 302 | | * An XMPP server is operational at Rutgers WINLAB (and other GENI wireless sites) for OMF messages. [[BR]] |
| 303 | | * An XML messaging service has been prototyped by the IMF project, that includes authorization. [[BR]] |
| 304 | | * [http://groups.geni.net/geni/attachment/wiki/GEC14Agenda/IMDesignTopics/GEC14-IMF-Anirban.2.pptx status at GEC14] [[BR]] |
| 305 | | |
| 306 | | Discussion [[BR]] |
| 307 | | * Who is lead/leads? [[BR]] |
| 308 | | * Where will XMPP servers be located? will they be fully federated? [[BR]] |
| 309 | | * How do we set "topics" in XMPP servers to support OMF messages? [[BR]] |
| 310 | | * Will these XMPP servers provide a generalized GENI XML messaging service? If so, what functions will be included? |
| 311 | | * What authorization mechanisms will be required? [[BR]] |
| 312 | | * Will the GEMINI project want to use the XML messaging service? [[BR]] |
| 313 | | * Will other parts of GENI (e.g., monitoring) want to use the XML messaging service? [[BR]] |
| 314 | | * Do we need a breakout session for further discussion? when? [[BR]] |
| 315 | | * We need an operations plan for reliable service; when? who? [[BR]] |
