[AG-DEV] Continual of AG services - Update 2
Salim Haniff
Salim.Haniff at uta.fi
Mon Apr 16 04:24:19 CDT 2012
Hi Jason and fellow colleagues,
I quickly looked over this email. It's quite in depth and it will
take more time for me to answer but I have some comments.
When it comes to commercial and institutional hosting it may be tricky
on my side. I am already struggling with explaining why AccessGrid
(or open source technologies rather) are better for academic
institutions. The current problem is various institutes have made a
financial investment into Adobe's Connect application so it will be
hard convincing them to spend more money on a "duplicate" product.
Even though the financial cost may be very small for AccessGrid they
are not interested in alternative solutions. Perhaps using Google to
store as much services as possible might be a better start.
If my memory about DNS is correct, only anl.gov can handle all the DNS
forwarding information. But I guess it would be up to their network
admin to reconfigure the address every time the hosted service IP
changes.
I tried to modify content in the table but my email client isn't
co-operating with me so I will do this later this week.
I am in favour of Jason's proposal of isolating global and regional
services. Certainly the bridge and multicast beacon could be
regionalized. The only pitfall, like my institution is currently
facing, the nearest bridge provider may lie in another region and I'm
not sure what political ramification this may cause.
For future planning, could it be possible to move some of the contents
of this email to a Wiki, like the table below, for easy editing. That
way updates could be made easier and everyone can see them quickly.
Additionally, maybe some tasks and deadlines assigned so this project
doesn't fall too far behind. I will again this week ask around if
anyone at my university is willing to help out getting a server for
supporting this project. If not I could try setting up something on
my dreamhost account but the problem is the account does not have HTTPS.
Best,
Salim
Quoting Jason Bell <j.bell at cqu.edu.au>:
> Colleagues (resent - I haven't received any feedback from this recent update)
>
> 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-tech at mcs.anl.gov<mailto:ag-tech at mcs.anl.gov>
> ag-users at mcs.anl.gov<mailto:ag-users at mcs.anl.gov>
> ag-announce at mcs.anl.gov<mailto:ag-announce at mcs.anl.gov>
> ag-dev at mcs.anl.gov<mailto:ag-dev at mcs.anl.gov>
> ag-cvs at mcs.anl.gov<mailto:ag-cvs at 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.bell at cqu.edu.au<mailto:j.bell at cqu.edu.au>
> j.bell at qcif.edu.au<mailto:j.bell at qcif.edu.au>
>
> jason.bell at arcs.org.au<mailto:jason.bell at 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.
> -------------------------------------------------------------------------
--
Salim Haniff (salim.haniff at uta.fi)
School of Information Sciences
33014 University of Tampere, Finland
More information about the ag-dev
mailing list