-
Notifications
You must be signed in to change notification settings - Fork 85
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
Option to use UAT environment #421
Comments
Should we support manually overriding the EDL base URL to anything? That way we can support other existing environments like System Integration Testing (SIT), and any others that may be created in the future. |
Supporting SIT would be great too! It might be more secure/simpler to just allow UAT/SIT/PROD for now? |
Currently, one of the options for earthdata.login(strategy="environment", environment=Env.UAT) Using "environment" twice where it means two different things looks strange, right? Would "endpoint" perhaps be a better name for the new keyword argument? Other suggestions? |
"maturity" is generally how I think about UAT/SIT/PROD, but "cmr_endpoint" is a good option as well (just endpoint makes me go "to what?") |
nice, I like "cmr_endpoint" too |
I've started working on this issue but could use some more expert eyes to ensure an appropriate token is available when using UAT. Specifically, my question is: Will the |
Yeah, we'll need different client IDs for each environment. This comment from a few lines up is prescient:
The URLs all repeat the hostname too, so maybe instead of
We would rather store
and concatenate these values with the variable hostname. EDIT: Thinking a bit about this, the variable defined just above is what I think of when I think "endpoint", so maybe that's not an ideal term for UAT/SIT/PROD... 🤷 |
Thanks @mfisher87. Then it seems like two questions remain...
earthdata.login(strategy="environment", cmr_environment=Env.UAT) How does that look? |
|
I'm realizing something after seeing the suggestion |
Yeah, I've been thinking of this argument as something that will change both EDL and CMR. Not just one or the other independently. Could be I'd also be happy with |
I'm actually just not sure where to find the Client ID value to use for UAT. Is a Client ID something I can find on some Earthdata page now — or, do we need to create a new Earthdata Application (in UAT, and then again in SIT)? |
I don't know if any "application" (that term always throws me off when it refers to an integration) was created for UAT/SIT. @betolink I think would know. Either way, while we're in there we should ensure all earthaccess maintainers are admins of all the EDL integrations :) |
@betolink, do you know the answer to the above question about the Client ID? |
Sorry for the delayed response @danielfromearth, I think we can ignore I like what you suggested earthdata.login(cmr_environment=Env.UAT) Or perhaps using a then earthaccess will do something similar to what's already doing:
|
After a bit of digging, I see that we require a client_id when we request a user's profile. However, why are we including a function to get a user's profile? I just submitted a question to EDL support regarding the need for a client_id because the documentation does not appear to align with the behavior:
However, we are using an access token, not a user token, so the documentation implies to me that we should not need to supply client_id. Unfortunately, this is not the case. When not including client_id (a valid one), I get this error:
So I see the following options for us:
|
@chuckwondo, your question about why resonates with me — and the third option sounds reasonable, but I don't really know what the range of considerations would be. (Should we move this |
I see the problem. I incorrectly assumed we use access tokens because when I look at the auth token the key is
We cannot move the client_id question to a new issue because your PR won't work in UAT without a registered app in UAT so that we can obtain a client_id appropriate for UAT. The existing client_id works only in PROD. We either create a UAT app to get a client_id (we should do the same for PROD too, but that might have other ramifications, which we might want to create a separate issue for), which then means we also need to move client_id to our new System class, OR we get rid of |
I think @danielfromearth already tested this in UAT and seemed to work. I'll test with some NSIDC UAT-only datasets and report back. I think the EDL documentation states that it shouldn't work but it does. I'd say we leave it like this for now and we open a new issue to register earthaccess as a client on its own. |
No,
|
Ah OK, I was talking about the search and access part not the |
We could, but that goes back to my other question. Why do we have |
If we can eliminate |
I thought we used it for the tokens but that's not the case, I feel we'll need it in the future but for now we can eliminate it. |
and what about a release after this PR? |
My only concern would be the possibility of this being a breaking change since However, I would be surprised if anybody uses that method, so I'm willing to risk pulling the method. |
Sure, sounds reasonable to me. |
@betolink, @mfisher87, @jhkennedy, any concern here with removing |
no concerns, we should get a |
Great! @danielfromearth, please remove use of Once that's done, I'll take one final (hopefully!) look at your changes so we can finally land your work. Thanks so much for your perseverance and patience! |
@danielfromearth 💯 this :) That PR had a lot going on, amazing work making this feature happen. And for the idea in the first place! @chuckwondo amazing work asking important questions along the way! |
Challenge
earthaccess
does not currently support access to collections that are in NASA Earthdata's User Acceptance Testing (UAT) environment. Instead, the production (PROD) environment is assumed when logging in viaearthaccess
and there is no option to change the environment.Desired functionality
When executing the
earthaccess.login()
method, an option to specify which environment should be available. And the authentication should be correctly applied to the specified environment.Example
I encountered this challenge when trying to test data transformation code with a data collection for the Tropospheric Emissions Monitoring of POllution (TEMPO) instrument that is in UAT. I would like to search and download granules from this collection using
earthaccess
, but that is currently not possible.Benefit
If the UAT environment can be accessed with
earthaccess
, its usability would be expanded to more dataset testing.The text was updated successfully, but these errors were encountered: