Support runtime filtering

[quintesse]

It should be possible to filter out a specific runtimes in the frontend. This can be used by the runtime teams to showcase their work. Or to filter out runtimes that are not yet considered stable.

Filtering should be done both in the creator and in the examples flow.

As discussed in fabric8-launcher/launcher-creator-backend#179 this might better be a front UI feature instead of a backend one.

For Summit it would be enough to have a fixed configuration option (ENV var?) that filters out one or more runtime from all possible options.

As an additional feature it would be very useful to have this available as a dynamic option too (perhaps when you add ?runtime=xxx to the URL or whatever). If we don't have time to add the dynamic option before Summit we should split this feature of into a separate issue so we don't forget about it because the runtime teams really want this.

Edit: adjusted description because we need to be able to filter multiple runtimes, not just one

[quintesse]

Edited description because we need to be able to filter multiple runtimes.

We could simply use name,name,name (eg vertx,nodejs,springboot).

Btw, given the fact that they want to be able to do is filter out runtimes that are not stable yet (unstable, preview or beta) perhaps what we should do is add a property to the runtime metadata which we can use to filter on. (eg. RUNTIME_METADATA_FILTER=status===stable)

[quintesse]

So they're not really interested in that because what we might consider stable or not might not coincide with what our clients think is unstable. So a simple list of allowed runtimes should be enough.

[ia3andy]

@quintesse I guess this should be a backend feature then.

[ia3andy]

There may be a frontend one soon, to filter from the url, but that's another use case it seems..

[quintesse]

@ia3andy why should it be a backend feature? If we want to do dynamic filtering on the frontend anyway wouldn't it be much easier to say: either get the filter from the URL (dynamic) or from some configuration (static)?

[ia3andy]

@quintesse because we requesting those runtimes from the backend having an environment for this in the frontend would be really weird IMO. For example if you add of remove a runtime in the backend, or if you rename one.. to me it's totally backend directed. URL filtering is a bit different because you can adjust it depending on the content.

[ia3andy]

btw I don't think we will do url filtering per say. It will be more a way to have the interface with a fixed runtime (which can only be done in the UI).

[quintesse]

@ia3andy I'm not saying there should be an ENV var, it can be anything that can be configured, but if you are already going to do filtering in the frontend why implement it in the backend too? Then we need to implement the same thing in two places, I just don't see the logic behind that.

[quintesse]

@ia3andy when you say "I don't think we will do url filtering per say", do you already have an idea of how you'd do it?

[edewit]

@quintesse why wouldn't we put all these filter options in the backend (url and env)? That way we don't have to request data that the user is not going to need and we have similar filtering options in the launcher-backend

[ia3andy]

@ia3andy when you say "I don't think we will do url filtering per say", do you already have an idea of how you'd do it?

@quintesse yes having a field to filter runtimes is not really necessary until we have more of them. What would be great thought, as we talked about for Quarkus, would be to have a "fixed" runtime so the new application backend is already configured, and the user can only selectect the capabilities (he can't change the runtime). I was thinking it like this for https://github.com/fabric8-launcher/launcher-frontend/issues/1078

[quintesse]

@ia3andy Quarkus is not the only use-case. The runtime teams have been asking for ages to have an option where they can send users to https://developers.redhat.com/launch/login where they will only see a single runtime. They don't want to run their own Launcher like Quarkus. We should support both options which means having a dynamic filter option in the frontend.

@edewit because we want to support the option of having dynamic filtering. One user goes to https://developers.redhat.com/launch/runtime/vertx [1] and only sees Vert.x boosters and creator options while another going to https://developers.redhat.com/launch/runtime/springboot [1] only sees springboot. Users going to https://developers.redhat.com/launch still see all options.

[1] urls are just examples

Aren't we doing frontend filtering for the examples too? And the examples filtering is 20x more complex than the creator which is a very simple list of runtimes. Going to the backend to filter a list of, what, perhaps 10 elements?, just seems weird to me.

[ia3andy]

@ia3andy Quarkus is not the only use-case. The runtime teams have been asking for ages to have an option where they can send users to https://developers.redhat.com/launch/login where they will only see a single runtime. They don't want to run their own Launcher like Quarkus. We should support both options which means having a dynamic filter option in the frontend.

@quintesse when I said fixed runtime, I didn't mean only for Quarkus, it was just a good example since we talked about that just before.

@edewit because we want to support the option of having dynamic filtering. One user goes to https://developers.redhat.com/launch/runtime/vertx [1] and only sees Vert.x boosters and creator options while another going to https://developers.redhat.com/launch/runtime/springboot [1] only sees springboot. Users going to https://developers.redhat.com/launch still see all options.

https://developers.redhat.com/launch/flow/new-app/runtime/springboot

I like this idea, this is actually how I see it too for fixed runtime in the frontend.

Aren't we doing frontend filtering for the examples too? And the examples filtering is 20x more complex than the creator which is a very simple list of runtimes. Going to the backend to filter a list of, what, perhaps 10 elements?, just seems weird to me.

I don't see why Example filtering (by runtime) couldn't be done the same way in the backend by just giving a list of runtimes, I don't see why it would be a problem?

[quintesse]

I don't see why Example filtering (by runtime) couldn't be done the same way in the backend by just giving a list of runtimes, I don't see why it would be a problem?

It's not a problem, but why implement the same thing in two places??

[gastaldi]

I think it would be nice if we could have:

Launcher Creator Backend

1. an environment variable set in the launcher-creator-backend with a filter expression to restrict the available runtimes (that would meet the requirement @tqvarnst asked for in Support runtime filtering launcher-creator-backend#179).
2. (Optional - could be implemented in the frontend) an optional query parameter containing a filter expression to be used while calling the /enums endpoint to filter out possible runtimes

Launcher Frontend

1. Have some sort of URL pattern to invoke the /enums endpoint by passing a filter expression like mentioned in the item 2 above

[ia3andy]

@gastaldi yes I agree.

Regarding the frontend, I see it a bit differently, filtering isn't really needed because there is not a lot of runtimes. Here is what I have in mind:

• preselect backend with springboot: https://developers.redhat.com/launch/flow/new-app?backend=springboot,database,rest
• fixed springboot runtime (no runtime change possible, other runtimes are not visible): https://developers.redhat.com/launch/springboot/flow/new-app/
• fixed springboot runtime (no change possible) with db: https://developers.redhat.com/launch/springboot/flow/new-app?backend=database

[ia3andy]

So I see two features for the frontend:

1. ability to preselect some configuration for the new app in the url (runtime, capabilities, ...)
2. ability to define a reduce the launcher scope to one runtime in the url. The user won't see the other runtimes.

[gastaldi]

Since fabric8-launcher/launcher-creator-backend#179 is already implemented, I propose to move this out of the Red Hat Summit train. Thoughts?

[quintesse]

Isn't this something that could be very useful for the runtime teams? Especially for summit? Or not?

[gastaldi]

I agree it's useful for the runtime teams, but I am not sure they are expecting this specific feature by summit.

[quintesse]

Perhaps it's it something we can leave as "nice to have if there's time left"?

[gastaldi]

Right, so back to the backlog