Skip to content
This repository has been archived by the owner on Jul 23, 2020. It is now read-only.

Curate list of boosters/quickstarts to only contain those that actually will work within Che in openshift online #316

Closed
maxandersen opened this issue Jul 5, 2017 · 23 comments

Comments

@maxandersen
Copy link
Collaborator

No description provided.

@joshuawilson
Copy link
Member

To be clear, this is to remove those quickstarts that do NOT run on our build set or work in Che?

@maxandersen maxandersen changed the title Curate list of boosters/quickstarts to only contain those that actually will run in openshift online Curate list of boosters/quickstarts to only contain those that actually will work within Che in openshift online Jul 7, 2017
@maxandersen
Copy link
Collaborator Author

Ideal is to have only quickstarts that actually will deploy AND be possible to run the unit tests in Che (even if that means remove the tests)

@gastaldi
Copy link
Member

gastaldi commented Jul 7, 2017

So these are the boosters in https://github.com/openshiftio/booster-catalog right?

Let me know which boosters are valid and then I'll create a branch containing only the supported boosters (probably named che or something more intuitive - suggestions are welcome)

@gastaldi
Copy link
Member

gastaldi commented Jul 7, 2017

We'll have a meeting on Monday 10th to discuss about how to improve the booster-catalog, so although a different branch will resolve the issue for now, the strategy may will probably change depending on the outcome of the meeting.

@jstrachan
Copy link

so to fix this blocker for now we could just remove them all right ?

/me ducks :)

@gastaldi
Copy link
Member

gastaldi commented Jul 7, 2017

<sarcasm>
They all work in my local IDE
</sarcasm>

😃

@maxandersen
Copy link
Collaborator Author

so to fix this blocker for now we could just remove them all right ?

basically.

Here is a result of @ldimaggi running through them:

Vert.X basic - OK
Secured Spring Boot Tomcat - fail - fabric8-ui/fabric8-ui#1660
Secured Vertx - Rest & Red Hat SSO - fail - fabric8-ui/fabric8-ui#1664
Vert.x - CRUD - fail - fabric8-ui/fabric8-ui#1667
Vert.x - ConfigMap - OK
Spring Boot Basic - OK
Spring Boot - CRUD - fail - fabric8-ui/fabric8-ui#1668
Vert.x HTTP + ConfigMap - OK
Spring Boot - Health Check - OK
Wildfly CRUD - fail - fabric8-ui/fabric8-ui#1670
Vert.x Health Check Example - OK
WildFly Swarm - Config Map - fail - fabric8-ui/fabric8-ui#1671
Wildfly Swarm - HTTP - fail - fabric8-ui/fabric8-ui#1672
WildFly Swarm - Health Checks - fail - fabric8-ui/fabric8-ui#1673
WildFly Swarm - REST and RH SSO - fabric8-ui/fabric8-ui#1674

@ldimaggi can you confirm if you in this tested they work from within Che too or only wether they deployed ?

@maxandersen
Copy link
Collaborator Author

meeting on Monday 10th to discuss about how to improve the booster-catalog

I probably can't make it but could you add me on this as I would like to listen in to better understand the challenges.

@maxandersen
Copy link
Collaborator Author

We'll have a meeting on Monday 10th to discuss about how to improve the booster-catalog, so although a different branch will resolve the issue for now, the strategy may will probably change depending on the outcome of the meeting.

Btw to be clear: We absolutely need to get the list cut down to actually working on openshift.io quickstarts. If they don't work in the deploy phase nor when running tests in Che they are a waste of time for users on openshift.io to try out. Thus getting the list reduced to what actually runs by July 14th is of higher priority than fixing the quickstarts.

@l0rd l0rd added the team/che label Jul 10, 2017
@l0rd
Copy link
Collaborator

l0rd commented Jul 10, 2017

Note that due to a current limitation in OSIO, regardless of the booster/quickstart selected, the Che stack will always be the same one (plain java): fabric8-ui/fabric8-ui#1534

@ldimaggi
Copy link
Collaborator

And - in the unpaid account config, the user can have (1) Che workspace at a time.

@jstrachan
Copy link

So to be able to filter the list of boosters we display unfortunately thats all done inside the Obsidian code in io.openshift.launchpad.ui.quickstart.NewProjectWizard.initializeUI() where it does...

        List<Booster> quickstarts = this.catalogService.getBoosters();
        this.type.setValueChoices(quickstarts);
        if(!quickstarts.isEmpty()) {
            this.type.setDefaultValue(quickstarts.get(0));
        }

