Closed jouvin closed 5 years ago
As an option, it would be good to be able to use the rack fullname
I think that's potentially risky as full names are not guaranteed to be valid pan, or perhaps even directories on the filesystem. Would it make sense to add an option to allow free-form rack codes that are not generated from the room name?
What is the use case for someone having to actually navigate the machine templates? I can't imagine why the average user should care what the directory structure is.
For the average user I don't know, for me when debugging things I can tell! Recently @urbonegi mentioned that there was internal discussions at MS about adding a new field that would be a rack label that could be defined by the site and would have to be a valid directory/pan namespace (we could even imagine to derive a default value from the full name). It would be perfectly ok for me.
Discussed with @jouvin and @XaF after the workshop, this is not needed as the templates can be easily seen with aq cat --machine
. If someone really wants to see the actual file lives, then the namespace is at the top of the aq cat
output.
The machine templates generated by the broker (
machine
directory in plenary templates) have a pan namespace reflecting the location hierarchy where the rack is designated by the rack name. But the rackname is a value generated by Aquilon, based on the room name, to ensure it is unique but as a consequence is not easily mapped to an actual rack (without usingaq show rack
), making difficult to navigate the machine templates.As an option, it would be good to be able to use the rack fullname, that a site can use to reflect the actual rack name at the site (at LAL we use for the fullname the label which is written on the rack) instead of the rack (generated) name.
This issue is somewhat related to #104 machine/site proposed namespace fix but need to be controlled by a different option.