perfSONAR User Q&A and Other Discussion

[Alan Whinery <>]

Thanks all.

David --
> So when we add a node, we run the script, and out pops an entire new 
> configuration.
Is that script share-able?


On 1/9/2015 10:06 AM, Aaron Brown wrote:
> Hey Alan,
>
>> On Jan 9, 2015, at 1:47 PM, Alan Whinery 
>> <>
>>  wrote:
>>
>> Thanks,
>>
>> I try to avoid being that guy that asks all the questions that are in
>> the README, sometimes to a fault. But I realized this morning that I'm
>> not going to shoehorn in the time to figure it out for myself before the
>> next set of digressions arrives.
>>
>> I had noticed the new more obviously-coherent "regular_testing"
>> directory there and the question, if I had framed it better, could have
>> been "if I alter regular_testing.conf, is that everything that needs to
>> happen to manage the test/endpoint list?”
> Yep, that’s where it all goes. 
>
>> The next question is -- do I restart, reload or HUP something after I
>> change the file, to make the changes effective?
> Just run “service regular_testing restart” and you should be good
>
> Cheers,
> Aaron
>
>> On 1/9/2015 8:00 AM, David A. J. Ripley wrote:
>>> This doesn't *quite* answer your question, but for some of our use cases 
>>> where there are a relatively large number of test points and a 
>>> well-structured test scheme, we generate the configuration 
>>> programmatically, using a script that encapsulates the desired test 
>>> rules, and takes as its input the list of test points. So when we add a 
>>> node, we run the script, and out pops an entire new configuration. 
>>> Obviously, this approach won't work well if you're going to have per-node 
>>> schedules. The point I'm trying to make is that scripting deltas in the 
>>> conf may be harder than just defining your test plans logic in a script 
>>> and generating a new config when you need to.
>>>
>>> D.
>>>
>>>> On Jan 9, 2015, at 12:16 PM, Daniel Doyle 
>>>> <>
>>>>  wrote:
>>>>
>>>> You would probably have the best luck trying to have it edit the regular 
>>>> testing conf file directly. All of the test manipulation in the frontend 
>>>> is handled through CGI requests so while it is technically possible to 
>>>> emulate what the frontend is doing it is uncharted (read: undocumented) 
>>>> territory.
>>>>
>>>> If you create a new test via the frontend and examine what it dumps into 
>>>> that file it should be straightforward to duplicate similar behavior.
>>>>
>>>> Removing the endpoints/tests should be the same thing - load up the 
>>>> file, pull your test or endpoint out, rewrite it.
>>>>
>>>> -Dan
>>>>
>>>>
>>>> On Jan 9, 2015, at 11:49 AM, Alan Whinery 
>>>> <>
>>>>  wrote:
>>>>
>>>>> And again with a Subject:
>>>>> More coffee now...
>>>>>
>>>>> On January 9, 2015 6:48:10 AM HAST, Alan Whinery 
>>>>> <>
>>>>>  wrote:
>>>>> What would be the straightforward and perfSONAR-minded way to have a 
>>>>> script do:
>>>>>
>>>>> 1 - add a scheduled test
>>>>> 2 - add an endpoint
>>>>> 3 - add another endpoint
>>>>>
>>>>> ?
>>>>>
>>>>> And I suppose the inevitable extension --
>>>>>
>>>>> 4 - delete endpoint (if necessary) 
>>>>> 5 - delete test
>>>>> ?
>>>>>
>>>>> -- 
>>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>> Dan Doyle
>>>> GlobalNOC Software Developer
>>>> 1-812-856-3892
>>>> 
>>>>
>>>>
>>>>
>>> --
>>> David A. J. Ripley
>>> Indiana University GlobalNOC.
>>> <>
>>>  +1-812-855-5079
>>> http://mypage.iu.edu/~daripley/daripley.pgp
>>>
>>