-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Namespace registry admin #462
Namespace registry admin #462
Conversation
viper.Set("Registry.DbLocation", registry_db_dir) | ||
|
||
err := InitializeDB() | ||
assert.NoError(t, err, "error initializing registry database") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a request for change, but more my own curiosity -- across our tests, I've noticed we switch back and forth between require.NoError
and assert.NoError
. Have you found a good reason to pick one over the other?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I looked this up as it seems to be personal preference. There is a minor difference. Basically, require
will cause a test to quit and exit immediately, which may be what we want more often, but with go routines, it can cause some issues.
To quote someone else:
"However, if the test has goroutines, we need to be careful that the test waits for goroutines' completion. Otherwise, the test errors get buried/missed; leaving you wondering why a test case failed!"
b71062d
to
5d57251
Compare
5d57251
to
75deece
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few small things and a rebase, and then I think we're good to go!
-- Admin metadata now contains a json string representing admin approval -- Admin approval is set the false by default -- When verifying whether a cache can advertise to the director, the namespace_registry first checks to see if the cache has admin approval
-- Fixed check of namespace existence for caches -- Refactored tests -- Fixed warning sent due to cache advertise failure due to lack of admin approval
…pace -- Added a getNamespace endpoint for registry 2.0 that returns a namespace of the prefix if it exists -- Added a metadata prefix to the wildcard auto-discovery to get around conflicts -- changed all current access to 2.0 api (as opposed to 1.0, which we are still keeping for backwards compatability)
-- Renamed boolean in dbGetJwks to be more accurate
-- Switched out integers for actual http errors -- Created an adminApprovalError for use in cache endpoints -- Adjusted prefix header to be the same style as the rest of our pelican headers -- Added some clarifying comments -- Returns the name of the unapproved cache as part of the error message
a546c47
to
8d30a3b
Compare
This adds a requirement for admin approval before a cache can advertise to the director.
Currently there is no endpoint to approve caches, but the registry database can be altered via sqlite with the following commands after the cache has been created with
pelican cache serve
:run sqlite
There will be a list of origins and caches that looks like this:
Then run the following with
1
replaced by whatever id is in the id column of the cache you wish to approve