Catalog communicates directly with Registry instead of the director

[pcrespov]

• move functionality to communicate with the registry to the catalog
• use cache mechanism in the catalog to store some of the service metadata/attributes

SEE #6657 (comment)

[GitHK]

subscribing here for progress as I am interested to this for future refactoring

[pcrespov]

@sanderegg I was wondering... is there any reason why we do not add all metadata info in the image labels as a columns in services_meta_data?? in particular I am interested in inputs and outputs.

[sanderegg]

@pcrespov why would you want to do that? these are static and in the images. the reason is simple, if you duplicate them, then you will have to take care of maintaining sync between the database and the images. we have seen how that goes already with files. not sure I see the advantage. is it for performance?

[pcrespov]

@pcrespov why would you want to do that? these are static and in the images. the reason is simple, if you duplicate them, then you will have to take care of maintaining sync between the database and the images. we have seen how that goes already with files. not sure I see the advantage. is it for performance?

@sanderegg i was curious because we already store a part of that metadata and we already have a sync worker for it. that was the main reason.

NO, it was not about performance. IMO that will improve as soon as we have the queries to the registry in the catalog :-)

[sanderegg]

@pcrespov tbh I am not sure the performance will improve that much. the director-v0 is already caching that information. actually the slow part is the validation of the data, which is already done in the catalog.
and the metadata, only the metadata that can be modified is in the database at the moment. I would prefer making use of aiocache instead and it can leverage redis