nicolaferraro commented on issue #1059: camel-k installation struggles URL: https://github.com/apache/camel-k/issues/1059#issuecomment-557563935 > > @davesargrad Cool that you fugured out the error, yes the docker registry ip was supposed to be in NO_PROXY list, and sorry for the late reply as I was in a different time zone so I couldn't see your messages. > > I think it will be really good if you can contribute all the steps as a guide to run camel-k behind corporate proxy. > > Hi @asifdxtreme > > I would be more than happy to document the steps I took. I'll do that with care over the next couple of days, and then I'll post it to this issue. > > Though I've not heard you guys say this, I think the "kamel" installation process may ultimately be replaced by an operator based installation process (operatorhub.io). Is this the plan? > > I do have one last issue that I'm trying to get past. To the extent that a camel component that is not in camel-core is needed by a route that I am building, what is the proper way to declare this maven dependency, and to ensure that the dependency jar is placed in the proper repository? I think the corporate proxy, and the vanilla k8s may add some wrinkles to the answer. > > I've found [one issue](https://github.com/apache/camel-k/issues/30) that seems to relate to this question. This issue references camel-mail as a camel component that is not in the camel-core used by camel-k. > > Perhaps you can help me to answer this. I think this will create one more wrinkle relative to working behind a proxy, with a vanilla k8s/docker distribution on centos7. > > Yesterday I was able to get the simplest integration running, but i quickly ran into additional problems when i tried one of the other examples ([restwithrestlet](https://github.com/apache/camel-k/blob/master/examples/RestWithRestlet.java)). That integration complained about not being able to find the restlet component. > > I was also looking for other examples that might use something such as [camel-mail](https://camel.apache.org/components/latest/mail-component.html). Any example that allows me to push the integration platform further, so that i can be sure that i've covered all the cases that might be of interest. > > Any suggestions/guidance would be appreciated. The `kamel` installation will remain because it's handy. Everything that can be installed via `kamel` can be also installed via operator already. The problem is that when you install via operator, you need to add additional configuration on the `IntegrationPlatform` resource, and that is not so user friendly as the CLI, because the current UI does not allow to put something that helps the user. The only place where the operator installation works with the default examples is OpenShift, because it has an internal registry that we automatically use to push images, so an empty `IntegrationPlatform` is ok. When you are outside Openshift, the operator does not know where to push images and you need to instruct it via the integrationplatform resource. If you take your current `IntegrationPlatform` with `k get integrationplatform camel-k -o yaml` and you use it during installation from operator hub, you should be able to do a full installation without kamel.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