so we'll need code in NewLaunchpadProjectWizard here:https://github.com/fabric8io/fabric8-generator/blob/b2ad1f11db56c42c799ce7606d6f5cff78d8336b/src/main/java/io/fabric8/forge/generator/quickstart/NewLaunchpadProjectWizard.java#L50 to do something like...

    @Override
    public void initializeUI(UIBuilder builder) throws Exception {
        super.initializeUI(builder);
        Object boosterCatalogValue = getParentClassFieldValue("catalogService");
        if (boosterCatalogValue == null || !(boosterCatalogValue instanceof BoosterCatalogService)) {
            LOG.warn("Cannot find the parent `catalogService` field!");
            return;
        }
        Object boosterFieldValue = getParentClassFieldValue("type");
        if (boosterFieldValue == null || !(boosterFieldValue instanceof UISelectOne)) {
            LOG.warn("Cannot find the parent `type` field!");
            return;
        }

        BoosterCatalogService boosterCatalog = (BoosterCatalogService) boosterCatalogValue;
        UISelectOne boosterField = (UISelectOne) boosterFieldValue;
        List<Booster> boosters = boosterCatalog.getBoosters();
        // TODO filter out the list to only include the boosters we want to include...
        boosterField.setDefaultValue(boosters);
    }

@gastaldi
Copy link
Member

@jstrachan until we come up with the definitive solution, we can create a new branch in booster-catalog and add only the passing boosters so you guys can use them without any changes. WDYT?

@l0rd
Copy link
Collaborator

l0rd commented Jul 12, 2017

@ldimaggi @maxandersen to be clear mvn clean install works in Che (just tested Vert.X basic where mvn vertx:run works too).

For what I can see errors are related to the fact that file target/classes/META-INF/fabric8/openshift.yml cannot be found. But to generate that file you can mvn fabric8:resource from Che terminal. But that's not enough to solve the problem of running successfully OpenShiftIT test but I'm pretty sure we can figure out how to solve that problem too.

@maxandersen
Copy link
Collaborator Author

so we just need to have 'fabric8:resource' tied into the test lifecycle ?

@maxandersen
Copy link
Collaborator Author

@l0rd btw. when I run 'mvn' from terminal I get:

[user@che-ws-tkknzjp16lrpmu2b-64688052-643zf /]$ mvn
bash: mvn: command not found
[user@che-ws-tkknzjp16lrpmu2b-64688052-643zf /]$

@jstrachan
Copy link

OK here is our curated list of boosters we include: https://github.com/fabric8io/fabric8-generator/blob/master/src/main/java/io/fabric8/forge/generator/quickstart/ValidBoosters.java#L39

So if we find another booster that works - or one to remove - we can just make a PR on this file.

When we can refer to individual versions of boosters we can then add better automated CI pipelines to add/remove/upgrade individual boosters.

@l0rd
Copy link
Collaborator

l0rd commented Jul 12, 2017

@maxandersen

so we just need to have 'fabric8:resource' tied into the test lifecycle?

I don't know how we should run this test. What I can tell is that if I git clone and mvn -Dtest=OpenShiftIT test I have the same java.io.FileNotFoundException on my local bash too (so nothing to do with Che). But my point is another: should we really consider it a blocker? If mvn clean install, mvn test and mvn vertx:run work fine do we really need to log that problem in the kill list?

when I run 'mvn' from terminal I get

Weird. It works for me but that doesn't count :-) It works on @ldimaggi tests so maybe you are running an old version of Che?

@maxandersen
Copy link
Collaborator Author

Awesome @jstrachan

and @l0rd for now if we can't give users an end-2-end walkthrough that is somewhat error free that is considered a blocker.

But yes, it is not Che specific - it is the quickstarts that are faulty.

About Che being old, then status says I'm running 1.0.201 - is that old or new ?

@sbose78
Copy link
Collaborator

sbose78 commented Jul 12, 2017

@jstrachan
Copy link

@maxandersen the new filtered list is now live on prod.

Though it looks like a UI regression has kicked in breaking all combo boxes + kebab menus fabric8-ui/fabric8-ui#1726 so you can only pick 1 quickstart anyway right now ;)

@l0rd
Copy link
Collaborator

l0rd commented Jul 13, 2017

@maxandersen I'm able to reproduce your issue when trying to run maven in Che terminal:

bash: mvn: command not found

As a workaround I've scl enable rh-maven33 bash

That happens because the docker image used to run Che workspaces is rhche/vertx. Before it was rhche/centos_jdk8 but we need to figure what caused this change of stack.

By the way this problem should be solved by redhat-developer/rh-che#147 that is currently wip by @dharmit

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants