Manageiq: Extract model decorators into a separate repository

[skateman]

Decorators are currently living in the manageiq-ui-classic repo, however, if we would like to use them in the REST API, it would be more convenient to extract them into a separate repo. This way we can use them without depending on the UI.

• [x] Create the manageiq-decorators repository from this
• [x] Include the manageiq-decorators into the core Gemfile https://github.com/ManageIQ/manageiq/pull/18360
• [x] Delete the decorators and their related assets from the UI https://github.com/ManageIQ/manageiq-ui-classic/pull/5158

@miq-bot add_label gaprindashvili/no, enhancement
@miq-bot assign @skateman

[skateman]

ping @martinpovolny @himdel

[Fryguy]

So, I have a high-level question, but what do you need from this repo that you would use in the API? Most of the decorators I sporadically looked at have patternfly classes, which feels very UI specific.

[Fryguy]

Additionally, I think we should extract the directory with history. It's pretty straightforward with git-filter-branch, since there are only really 2 directories or so.

[skateman]

@Fryguy everything inside the decorators is UI-specific. Imagine for a second that we have a fully API-driven UI and you're asking for a record to render a provider's summary screen. All the different providers (based on what STI model they are in and on other circumstances) can have different icons/images/quadicons. I would like to equip the API with the ability to tell the UI about these things.

I never used the git-filter-branch, but most of the decorators are kinda new and a lot of bad practices have been dropped from the codebase. So I'm not sure if we want to keep the history cc @martinpovolny

[Fryguy]

a fully API-driven UI

The SUI was a fully API driven UI and didn't need this from what I can tell, so I still don't see the usage. While I understand the goal of getting everything over the API, APIs are generally more data driven and don't care about presentation. So, I'm still not understanding the expected usage of this.

All the different providers (based on what STI model they are in and on other circumstances) can have different icons/images/quadicons.

Perhaps I misunderstand, but I would expect that the plugins would each provide their assets, but only provider specific ones (like the EMS icon). The "common" assets would be part of the UI layer, and don't need to query the API to know, for example, the structure of a quadicon for a VM. For provider specific assets like the EMS icon, I would expect an attribute on the EMS, but it would like be a simple string, like "redhat", and then I would expect the UI to have a method that would transform that string into an image path or something, like "packs/redhat_icon.svg"

[skateman]

The SUI was a fully API driven UI and didn't need this from what I can tell, so I still don't see the usage.

That's correct, but the number of features is not comparable with the OPS UI. We're not displaying that many resource types there and none of the complex stuff.

that the plugins would each provide their assets

I wish we could be already there :pray:

For provider specific assets like the EMS icon, I would expect an attribute on the EMS, but it would like be a simple string, like "redhat", and then I would expect the UI to have a method that would transform that string into an image path or something, like "packs/redhat_icon.svg"

SUI currently does this, but it's usable only for some specific resources that the SUI deals with. It's not always so trivial what kind of icon/image to render for a resource.

I'm creating a document where I'm describing the concept behind this a little bit more detailed.

[Fryguy]

I'm creating a document where I'm describing the concept behind this a little bit more detailed.

That would be great! Can you put it in https://github.com/ManageIQ/manageiq-design as an RFC?

[juliancheal]

@skateman This is my code extractor project https://github.com/juliancheal/code-extractor and an example of it when I extracted the provider code https://github.com/juliancheal/manageiq-provider-extractions

[skateman]

As @Fryguy the document is available here

[abellotti]

Interesting discussion, my initial thinking is Model & API are the data layers, and feel this should stay that way. It sounds like we need a data -> presentation mapping layer, the above decorators can still be moved out but would be consumed by that layer, not the Model/API one. Model/API saying this is type X, or Y, (text prefix string, class, etc) mapping layer saying for X we need Decorator dX, etc. UI can then fetch the appropriate decorators (probably prefetched/cached) needed in the mapping layer for the presentation side of things. Maybe extending what SUI had, but supporting Decorators above and honoring provider plugins hierarchies. my 2 cents.

[martinpovolny]

Include the manageiq-decorators into the core Gemfile #17676

@Fryguy, @abellotti : as seen in the description @skateman created a rails engine with the decorators. Any further thoughts on this? Or other suggestions how to move this forward?

[skateman]

From the API side we could add an URL parameter that specifies the decorated fields, to request e.g. &decorate=fonticon,fileicon,quadicon. If this parameter is not set, the decorate method would not be even called.

[martinpovolny]

@Fryguy, @abellotti : as seen in the description @skateman created a rails engine with the decorators. Any further thoughts on this? Or other suggestions how to move this forward?

Can @skateman proceed with creating the repo and extracting the decorators?

[Fryguy]

@skateman and I spoke about this, and we are moving forward with it. In the ideal case, we would not need this repo, because the API would be changed to return all of the necessary info, and then, given the UI is completely API driven, it could convert the data from the API to the appropriate styles and images. However, it will take a while to change the API to have all of the data, as well as change the UI to consume that new data regardless of the fact that the UI is not even 100% API driven. So, this repo is more of a "temporary, but likely long term" approach, and I am ok with that.

The new repo has been created at https://github.com/ManageIQ/manageiq-decorators. I will be doing the repo dance to add the services later today.

[Fryguy]

Since all of the checklist items are complete, I am deeming this done.