[atlas] New default settings for Atlas measurement form

Hi Gerdriaan,

I see you have found the beta-ui preference setting for testing out the new msm details pages, hope you like the direction it is taking :). This is under heavy development so lots of things are likely to change until the dust settles. The details tab is still in the process of being ported from the old, and everything is not yet in place. You can still see the current (older) details page for measurements either on the main atlas.ripe.net <http://atlas.ripe.net/> site, or by changing your preference to not use the beta feature for the msm detail pages (or by simply replacing 'measurementdetail/70004930/details' with 'measurements/70004930/' in your url)

Kind regards,

Stephen


> On 17 Apr 2024, at 11:26, Gerdriaan Mulder <ripe at moeilijklastig.nl> wrote:
> 
> Hi Stephen,
> 
> Testing the same procedure as I mentioned earlier still gives the daily spending limit error, but that fortunately doesn't prevent setting the other options.
> 
> I could now successfully create a not-one-off measurement with a 120s interval and a predefined stop datetime (#70004930). Thanks!
> 
> In the beta UI, I couldn't find the stop datetime on the measurement details page. I would expect it to be visible on <https://beta-ui.atlas.ripe.net/measurementdetail/70004930/details> when clicking on "Status & Timing". Clicking on that part does rotate the "arrow" on the right side, but the details do not appear. I suppose that's still under development.
> 
> Thanks for the quick fix!
> 
> Best regards,
> Gerdriaan Mulder
> 
> On 17/04/2024 09.03, Stephen Suess wrote:
>> Hi again Gerdriaan!
>> 
>> I have looked into it, and see why you are experiencing this:
>> 
>> Every time values change in the form, we send a request to a special estimate API to determine if the payload is without error, and send back a cost estimate. Currently that endpoint does not calculate values less than a day (leaving it up to the client). So because your particular measurement would use a lot of credits, that daily estimate indeed exceeded your credits (while the much smaller defined time window should not have), and the API returned the warning you see. This in turn was short circuiting the client side calculation for the measurement's actual (approximate) credit usage.
>> 
>> We haven't actually seen this case happen before in our testing, so thank you for pointing it out. The complete fix will involve changes to the estimate API, and that has been requested and will hopefully be done soon. In the meantime, I have created a client side fix for this and put it up on our beta-ui site if you (or anyone else) would like to test it out before we move it to production tomorrow: https://beta-ui.atlas.ripe.net/measurements/form
>> 
>> Do let us know if you find other issues. Thanks again for reporting this.
>> 
>> Stephen
>> 
>>> On 16 Apr 2024, at 09:08, Stephen Suess <ssuess at ripe.net> wrote:
>>> 
>>> Hi Gerdriaan,
>>> 
>>> Thanks for the detailed report, I will look into these items and get back to you soon.
>>> 
>>> Stephen
>>> 
>>> 
>>>> On 15 Apr 2024, at 22:31, Gerdriaan Mulder <ripe at moeilijklastig.nl> wrote:
>>>> 
>>>> Hi Stephen, hi list,
>>>> 
>>>> I've noticed a few UI related issues that might have been introduced by this change, although they might have existed prior to this change. I'm not sure how they all relate, but it seems that the UI refuses to function properly when, at some point, you've received a message indicating:
>>>> 
>>>> There was a problem with your request
>>>> Details:
>>>> 1. Executing this measurement request would violate your maximum daily spending limit of 1000000.0 credits. Please stop some of your currently running measurements and try again.
>>>> 
>>>> For example, the "Costs" section isn't updated to reflect whatever daily cost the proposed measurement would've had. I would have expected that the form is just updated and (properly) refused on form submission.
>>>> 
>>>> One way to reproduce such a warning is:
>>>> 
>>>> 1. Create Measurement, select Traceroute, IPv6, target nl-ede-as12859.anchors.atlas.ripe.net
>>>> 2. More options, set frequency to 120, so far so good
>>>> 3. Toggle "This is a one-off"
>>>> 4. Observe the message above of exceeding some spending limit
>>>> 5. Try setting an End Time, for example the current date (the message above appears again), and 15 minutes in the future (the message above appears again)
>>>> 6. The "Costs" section indicates something along the lines of:
>>>> 
>>>> Current Balance: 37.854.350
>>>> This measurement would have a daily cost of: 3.000
>>>> Daily Income: 74.677
>>>> Days until balance exhausted: 12.618,12
>>>> Total cost for this measurement (if stop date known): N/A
>>>> 
>>>> 7. Try submitting the form
>>>> 8. The following message appears:
>>>> 
>>>> There was a problem with your request Details: 1. Executing thi15s measurement request would violate your maximum daily spending limit of 1000000.0 credits. Please stop some of your currently running measurements and try again.
>>>> 
>>>> As you might already see, a few fields show old values, such as "This measurement would have a daily cost of: 3.000", and "Total cost for this measurement (if stop date known): N/A", where we've seen that the daily cost would exceed 1000000.0 credits (from the warning message at least), and that we set an end date/time.
>>>> 
>>>> I also noticed a side-effect. When "increasing the frequency" from 120 to 900 (terminology might be a bit off there as well) such that the daily spending limit is below 1M, the end date/time that was entered is forgotten. Consequently, submitting the measurement as is will generate a non-bounded measurement.
>>>> 
>>>> Another "nag": when trying to set an end date/time, and clicking on today's date, the form refuses that input (the time is apparently automatically set to 00:00, which is typically before the current time), and sets the day to tomorrow instead.
>>>> 
>>>> As it happens, imagine my surprise trying to create a repeating measurement for approximately 1 hour, but instead ending up with a non-bounded one.
>>>> 
>>>> Best regards,
>>>> Gerdriaan Mulder
>>>> 
>>>> PS. When you remove the default probe selection, such that no probes are selected, the UI keeps on nagging (i.e. warnings pop up at the top of the screen) about this when you're editing other fields. This is a really frustrating experience. How about changing that to a more simple "list of things to fix" just above the Create My Measurement(s) button and/or simply highlighting the field that would currently not pass form validation?
>>>> 
>>>> On 13/03/2024 10.41, Stephen Suess wrote:
>>>>> Hello Atlas users,
>>>>> 
>>>>> After an analysis of usage patterns in measurement creation, we have rolled out a couple of changes to the defaults in the measurement form (https://atlas.ripe.net/measurements/form/ <https://atlas.ripe.net/measurements/form/>):
>>>>> 
>>>>> - Under timing, the default is now one-off (instead of periodic as before)
>>>>> - Default probe selection is now 50 random, worldwide probes (instead of 10 as before)
>>>>> 
>>>>> We hope you find these useful. Please let us know if you encounter any issues.
>>>>> 
>>>>> Thanks!
>>>>> Stephen
>>>>> RIPE Atlas UI
>>>>> 
>>>> 
>>>> -- 
>>>> ripe-atlas mailing list
>>>> ripe-atlas at ripe.net
>>>> https://mailman.ripe.net/
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20240417/aadb516b/attachment-0001.html>