-
Notifications
You must be signed in to change notification settings - Fork 965
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
feat: generalize application model (+ add databricks application support) #1398
feat: generalize application model (+ add databricks application support) #1398
Conversation
23f8589
to
849a7e6
Compare
849a7e6
to
05328ae
Compare
4e0cf63
to
7cd8f04
Compare
Do you think there is a way to refactor this class so no coding is required to introduce another app? I think only thing that would need to be done is figuring out how to render keys but apart from that it would be much user friendly and scalable. Btw shall we introduce new icon for databricks app? |
@mgorsk1 Yeah so this was kind of my dilemma while doing this. I did introduce a new logo for Databricks in this PR (HERE). I don't think it would be very hard to make this open to any kind of app but then the UI rendering would just show up with no icon? Is that ok? Are there any other instances of this happening? I think what I would do is leave all of the Airflow specific things for backwards compatibility and then have a new template for any other type of app. I would definitely vote for this route as long as folks are ok with developer essentially being able to put in any kind of app. We could also maybe log a warning message or something in their app doesn't have an icon. |
We can have a default icon for when the app doesn't match supported ones. The same happens for tables if the database name doesn't have matching icon. +1 for making generic design for anything except Airflow. |
@mgorsk1 Cool this is super helpful. I did not know this. I will refactor this PR to be generic but freeze the Airflow constructs already in place for backwards compatibility 👍. Will reach out for a review when it is ready. |
make sense to make the application more generic to support other workflow type including databricks job/prefect etc. @jroof88 I am curious how you link the databricks job with the table. I did something similar for databricks which requires some internal usage tracking(not visible external). |
@feng-tao My plan is to link the amundsen table to the databricks ETL job that writes to the table so it's is easy for folks to go from table to job without have to naviagate/search the databricks jobs ui |
Is it through manual mapping? |
7cd8f04
to
98cca58
Compare
@feng-tao We have code that parses our databricks jobs via the api and then can map the links to specific tables yes |
e18a212
to
9245807
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.
one nit but lgtm
|
||
# The Application model was originally designed to only be compatible with Airflow | ||
# If the type is Airflow we must use the hardcoded Airflow constants for backwards compatibility | ||
if self.application_type == 'Airflow': |
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.
just to be 200% sure can we do if self.application_type.lower() == 'airflow'
?
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.
Yup! Done ✅
Currently the Application model isn't very usable to anyone who doesn't use Airflow. This commit generalize the model while also freezing current Airflow logic into place for backwards compatibility. I update docs and tests as well to make sure it works properly. Signed-off-by: jroof88 <jack.roof@samsara.com>
Signed-off-by: jroof88 <jack.roof@samsara.com>
Bump databuilder minor version to pick up new application changes Signed-off-by: jroof88 <jack.roof@samsara.com>
Bump frontend minor version to pick up new databricks application logo rendering Signed-off-by: jroof88 <jack.roof@samsara.com>
9245807
to
15b0d4a
Compare
In amundsen-io#1398 we generalized the Application model to be any application not just airflow. In that PR, I removed a arguement to the init for the model. This broke the sample data loader but it could also break peoples workflows who are already using Application model. This commit brings the arguement back.
In amundsen-io#1398 we generalized the Application model to be any application not just airflow. In that PR, I removed a arguement to the init for the model. This broke the sample data loader but it could also break peoples workflows who are already using Application model. This commit brings the arguement back. Signed-off-by: jroof88 <jack.roof@samsara.com>
…ort) (amundsen-io#1398) Signed-off-by: jroof88 <jack.roof@samsara.com>
…ort) (amundsen-io#1398) Signed-off-by: jroof88 <jack.roof@samsara.com>
Summary of Changes
Currently the Application model isn't very usable to anyone who doesn't use Airflow. This commit generalize the model while also freezing current Airflow logic into place for backwards compatibility. I update docs and tests as well to make sure it works properly.
I also add a databricks logo for rendering databricks applications nicely on the frontend :)
Tests
I refactored the tests in
test_application.py
to allow for multiple test cases and added proper testing for the databricks model typeDocumentation
I updated the model documentation to remove the concept Airflow only support
CheckList
Make sure you have checked all steps below to ensure a timely review.