Skip to content
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

Refactor rest - part 2 #322

Merged
merged 50 commits into from
Apr 1, 2022
Merged

Refactor rest - part 2 #322

merged 50 commits into from
Apr 1, 2022

Conversation

mmacata
Copy link
Member

@mmacata mmacata commented Mar 18, 2022

See also MR #320 and issues #190, #189 and #191

General refactoring thoughts:

This PR splits up the rest modules into:

  • the class used with flask which stays in the existing rest module
    For raster_colors e.g. class SyncPersistentRasterColorsResource(ResourceBase)
  • the classes used for processing, separated into persistent and ephemeral processing as well as ephemeral_with_export and ephemeral_renderer_base. They are moved to processing.actinia_processing. Perspectively this will become a separate repository.
    For raster_colors e.g. class EphemeralRasterColorsOutput(EphemeralProcessing) and class PersistentRasterColorsRules(PersistentProcessing)
  • the methods in between which are used to write processing jobs into the queue and then to read from it are moved to processing.common
    For raster_colors e.g. def start_job_colors_out(*args) and def start_job_from_rules(*args)

Effects on the queue (local / redis)

Regarding the queue - the methods in between mentioned above can be used in 3 different ways:

  • in the job receiver with QUEUE_TYPE = local. Here, actinia_processing is needed. If the import fails, actinia won't start up with ModuleNotFoundError: No module named 'actinia_core.processing' - No actinia_processing found but required for local queue! [in /usr/lib/python3.8/site-packages/werkzeug/_internal.py:113]
  • in the job receiver with QUEUE_TYPE = redis - import doesn't matter as no processing done here
  • in the job executor. actinia_processing is the essential part and import is highly relevant.

One note about sorting inside actinia_processing

The modules are sorted by inheritance into the subfolders

  • ephemeral,
  • ephemeral_with_export,
  • persistent and
  • ephemeral_renderer_base.

This means eg. that the module persistent_processing.py is inside the folder ephemeral because it inherits from EphemeralProcessing directly: class PersistentProcessing(EphemeralProcessing). The module ephemeral_processing, from which all other classes inherit directly or indirectly, is on top level next to the folders.

WARNING

Last thing: again a WARNING that some actinia plugins are affected by move of

  • ephemeral_processing_with_export
  • ephemeral_processing
  • persistent_processing

Alle of them are adjusted with these PRs:

@mmacata mmacata marked this pull request as ready for review March 25, 2022 14:03
@mmacata mmacata mentioned this pull request Mar 25, 2022
@mmacata mmacata requested review from anikaweinmann, marcjansen, metzm and neteler and removed request for anikaweinmann March 25, 2022 14:08
Copy link
Contributor

@metzm metzm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many substantial changes, therefore I suggest to merge rather soon and fix any issues in separate PRs.

@mmacata
Copy link
Member Author

mmacata commented Mar 31, 2022

I agree. I kind of wait for a fix of #332 to have a running actinia when all of these MRs are merged to be able to see directly if anything is not running smoothely.

@mmacata mmacata merged commit d9b9f11 into actinia-org:main Apr 1, 2022
@mmacata mmacata added this to the 4.0.0 milestone Nov 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants