Get Airflow working inside Navbar

[rtapella]

No description provided.

[rtapella]

@LucaCinquini what info do you need from us to configure Airflow to be happy with CORS requests from the navbar UI to Airflow?

Can we read the location from SSM?

[LucaCinquini]

Yes, the location is in SSM and @drewm-jpl can tell you which is the parameter to use. But I think the UI/UX team should try to include it in the NavBar and see what problems arise. As I mentioned earlier, I am not sure it is such a great idea to imprison Airflow within another site...

[drewm-swe]

To find the Airflow UI URL in a given venue, you can find it in an SSM parameter under this naming convention /unity/dev/sps/${DEPLOYMENT_NAME}/${DEPLOYMENT_COUNTER}/processing/airflow/ui_url

[anilnatha]

@drewm-jpl My understanding of the param names is that it should follow something like /unity/{project}/{venue}/... but in that path you've shared, dev is hard coded into the SSM Param.

[drewm-swe]

@anilnatha Whoops, yes that's correct the venue is parameterized in the SSM parameter name as well.

/unity/{venue}/sps/${DEPLOYMENT_NAME}/${DEPLOYMENT_COUNTER}/processing/airflow/ui_url

Currently, project and venue are combined so the SBG dev SSM parameter would appear like this:
/unity/sbg-dev/sps/${DEPLOYMENT_NAME}/${DEPLOYMENT_COUNTER}/processing/airflow/ui_url

There doesn't appear to be guidance on the gitbook docs on how to handle the project/venue combo but that's what we have currently.

[anilnatha]

@drewm-jpl Thanks for the clarification and addressing my concern.

@galenatjpl Could you please point us to the documentation on how to handle the SSM param naming convention with regards to project and venue. IIRC, it was something like /unity/{project}/{venue}/... but I want to make sure this is accurate.

[galenatjpl]

@anilnatha I think we are now settling on /unity/{project}/{venue}/.. (see the "Name Form" section here: https://unity-sds.gitbook.io/docs/developer-docs/common-services/docs/users-guide/deployment/deployment-concepts-and-infrastructure/unity-ssm-parameters/ssm-parameter-naming-requirements-and-conventions).
I think at a minimum we need to stick with the /unity/{project}/{venue}/.. convention, so that proj/venue deployments will know what params explicitly apply to them.

[rtapella]

@anilnatha please work with @drewm-jpl to update this (e.g. use the health json landingPage URL?) or otherwise get a URL to try out to test this... (assuming the CORS stuff will work)

[GodwinShen]

@anilnatha and @rtapella ping for status. Is this still blocked?

[rtapella]

Once Airflow is deployed with the new URL structure, we can test this out—that will/should avoid CORS issues. Initially we'll just use the URL from the Health Status info for each app.

[rtapella]

@LucaCinquini @drewm-jpl we will need the Airflow health-endpoint URLs to have the MCP URL
then it should show up in the navbar and work properly

[anilnatha]

@LucaCinquini Please add sub-issues to this Epic as needed to address the tasks needed to get Airflow accessible from the navbar (aka portal)

[LucaCinquini]

So do you simply need a link to the Airflow URL? Isn't that accessible already through the Health Check endpoint?

[anilnatha]

We're good on the Airflow URLs being provided in the health API endpoint response, but when Airflow is accessed via the portal, there is an error.

Blocked loading mixed active content “http://www.dev.mdps.mcp.nasa.gov:4443/unity/dev/sps/home”

[LucaCinquini]

Are you trying to display Airflow in an embedded window? Otherwise, the URL works just fine.

[anilnatha]

Yup, that's exactly what we're trying to do.