You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when listing accounts/scopes while at VO def (i.e. when super_root) we return all accounts/scopes irrespective of VO. Normally we'd filter using .like('%@tst') at the core, but as we don't append the VO when at def, the string used is just '%' which returns all accounts.
In itself this isn't a bad thing, but because we strip the VO from the end of account names at the API level the list returned is somewhat confusing, for example it can have multiple root accounts and there's no indication of their respective VO.
There are other places we use .like() that may exhibit similar behaviour.
Modification
Do nothing, as this should only affect super_root who should/might not be running these kinds of commands on def anyway.
Limit the results to def (i.e. we should only see super_root in the list of accounts.
Include the VO in the returned list (for this set of circumstances only) so that super_root can use list functions to monitor across all VOs meaningfully.
Discuss at the next M-VO meeting? Course of action may depend on how we/users plan on using the M-VO setup.
The text was updated successfully, but these errors were encountered:
Motivation
Currently when listing accounts/scopes while at VO
def
(i.e. whensuper_root
) we return all accounts/scopes irrespective of VO. Normally we'd filter using.like('%@tst')
at the core, but as we don't append the VO when atdef
, the string used is just'%'
which returns all accounts.In itself this isn't a bad thing, but because we strip the VO from the end of account names at the API level the list returned is somewhat confusing, for example it can have multiple
root
accounts and there's no indication of their respective VO.There are other places we use
.like()
that may exhibit similar behaviour.Modification
Do nothing, as this should only affect
super_root
who should/might not be running these kinds of commands ondef
anyway.Limit the results to
def
(i.e. we should only seesuper_root
in the list of accounts.Include the VO in the returned list (for this set of circumstances only) so that
super_root
can use list functions to monitor across all VOs meaningfully.Discuss at the next M-VO meeting? Course of action may depend on how we/users plan on using the M-VO setup.
The text was updated successfully, but these errors were encountered: