Colleagues I have posted an updated message of the "Continual of AG services" to the AG-Dev list. I have posted a copy of this email to this mailing list as well, in the effort to obtain as much feedback as possible.
It is preferred that feedback is posted to the AG-Dev mailing list (https://lists.mcs.anl.gov/mailman/listinfo/ag-dev to subscribe), but you are welcome to post to this list or to me personally. Many thanks, Jason. From: Jason Bell Sent: Tuesday, 10 April 2012 03:33 PM To: ag-...@mcs.anl.gov Subject: Continual of AG services - Update 2 Colleagues I have started to draft feedback (apologies for the roughness) from everyone and collated a few ideas on ways to move the AG services forward. I have attempted to group all comments and added a few of my own, but please feel free to comment, even editorial feedback welcomed! It is hoped that this email is only the beginning and additional content will be provide once new feedback has been obtained, particularly to the table below. Please note, that though a number of suggestions were made on how the Access Grid software and services can be improved, I believe it is important to focus on the continuation of current services, before additional code development or the likes can be considered. One idea that has been floated around, is to setup a/many Virtual Machine/s to run many of the services on. There are many options with this idea, either use one of the many global hosting services, or to use an institutional system (thanks to all those institutional groups who have already offered their services!). Some things to consider though: Commercial hosting service * Someone or group has to finance the ongoing costs o Even if multiple groups contribute, a board or person will have to manage payment, etc. * Commercial grade network (will large downloads and site visits be slow or incur large costs) * Will the "hosting" be reliable? * Given the many hosting services that are starting and stopping, will a new host be needed every couple of years? * Not tied to any particular group or organisation, therefore if funding stops from one location, another can take over or replace easily, without the need to move the services to another location. * Not being tied to anyone particular, this can be seen as a more open source product and community. Institutional hosting * Will the services need to be transferred again, after support runs out? * Will network charges be incurred? * Most intuitional organisations are funded on a "term" basis, therefore, will services need to be moved regularly once support runs out? o For example, ANL will no longer fund/support the AG projects, therefore services need to be moved. Will this be something that occurs every few years? o How reliable can we count on the support? * Institutions generally have very large and fast networks, thus large data traffic should cause any performance issues. What do people think of the two options listed? Any advantages or disadvantages to add? Any preference? Another question that I guess needs to be answered is domain names. For example, some of the default aspects of the Venue Server and Venue Client code points to ANL addresses. For example, "vv3.mcs.anl.gov", I am wondering if it be possible to have rules in place that forward this address (DNS redirection) to another location (one to be determined of course). This will prevent the need to immediately modify source code and roll out updates to support new internet addresses. I have attempted to table the various Access Grids Services and Systems that need to be transitioned, provided some general comments and possible options. If anyone have anything else to add or modify, please do contribute to this conversation. Access Grid Services and Systems Comments Priority Option 1 Option 2 Option 3 Recommendation Additional Comments www.accessgrid.org<http://www.accessgrid.org> domain name * Can the domain name be transferred? * Who will own (be responsible) for maintaining this address * Do we want to obtain a new address? Nice to have Transfer domain Use a new address ??? vv3.mcs.anl.gov and other anl.gov domain names * Can all these address be forward to new location. * Thinking out loud, but standardising to a new address, such as www.accessgrid.org<http://www.accessgrid.org> would be useful in the long term. Nice to have Forward to new domain names Update Venue Client and Venue Server code and roll up new versions with these updates ??? Access Grid Source Code * A system needs to be implemented that allows the storage and Access to the Access Grid Source Code. * It is expected that an international group will oversee updates, etc. * This is currently in a SVN repository. * Only one repository required. Must to have Using Source Forge Google ???? Nothing further investigated? Using a hosted service (Commercial or Institutional) and implement a SVN repository Source Forge Instructions: http://sourceforge.net/apps/trac/sourceforge/wiki/SVN%20adminrepo#ImportingfromotherreposincludingotherSCMs ANL Jabber Server (could be made a regional service) * Currently, any newly configured Venue Server will use the ANL Jabber Server. * Questions: o Do we want to use a different technology than jabber? o Should a number of regional jabber servers be configured and a Venue Server config option be implemented. o Should each Venue Server run their own Jabber server, therefore removing a single point of failure? * Should a Global Jabber server be implemented as a stop gap measure? Critical Use a hosted service (Commercial or Institutional) and implement a Global Jabber server Note: The Venue Server source code will have to be modified to point to new server, if DNS redirection cannot be implemented. Use a different technology than Jabber. One technology that has been mentioned is MQTT (Message Queue Telemetry Protocol). Each host running their own jabber server? * Is this Feasible or even possible? * Is the development work require too much before the required deadline for the shutdown? ANL Bridge Registry (could be made a regional service) It is already possible to run your own Bridge Registry. The question is more, currently Venue Clients default to using "vv3.mcs.anl.gov:8030" Should another global "bridge registry" be implemented, or should a number of "regional bridge registries" be implemented that these be added to the source code? Critical Use a hosted service (Commercial or Institutional) and implement a Global Bridge Registry Note: The Venue Client source code will have to be modified to point to new server, if DNS redirection cannot be implemented. Roll out a set of regional registries, which is documented on the AG website and provide documentation to users for adding new registries. * Additionally, update source code to contain new registries. ??? AG-Dev Certificate Authority Currently, whenever new Venue Servers are implemented, they must request and install an identity certificate. Critical Centralised certificates? Use a hosted service (Commercial or Institutional) and implement a Global Jabber server Note: The Venue Server source code will have to be modified to point to new server, if DNS redirection cannot be implemented. Self-signed certificates * lessens the security features available * Does anyone care about this? ??? The accessgrid.org web site The www.accessgrid.org<http://www.accessgrid.org> website is a very useful resource that contained things like: * Global Node listing; * QA information and results; * AG Projects (http://www.accessgrid.org/projects) * Software downloads; * Documentation; * Hardware information; * Community information; and * New and events Things to note: * Website is based on Drupal 4.7 and is extremely long overdue for a software upgrade. Current version is 7.12 (as of 10/4/2012) * Newer versions may cause issues with some aspects of the current content, particularly Node listing and QA; Must to have Use a hosted service (Commercial or Institutional) and implement a Global Bridge Registry Simply move current content to new location. * Current version of drupal out-dated; * Content will be the same as current website. * Assumed less work required Use a hosted service (Commercial or Institutional) and implement a Global Bridge Registry Install newer version of drupal and port content over. * Significant amount of work required; * Some aspects, particularly Node listing and QA may have to be completely redeveloped; Start a fresh, possibly look towards using a different CMS system? It is assumed that the domain name www.accessgrid.org<http://www.accessgrid.org> can still be used. AG-related mailing lists There are many community mailing list that are actively used. These being: ag-t...@mcs.anl.gov<mailto:ag-t...@mcs.anl.gov> ag-us...@mcs.anl.gov<mailto:ag-us...@mcs.anl.gov> ag-annou...@mcs.anl.gov<mailto:ag-annou...@mcs.anl.gov> ag-...@mcs.anl.gov<mailto:ag-...@mcs.anl.gov> ag-...@mcs.anl.gov<mailto:ag-...@mcs.anl.gov> * Are all these mailing list still required? * Are there any other ones that should be created? * Can the history be ported? Must to have Use a hosted service (Commercial or Institutional) and implement an Access Grid mailing list service. Use Source Forge. If using Source Forge is decided as the best option for housing the source code, they have additional services such as mailing lists that could be used. ANL Venue Server It is already possible to run your own Venue Server. The question is more, currently Venue Clients default to using "vv3.mcs.anl.gov:8000" Should another global "Venue Server" be implemented, or should a number of "regional Venue Server" be implemented that these be added to the source code? * Which ones become default? Nice to have Use a hosted service (Commercial or Institutional) and implement a Global Venue Server Note: The Venue Client source code will have to be modified to point to new server, if DNS redirection cannot be implemented. Roll out / utilise more a set of regional Venue Servers, which is documented on the AG website and provide documentation to users for adding Venue Server addresses. Set the default Venue Server to one currently listed at http://www.accessgrid.org/community or another one??? Any volunteers? NCSA AG Scheduler NCSA are interested in finding someone to take on the support of AGSchedule Critical ??? Use a hosted service (Commercial or Institutional) and implement and support AGSchedule on a new server. Multicast Beacon Is a global or regional solution required? I would propose that we should try to break down some of the current AG services into 2 categories. These being Global and Regional Services. * Global Services - are services that only requires a single instance or implementation; * Regional Services - are services that can have multiple instances or implementations of; Once the various services are determined to be Global or Regional, a total list of global resources can be identified. For example, if throughout this process, it is determined that a regional list of bridge registries is the best option, then a global service is no longer needed. Thereby no resources will be required in running this as a global service, as it will be expected various "regional" group will run their own implementation. Many thanks for your time and I look forward to everyone's feedback. Many regards, Jason. ------------------------------------------------------------------------- Jason Bell, B.I.T. (Honours) Video Collaboration Champion Queensland Cyber Infrastructure Foundation http://www.qcif.edu.au/ ARCS eResearch Collaborative Services http://www.arcs.org.au/ Senior Research Technologies Officer Information Technology Directorate CQ University Australia http://www.cqu.edu.au/ E-mail : j.b...@cqu.edu.au<mailto:j.b...@cqu.edu.au> j.b...@qcif.edu.au<mailto:j.b...@qcif.edu.au> jason.b...@arcs.org.au<mailto:jason.b...@arcs.org.au> Work : +61 7 4930 9229 Mobile : 0409 630897 Postal : Building 19, Room 1.55 Central Queensland University Bruce Highway Rockhampton, Queensland, Australia, 4702 ------------------------------------------------------------------------- Patience is a virtue. But if I wanted Patience, I would have become a Doctor. -------------------------------------------------------------------------
