New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Arquillian OpenShift] Creates an integration with Fabric8 plugin #806

Closed
lordofthejars opened this Issue Sep 13, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@lordofthejars
Member

lordofthejars commented Sep 13, 2017

Issue Overview

Creates an integration with Fabric8 plugin because when Fabric8 maven plugin is run it takes the default namespace configured (or the one that it is active in oc configuration) and do some stuff like creating ImageStreams or configuring builds.

The problem is that when running with Cube, you need to specify the namespace where Fabric8 has done all the configuration steps. That's fine in most cases, but if you want to use the random namespace generation provided by Cube, then the test will fail because this namespace created by Cube was not the one configured by Fabric8.

Expected Behaviour

The solution would be integrating Fabric8 plugin with Cube by either:

  • we can re-use logic of fabric8-maven-plugin to generate those files create s2i image and register it in openshift registry this can be done under the hood based on e.g @AutogenerateOpenshiftResources annotation put on the test class
  • we can provide Shrinkwrap descriptors so you can either create default files like fmp does but also open it up for customization "shrinkwrap style "this would mean we have to flesh out what kind of @Deployment methods we would like to have to make it simple and powerful enough

My recommendation would be as first try, the first approach.

Current Behaviour

No integration

Additional Information

This bug comes from #743

@iocanel

This comment has been minimized.

Contributor

iocanel commented Sep 19, 2017

I think that now that we allow resources to refer to objects in their original namespace, problem is almost solved. Still, it would be better if we could have everything created or copied inside the test namespace.

I am wondering if we can use the same approach and just copy the refereed objects over.
So, all we need is a PathAwareTypedVisitor for ObjectReferenceBuilder and through it navigate up the object graph via getParent() until we reach a top level object (anything that's instance of KubernetesResource. Then we could just copy the object, by building it and adding it to the list of resources we need to install.

I'll try to make a quick poc.

@lordofthejars

This comment has been minimized.

Member

lordofthejars commented Sep 19, 2017

The problem I see is that if you copy everything then maybe you are copying something that you don't want (maybe because it was already there before).

@iocanel

This comment has been minimized.

Contributor

iocanel commented Sep 19, 2017

Cross namespace references will definitely not be there. But even if they are (by a previous run in a non-ephemeral namespace) we can control what we want to do (recreate, reuse, fail).

@lordofthejars

This comment has been minimized.

Member

lordofthejars commented Sep 19, 2017

Ok great, I was just pointing out some cases that came to my mind :)

dipak-pawar added a commit to dipak-pawar/arquillian-cube that referenced this issue Mar 13, 2018

dipak-pawar added a commit that referenced this issue Mar 28, 2018

@dipak-pawar dipak-pawar added this to the 1.15.3 milestone Apr 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment