Re: [che-dev] How to apply devfile overrides in the REST API

[Maksim Shaposhnyk <mshaposh@xxxxxxxxxx>]

Not exactly answer to your question, but...

Given description clearly identifies the main problem - factory functionality is smeared with a thin layer over all of the product modules

and there is no single actor who is responsible for doing all the magic (this is probably a historical consequence of quick

adoptions for the new functionality without the architectural refactorings). Maybe it's good time to try to reformat it to the present-day needs
and try to do it more microservice-like.

Just my 2 cents....

Regards, Max.

On Fri, Nov 1, 2019 at 6:38 PM Lukas Krejci <lkrejci@xxxxxxxxxx> wrote:

Hello folks,

in the platform team, we've been discussing how to best apply the
devfile values overrides to the workspace being created using the
factory API or workspace API.

We're investigating this for the upcoming issue
https://github.com/eclipse/che/issues/13617 which wants to apply
overrides to various parts of the devfile coming to/through the factory API.

Quick recap of what factory and workspace APIs do:

Factory API "materializes" a URL into a fully contained devfile - e.g.
it tries to find a devfile on the supplied URL, fetches all the
referenced content and inlines it. It can also synthesize a devfile if
none is found on the supplied URL. Such devfile can then be further
worked on.

Workspace API actually creates a workspace out of a devfile.

Now, there are essentially 3 places where the overriding logic may reside:

1) the factory API applies the overrides during the "materialization" of
the devfile

2) workspace API applies the overrides before a workspace is created

3) the client (dashboard, chectl) applies the overrides on a
materialized devfile obtained from the factory before it sends it to
workspace API.

Each approach has its pros and cons and we realized we could not pick
the obviously best approach out of the three.

My take on this is that I'd rule out the variant number 3, because,
applying the same logic, the whole of the factory API could be done on
the client side. I am more inclined towards applying the overrides on
the workspace API though, because that increases the reusability of a
single devfile - the users don't have to have several variants of a
devfile on the filesystem and can create multiple different workspaces
out of it. Having such ability on the factory API would merely make it
easier to create such multiple variants.

On the other hand, usecase mentioned in
https://github.com/eclipse/che/issues/13617#issuecomment-531758905
would call for the overrides to be applied on the factory API so that
direct links to customized workspaces could be created.

What are your thoughts about the options?


Thanks,

Lukas

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

--

Max Shaposhnyk,

senior software engineer

Red Hat