<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
From the UK's perspective we have, like most countries, an
independent network (in our case mixing AGTkit, IOCOM (IG2 and
visimeet) and EVO) but will like to cross-collaborate post June.<br>
<br>
Three things that need to be acted upon centrally:<br>
- Establish Google code or Source-Forge repository needed; source
code and packages<br>
- Mailing Lists: listserv or equivalent accounts are essential<br>
- Name/ownership of website accessgrid.org<br>
<br>
Extra point:<br>
- Central list of the bridge registry file locations. This could be
held as a list at accessgrid.org.<br>
(UK bridge registry
<a class="moz-txt-link-freetext" href="http://www.ja.net/services/video/agsc/AGSCHome/ag3peers.txt">http://www.ja.net/services/video/agsc/AGSCHome/ag3peers.txt</a>)<br>
- Central list of countries venue server list <br>
(UK venue server
<a class="moz-txt-link-freetext" href="https://sam.ag.manchester.ac.uk:8000/Venues/default">https://sam.ag.manchester.ac.uk:8000/Venues/default</a>)<br>
<br>
Less important and can be regional:<br>
- Jabber: most countries appear to use their own jabber server -
including now one in the UK. <br>
- Certificates - we have been testing and believe self-certification
is acceptable and note this is only really required when building a
new server or if used for client-server authentication. Also servers
run nicely even when a certificate expires. <br>
<br>
- Final issue is to check on who owns which multicast addresses. <br>
<br>
<br>
I will be at the worldwide meeting on Monday.<br>
yours Martin (<a class="mailto"
href="mailto:ag-collaboration@listserv.manchester.ac.uk">ag-collaboration@listserv.manchester.ac.uk</a>)<br>
<br>
<a class="moz-txt-link-freetext" href="http://wiki.rcs.manchester.ac.uk/community/VTAS">http://wiki.rcs.manchester.ac.uk/community/VTAS</a><br>
<br>
On 16/04/2012 14:55, Christoph Willing wrote:
<blockquote
cite="mid:88202C0E-25E8-485E-AAB5-4836D1C972DF@uq.edu.au"
type="cite">Comments below:
<br>
<br>
On 16/04/2012, at 11:59 AM, Jason Bell wrote:
<br>
<br>
<blockquote type="cite">Colleagues (resent – I haven’t received
any feedback from this recent update)
<br>
<br>
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!
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
One idea that has been floated around, is to setup
<br>
a/many Virtual Machine/s to run many of the services on.
<br>
</blockquote>
<br>
Virtual or physical machine is a site dependent implementation
detail we shouldn't need to worry about here.
<br>
<br>
<br>
<blockquote type="cite">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:
<br>
<br>
Commercial hosting service
<br>
<br>
· Someone or group has to finance the ongoing costs
<br>
o Even if multiple groups contribute, a board or person will
have to manage payment, etc.
<br>
· Commercial grade network (will large downloads and
site visits be slow or incur large costs)
<br>
· Will the “hosting” be reliable?
<br>
· Given the many hosting services that are starting and
stopping, will a new host be needed every couple of years?
<br>
· 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.
<br>
· Not being tied to anyone particular, this can be seen
as a more open source product and community.
<br>
<br>
Institutional hosting
<br>
<br>
· Will the services need to be transferred again, after
support runs out?
<br>
· Will network charges be incurred?
<br>
· Most intuitional organisations are funded on a “term”
basis, therefore, will services need to be moved regularly once
support runs out?
<br>
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?
<br>
o How reliable can we count on the support?
<br>
· Institutions generally have very large and fast
networks, thus large data traffic should cause any performance
issues.
<br>
</blockquote>
<br>
Answers to just about all these questions is pretty obviously yes.
Basically any support system that anyone sets up will occasionally
need renewal. I guess its best to minimise the frequency of that;
we've had a good run with ANL - over 10 years.
<br>
<br>
<br>
<blockquote type="cite">
<br>
What do people think of the two options listed? Any advantages
or disadvantages to add? Any preference?
<br>
</blockquote>
<br>
Its probably harder with a commercial option esp finding ongoing
funding. Doing it institutionally, we can take advantage of
people's spare of after hours cycles. Of course that obviates
performance guarantees (but we've never had them previously
anyway).
<br>
<br>
<br>
<blockquote type="cite">
<br>
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).
<br>
</blockquote>
<br>
According to whois, accessgrid.org belongs to University of
Chicago. They would have to (as mentioned below) either:
<br>
1. transfer ownership to the new "owners" (yet to be
determined)
<br>
or 2. point DNS to new owners IP addresses
<br>
<br>
<br>
<blockquote type="cite"> This will prevent the need to
immediately modify source code and roll out updates to support
new internet addresses.
<br>
<br>
I have attempted to table
<br>
</blockquote>
<br>
Sorry my email client has lost the table layout - hope the
comments make sense.
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
<br>
Access Grid Services and Systems
<br>
Comments
<br>
Priority
<br>
Option 1
<br>
Option 2
<br>
Option 3
<br>
Recommendation
<br>
Additional Comments
<br>
<a class="moz-txt-link-abbreviated" href="http://www.accessgrid.orgdomain">www.accessgrid.orgdomain</a> name
<br>
· Can the domain name be transferred?
<br>
<br>
· Who will own (be responsible) for maintaining this
address
<br>
<br>
· Do we want to obtain a new address?
<br>
<br>
<br>
Nice to have
<br>
Transfer domain
<br>
Use a new address
<br>
???
<br>
<br>
<br>
vv3.mcs.anl.gov and other anl.gov domain names
<br>
· Can all these address be forward to new location.
<br>
<br>
· Thinking out loud, but standardising to a new address,
such aswww.accessgrid.org would be useful in the long term.
<br>
<br>
<br>
Nice to have
<br>
Forward to new domain names
<br>
Update Venue Client and Venue Server code and roll up new
versions with these updates
<br>
</blockquote>
<br>
Packaging new versions for Linux after code updates is pretty
easy.
<br>
<br>
Mac packaging has been (I think) exclusively an ANL activity.
<br>
<br>
Windows packages have been based on ANL packaging too haven't
they.
<br>
<br>
That probably means that those at ANL who have been making the Mac
& Windows packages will need to keep making them, or others
will have to figure out how to do it (hopefully with ANL
packagers' help).
<br>
<br>
Who's volunteering to do the Mac & Windows builds? Hard to
continue without them.
<br>
<br>
<br>
<blockquote type="cite">???
<br>
<br>
<br>
Access Grid Source Code
<br>
· A system needs to be implemented that allows the
storage and Access to the Access Grid Source Code.
<br>
<br>
· It is expected that an international group will
oversee updates, etc.
<br>
<br>
· This is currently in a SVN repository.
<br>
<br>
· Only one repository required.
<br>
Must to have
<br>
Using Source Forge
<br>
<br>
<br>
Google ????
<br>
<br>
Nothing further investigated?
<br>
<br>
Using a hosted service (Commercial or Institutional) and
implement a SVN repository
<br>
<br>
Source Forge
Instructions:<a class="moz-txt-link-freetext" href="http://sourceforge.net/apps/trac/sourceforge/wiki/SVN%20adminrepo#ImportingfromotherreposincludingotherSCMs">http://sourceforge.net/apps/trac/sourceforge/wiki/SVN%20adminrepo#ImportingfromotherreposincludingotherSCMs</a><br>
<br>
ANL Jabber Server
<br>
(could be made a regional service)
<br>
· Currently, any newly configured Venue Server will use
the ANL Jabber Server.
<br>
</blockquote>
<br>
This is not exactly correct; while the ANL jabber server is the
default, this is actually set in the VenueServer.cfg file so is a
configurable setting. The catch is that this file is generated for
you, if it doesn't already exist, from defaults in the VenueServer
library. Therefore if you don't have a VenueServer.cfg already,
create a minimal one with (for instance)
<br>
<br>
# AGTk 3.2
<br>
[VenueServer]
<br>
textHost = jabberserver.somewhere.org
<br>
<br>
- the remaining entries will be created for you when you start the
server.
<br>
<br>
If you already have a VenueServer.cfg, edit the textHost entry to
whatever you like and restart the server.
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
· Questions:
<br>
o Do we want to use a different technology than jabber?
<br>
</blockquote>
<br>
There are some good reasons to use something different. A recently
discovered good reason to keep it is that its logfile provides an
excellent record of venue server usage. See:
<br>
<a class="moz-txt-link-freetext" href="http://www.rcc.uq.edu.au/accessgrid/usage/">http://www.rcc.uq.edu.au/accessgrid/usage/</a>
<br>
for a display of the APAG Venue Server usage, derived wholly from
the logfile of the Jabber server we run here.
<br>
<br>
<br>
<blockquote type="cite">o Should a number of regional jabber
servers be configured and a Venue Server config option be
implemented.
<br>
</blockquote>
<br>
As above, thats configurable in the VenueServer.cfg file right
now. There'd be no problem with adding a specific option but since
its already configurable by other means, needn't be a high
priority.
<br>
<br>
<br>
<blockquote type="cite">o Should each Venue Server run their own
Jabber server, therefore removing a single point of failure?
<br>
</blockquote>
<br>
While its pretty easy to run a venue server, its much, much harder
to set up a compatible jabber server (one of the good reasons to
use something other than jabber as the text chat protocol).
<br>
<br>
<blockquote type="cite">
<br>
· Should a Global Jabber server be implemented as a stop
gap measure?
<br>
</blockquote>
<br>
I'm happy for the APAG jabber server to be used globally as a more
or less indefinite stop gap measure.
<br>
<br>
<br>
<blockquote type="cite">Critical
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Jabber server
<br>
</blockquote>
<br>
From the above, I'm not sure its actually critical (at least not
urgent) to to implement a new jabber server. In any case it may be
a somewhat wasted effort if we end up using something other than
jabber.
<br>
<br>
<br>
<blockquote type="cite">
<br>
Note: The Venue Server source code will have to be modified to
point to new server, if DNS redirection cannot be implemented.
<br>
Use a different technology than Jabber.
<br>
<br>
One technology that has been mentioned is MQTT (Message Queue
Telemetry Protocol).
<br>
</blockquote>
<br>
I've suggested this in the past because I've used it myself in
other projects - other people will have their own favourites. MQTT
already has a python binding and I found it was pretty easy to use
and think it should be relatively easy to incorporate into the AG
code. However there would be a reasonable effort to actually do
it.
<br>
<br>
<br>
<blockquote type="cite">
<br>
Each host running their own jabber server?
<br>
<br>
· Is this Feasible or even possible?
<br>
</blockquote>
<br>
Setup complexity make this possibility doubtful.
<br>
<br>
<br>
<blockquote type="cite">· Is the development work require
too much before the required deadline for the shutdown?
<br>
<br>
<br>
ANL Bridge Registry
<br>
(could be made a regional service)
<br>
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”
<br>
</blockquote>
<br>
A second default (<a class="moz-txt-link-abbreviated" href="http://www.ap-accessgrid.org:8030">www.ap-accessgrid.org:8030</a>) has been included as
a default for quite a while (years?) now. Others can be easily
added but would need to be part of a new package release for them
to be available by default. Otherwise they can be added by hand
via VenueClient gui (hardly automatic though).
<br>
<br>
<br>
<blockquote type="cite">
<br>
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?
<br>
<br>
Critical
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Bridge Registry
<br>
<br>
Note: The Venue Client source code will have to be modified to
point to new server, if DNS redirection cannot be implemented.
<br>
Roll out a set of regional registries, which is documented on
the AG website and provide documentation to users for adding new
registries.
<br>
<br>
· Additionally, update source code to contain new
registries.
<br>
???
<br>
<br>
<br>
AG-Dev Certificate Authority
<br>
Currently, whenever new Venue Servers are implemented, they must
request and install an identity certificate.
<br>
</blockquote>
<br>
An identity will work but are pretty inconvenient to use from boot
time scripts; better to use service certificates.
<br>
<br>
<br>
<blockquote type="cite">Critical
<br>
Centralised certificates?
<br>
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Jabber server
<br>
<br>
Note: The Venue Server source code will have to be modified to
point to new server, if DNS redirection cannot be implemented.
<br>
Self-signed certificates
<br>
· lessens the security features available
<br>
<br>
· Does anyone care about this?
<br>
</blockquote>
<br>
Yes, I care about it and have started looking at how to set up a
certificate issuing infrastructure based on the ANL model. Its
incomplete - waiting for more time to spend on it. Needs some
changes to current AG code which points requests to particular
servers running particulars cgi scripts.
<br>
<br>
I'd recommend anyone running AG services to obtain new
certificates before June deadline so they have a year before
certificate system needs to be fully functional.
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
???
<br>
<br>
<br>
The accessgrid.org web site
<br>
The <a class="moz-txt-link-abbreviated" href="http://www.accessgrid.org">www.accessgrid.org</a> website is a very useful resource that
contained things like:
<br>
<br>
· Global Node listing;
<br>
· QA information and results;
<br>
· AG Projects (<a class="moz-txt-link-freetext" href="http://www.accessgrid.org/projects">http://www.accessgrid.org/projects</a>)
<br>
· Software downloads;
<br>
· Documentation;
<br>
· Hardware information;
<br>
· Community information; and
<br>
· New and events
<br>
<br>
Things to note:
<br>
· 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)
<br>
· Newer versions may cause issues with some aspects of
the current content, particularly Node listing and QA;
<br>
<br>
Must to have
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Bridge Registry
<br>
<br>
Simply move current content to new location.
<br>
<br>
· Current version of drupal out-dated;
<br>
· Content will be the same as current website.
<br>
· Assumed less work required
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Bridge Registry
<br>
<br>
Install newer version of drupal and port content over.
<br>
<br>
· Significant amount of work required;
<br>
· Some aspects, particularly Node listing and QA may
have to be completely redeveloped;
<br>
Start a fresh, possibly look towards using a different CMS
system?
<br>
<br>
It is assumed that the domain name <a class="moz-txt-link-abbreviated" href="http://www.accessgrid.org">www.accessgrid.org</a> can still
be used.
<br>
AG-related mailing lists
<br>
There are many community mailing list that are actively used.
These being:
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ag-users@mcs.anl.gov">ag-users@mcs.anl.gov</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ag-announce@mcs.anl.gov">ag-announce@mcs.anl.gov</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ag-dev@mcs.anl.gov">ag-dev@mcs.anl.gov</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ag-cvs@mcs.anl.gov">ag-cvs@mcs.anl.gov</a>
<br>
<br>
· Are all these mailing list still required?
<br>
<br>
· Are there any other ones that should be created?
<br>
<br>
· Can the history be ported?
<br>
<br>
<br>
Must to have
<br>
Use a hosted service (Commercial or Institutional) and implement
an Access Grid mailing list service.
<br>
<br>
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.
<br>
<br>
<br>
<br>
ANL Venue Server
<br>
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”
<br>
<br>
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?
<br>
· Which ones become default?
<br>
<br>
<br>
<br>
Nice to have
<br>
Use a hosted service (Commercial or Institutional) and implement
a Global Venue Server
<br>
<br>
Note: The Venue Client source code will have to be modified to
point to new server, if DNS redirection cannot be implemented.
<br>
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.
<br>
Set the default Venue Server to one currently listed
athttp://www.accessgrid.org/communityor another one???
<br>
<br>
Any volunteers?
<br>
</blockquote>
<br>
We'll continue to run APAG venue server from UQ.
<br>
<br>
We could easily run a more generic vv3.accessgrid.org server too
but maybe people would prefer that to be hosted more centrally
(US, Europe).
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
<br>
NCSA AG Scheduler
<br>
NCSA are interested in finding someone to take on the support of
AGSchedule
<br>
Critical ???
<br>
Use a hosted service (Commercial or Institutional) and implement
and support AGSchedule on a new server.
<br>
<br>
<br>
Multicast Beacon
<br>
Is a global or regional solution required?
<br>
</blockquote>
<br>
It would be good to have some widely used system again.
<br>
<br>
We've been using dbeacon for a while in Asia Pacific region and it
seems pretty good. It has no real central server - any
participating site can host web server for its display e.g.
display nominally hosted at:
<br>
<a class="moz-txt-link-freetext" href="http://syd-a-ext1.aarnet.net.au/matrix/">http://syd-a-ext1.aarnet.net.au/matrix/</a> (AARNet)
<br>
is also available at:
<br>
<a class="moz-txt-link-freetext" href="http://ag0-video.vislab.uq.edu.au:8888/matrix/">http://ag0-video.vislab.uq.edu.au:8888/matrix/</a> (UQ RCC)
<br>
<br>
<br>
<blockquote type="cite">
<br>
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.
<br>
<br>
· Global Services - are services that only requires a
single instance or implementation;
<br>
<br>
· Regional Services – are services that can have
multiple instances or implementations of;
<br>
</blockquote>
<br>
I'm not necessarily against it but I'm not sure this is a
particularly important distinction. Any AG service can be run by
as many different sites as want to run them. Whether you label
them global or regional doesn't really mean much. For instance the
APAG venue server has lots of venues related to the asia pacific
region but that hasn't prevented sites from elsewhere in the world
also using it (and they've been welcome to do so).
<br>
<br>
<br>
<blockquote type="cite">
<br>
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.
<br>
</blockquote>
<br>
Further to above, the concept of various groups running "their
own implementation" has been a core feature of the AG as I
understand it - it was designed to work in precisely that way.
Lots of "regional" services is the way to go, I think. No harm in
having some "model service site" as ANL has been over the years,
but not sure where that should be.
<br>
<br>
<br>
chris
<br>
<br>
<br>
<blockquote type="cite">
<br>
Many thanks for your time and I look forward to everyone’s
feedback.
<br>
<br>
Many regards,
<br>
Jason.
<br>
<br>
-------------------------------------------------------------------------
<br>
Jason Bell, B.I.T. (Honours)
<br>
<br>
Video Collaboration Champion
<br>
Queensland Cyber Infrastructure Foundation
<br>
<a class="moz-txt-link-freetext" href="http://www.qcif.edu.au/">http://www.qcif.edu.au/</a>
<br>
<br>
ARCS eResearch Collaborative Services
<br>
<a class="moz-txt-link-freetext" href="http://www.arcs.org.au/">http://www.arcs.org.au/</a>
<br>
<br>
Senior Research Technologies Officer
<br>
Information Technology Directorate
<br>
CQ University Australia
<br>
<a class="moz-txt-link-freetext" href="http://www.cqu.edu.au/">http://www.cqu.edu.au/</a>
<br>
<br>
E-mail : <a class="moz-txt-link-abbreviated" href="mailto:j.bell@cqu.edu.au">j.bell@cqu.edu.au</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:j.bell@qcif.edu.au">j.bell@qcif.edu.au</a>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jason.bell@arcs.org.au">jason.bell@arcs.org.au</a>
<br>
Work : +61 7 4930 9229
<br>
Mobile : 0409 630897
<br>
Postal : Building 19, Room 1.55
<br>
Central Queensland University
<br>
Bruce Highway
<br>
Rockhampton, Queensland,
Australia, 4702
<br>
-------------------------------------------------------------------------
<br>
Patience is a virtue.
<br>
<br>
But if I wanted Patience,
<br>
I would have become a Doctor.
<br>
-------------------------------------------------------------------------
<br>
<br>
</blockquote>
<br>
Christoph Willing +61 7 3365 8316
<br>
Research Computing Centre
<br>
University of Queensland
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>