perfsonar development work

[Szymon Trocha <>]

Dear all,

You raised an important point for discussion. The list of services in 
psUI config file is already long and contains services which do not work 
or responding. It is also becoming more difficult to maintain. While at 
the same time a lot of work was put in creating LS capabilities.

Michael Bischoff pisze:
> "why is the MA.conf file still necessary?"
[...]
> Stripping MA.conf method from psui in one go would be to abrupt on our users. 
> While psui is
> gLS capable, we would want to allow some period where the functionally can be 
> matured as well
> as deployments increase.
>
> MA.conf still serves use, albeit in a somewhat evolved way, it would be 
> useful to allow
> users/(small)usergroups to have access to their personal list of 
> favourite/frequently used
> services. This could even evolve in to a locally hosted cached list of gls 
> entries.

Yes, and this is already a case where LHCOPN has its own dedicated 
instance of psUI, with a dedicated list of services, while not using LS 
capability yet. So this is at least one reason to leave it.

> Dynamically obtained service addresses should for the most part replace more 
> 'statically'

I fully support Jason's view here to make use of LS infrastructure and 
finally (possibly) replace the config file. Although I may still 
consider some period of time where configuration file exists but is 
static and e.g. restricted for MDM participants (just as en example of 
user group). I'm strongly against including test, non-productive or 
external services in the list.

> MA.conf. The adoption rate here should be a direct indication as to the 
> quality of the
> provided functionality. Additional stimulation above the added ease of use 
> that dynamically
> obtaining service addresses brings, would only and frustrate the user. 
> Increasing awareness
> is more the direction I would opt for. So don't say 'use this', but rather 
> 'did you know..'
> and gather feedback - improve the functionally - which should improve 
> adoption rate.

Currently within GN2 the adoption rate is not fast although the tools 
are already there (don't know the reason why yet). I'm not even talking 
about LS but also MA instances. MDM is still small in size and not 
up-to-date. The only wide deployment is taking place for LHCOPN, our 
first real user. Increasing the adoption rate in terms of service 
coverage and then LS cloud deployment is necessary to make the whole 
system useful and functional. This is one of my top priorities for GN3 
especially that perfSONAR will be a service activity under GN3. This 
should also bring us feedback as Michael wrote.

And if there are any issues or doubts regarding hLS/gLS we should 
discuss them and solve. There was so much good work done until this time 
to leave it unused.

Regards,
--
Szymon Trocha

Poznan Supercomputing & Netw. Center ::: NETWORK OPERATION CENTER
Tel. +48 618582022 ::: http://noc.man.poznan.pl