perfsonar development work

[Jeff W.Boote <>]

I think there is a fundamental problem with the way pS-UI is trying to  
use to use the gLS infrastructure.

When you bring up a web-browser, you don't say: tell me all web  
servers in existence so I can pick from them. That is not a scalable  
user interface, and it is not a scalable information architecture.

The gLS infrastructure should not be expected to be able to give you  
all current bwctl-mp servers in a blink of an eye, just like you don't  
expect your web browser to be able to collect all news services that  
fast.  For the web-browser, you make use of an intermediary that  
caches the information, and I would suggest that is the most likely  
best case scenario here. I recommend having a daemon run on a  
centralized host that is continuously being updated based on what it  
finds in the gLS to generate an 'current' MA.conf file. (This could be  
implemented in a similar way to http://www.perfsonar.net/activeServices.html.)

If every client tries to do this functionality, it is not scalable.  
gLS/hLS servers will quickly see things that look like DOS attacks and  
will need to add hooks to protect themselves from excessive queries.  
(Note - DNS servers do not allow zone transfers in general for the  
same reason.) The distributed gLS/hLS database is designed to answer  
more specific queries in the same model as DNS.

jeff

On Feb 25, 2009, at 7:36 AM, Szymon Trocha wrote:

> 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