Measurement (and Probe?) Naming

[danielquinn]

It'd be really nice to be able to create/edit a measurement and give it a name so that you could do something like this:

$ ripe-atlas report trace-to-danielquinn.org-from-s-america

The slug would have to be unique of course, but it beats having to look up the measurement id all the time, especially if you have a few measurements you query often.

[danielquinn]

It's funny, when I originally proposed an aliasing option, I was thinking more along the lines of something server-side, but I like @pierky's PR idea (#173) 'cause it would allow people to create aliases like starbucks without having to worry about naming conflicts with others'.

Now that I think about it though the problem with this approach though is that it's limited to measurements and perhaps it might be better to go the route of something like:

ripe-atlas alias measurement 1001 ping-all-the-things
ripe-atlas alias probe 1234 mom

Also, while I like the enthusiasm of using the config, it may not be the best place for it as this isn't really configuration. Maybe something like a separate aliases.json file or something is in order? I'm curious about what the RIPE guys have to say about this:

• Is this a feature they want to have?
• If so, is this something they want to implement client-side or server-side?

What say you guys?

[pierky]

Waiting for RIPE NCC guys' feedback I refined my PR by implementing @danielquinn's suggestions.

Aliases have been moved into a standalone file and are no more part of the configuration file. To setup and edit aliases I introduced the alias command:

$ ripe-atlas alias add measurement 1674977 traceroute_www.ripe.net
$ ripe-atlas alias add probe 1234 rack1
$ ripe-atlas alias del probe rack1

'traceroute_www.ripe.net' is an alias for 1674977

$ ripe-atlas alias list measurement

Measurement aliases:

- traceroute_www.ripe.net: 1674977

New features:

• now alias names can contain dots too!
• I implemented aliases for the probe-info command too.

If the client-side aliases idea will be the winner one, do you think it's worth to extend it to the API keys aliases too?

[emileaben]

As a ripe atlas user i often struggle with creating larger campaigns (consisting of multiple units of what RIPE Atlas defines as 'measurements'), especially if they have some structure (ie. i have a similar set of measurements at 5 different packet sizes). something like tagging of measurements, would probably solve that, and also solve aliasing (ie. a single unique tag if you just want a shortcut to a measurement).

ie. for my 5 sizes of packets, i'd choose 1 tag to uniquely identify the campaign, and 1 to id the pkt sizes: ripe-atlas tag measurement 12345 msm-campaign-667 msm-campaign-667-size100 ripe-atlas tag measurement 12346 msm-campaign-667 msm-campaign-667-size1000 ...

note: i'm heavily influenced by: Deli.cio.us

having server-side tagging allows for searches on these tags (tags have different meanings for different users, but it also seems to work for probes)

emile

[danielquinn]

@pierky I like what you've done so far on this with #173 but I think it'd be good to wait for the RIPE people to make a few decisions on this before you expend any more effort. Specifically, they need to say whether they (a) want to have this sort of feature in the client or in the server, (or indeed at all), and (b) if they do want to have it, what the nature of it would be. This ticket has already evolved from "let's name measurements" to "let's name measurements and probes" and now "let's name groups of measurements".

[astrikos]

I believe a server side solution would be the best but since there is no ETA, I think what @pierky did is okay for now. I agree we shouldn't spend more effort. We already have aliases for measurements/probes which are the most popular. Let's stay with these and see in the future what we can expand or delete if at some point it becomes server-side feature. Also it might be a nice test to see how people like it. If some express their interest because we have it on tools we can go and implement on server faster. Bottomline, merging #173 and closing this unless there are any other objections.

[pierky]

Ok, I fixed the problems you pointed out in the code of #173 so that it can be reviewed again before merging.