Skip to content
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.

Sign up for GitHub

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

Jump to bottom

install: optional registry #2358

Closed
lburgazzoli opened this issue Jun 4, 2021 · 6 comments
Closed

install: optional registry #2358

lburgazzoli opened this issue Jun 4, 2021 · 6 comments

Comments

@lburgazzoli
Copy link
Contributor

lburgazzoli commented Jun 4, 2021 •
edited by astefanutti
Loading

camel-k installation tries to determine a registry and may fail if it does not find one.
in some environment, camel-k is not supposed to perform any build so we should have an option to make the registry optional
@phantomjinx
Copy link
Contributor

Current plan:

  1. kamel install already contains a --registry switch so if this is set to none then the user can flag no registry
  2. If o.Registry.Address == none then find the building trait in the catalog, copy, disable it then add it to the IntegrationPlatform
  3. Try a kamel run ... (& write tests) to prove that a build cannot be attempted and the empty Registry{} never used

@phantomjinx
Copy link
Contributor

phantomjinx commented Jun 9, 2021 •
edited by astefanutti
Loading

Latest implementation carries through the --registry none and implements 3 changes:

  • platform.Spec.Registry.Address = Disabled
  • platform.Spec.BuildPublishStrategy = Disabled
  • platform.Spec.BuildStrategy = Disabled

This seemed logical since the registry is required for BuildPublishStrategy and since one of the active types of BuildPublishStrategy are required for BuildStrategy. If this is not correct then can you provide an example please?

If it is correct, can you provide a use-case where the operator is useful without any build capability, please?

thx.

cc @lburgazzoli @astefanutti

@astefanutti
Copy link
Member

Latest implementation carries through the --registry none and implements 3 changes:

  • platform.Spec.Registry.Address = Disabled
  • platform.Spec.BuildPublishStrategy = Disabled
  • platform.Spec.BuildStrategy = Disabled

This seemed logical since the registry is required for BuildPublishStrategy and since one of the active types of BuildPublishStrategy are required for BuildStrategy. If this is not correct then can you provide an example please?

That is correct.

If it is correct, can you provide a use-case where the operator is useful without any build capability, please?

The use case it to run an Integration using a pre-built image. Obviously, this pre-built image has to comply with the Camel K runtime contract (that is not documented ;). As an easy way to write an e2e test for this, I think we could re-use any existing test, and add a subsequent test that would re-deploy the same Integration, by re-using the previously built image, and make sure both the operator installation and the Integration Pod run successfully.

phantomjinx added a commit to phantomjinx/camel-k that referenced this issue Jun 29, 2021
@phantomjinx
apache#2358: Allow for an optional registry
dff6334 
* When installing on a non-openshift cluster, allow for possibility of
  installing without a registry being present.

* Implies that no building of components can happen but running of
  existing integrations and kits can

* e2e tests for installation and running

* Extend API to include constants for Disabled states

* install.go
 * If --registry none is specified then setting the registry address to
   disabled

* operator.go
 * If regsitry Address is disabled then seting both Publish and Build
  strategies to disabled (if not on openshift)

* defaults.go
 * Avoid configuring registry is disabled

* Controllers and Actions
 * Integration controller checks on integration kit and if latter is in
   state "Cannot Build" then Error
 * Integration kit controller executtes build action but if platform is
   disabled then returns early in state "Cannot Build"
 * "Cannot Build" differentiates from "Error" since error action can
   put the integration kit back to initialization phase to try and build
   again. This makes no sense for "Cannot Build" cannot build

* Makefile
 * Allow the image to be overridden on the command line using an Env Var.
@phantomjinx
Copy link
Contributor

phantomjinx commented Jun 29, 2021 •
edited
Loading

PR -> #2464

@phantomjinx phantomjinx mentioned this issue Jun 29, 2021
Closed
phantomjinx added a commit to phantomjinx/camel-k that referenced this issue Jul 12, 2021
@phantomjinx
apache#2358: Possible to skip configuring of registry when installing…
97ce6dd 
… via cli

* install.go
 * Use of --skip-registry-setup switch will bypass all configuration in
   relation to the registry and leave a blank structure in the newly
   installed platform

* Includes tests

* Makefile
 * Makes the IMAGE_NAME and VERSION overrideable on the cli
@phantomjinx
Copy link
Contributor

phantomjinx commented Jul 12, 2021 •
edited
Loading

New PR -> #2497

merged

nicolaferraro pushed a commit that referenced this issue Jul 16, 2021
@phantomjinx @nicolaferraro
#2358: Possible to skip configuring of registry when installing via cli
8f917ee 
* install.go
 * Use of --skip-registry-setup switch will bypass all configuration in
   relation to the registry and leave a blank structure in the newly
   installed platform

* Includes tests

* Makefile
 * Makes the IMAGE_NAME and VERSION overrideable on the cli
@astefanutti
Copy link
Member

It's been fixed with #2497.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@astefanutti @phantomjinx @lburgazzoli