-
Notifications
You must be signed in to change notification settings - Fork 352
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
Running without a platform #1047
Milestone
Comments
+1 |
This is especially useful when you install camel k globally (and also knative sources). Once you do it, people can create those objects from the OCP console in any namespace and see them running. |
+1 (best choice for knative usecase) |
Let's move this to milestone 5. |
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 3, 2019
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 3, 2019
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 4, 2019
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 4, 2019
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 4, 2019
lburgazzoli
pushed a commit
that referenced
this issue
Dec 5, 2019
lburgazzoli
pushed a commit
that referenced
this issue
Dec 5, 2019
lburgazzoli
pushed a commit
that referenced
this issue
Dec 5, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some people don't like the fact that you have to create a platform before being able to run an integration, especially in contexts like OpenShift where you don't need to provide any special configuration but you can use the default one as all parameters are automatically discovered.
Can we think to generate a default platform in contexts where the default one can work?
The text was updated successfully, but these errors were encountered: