OpenShift Marketplace/Hub

[roldancer]

Hi All, I would like to know if OpenShift Marketplace/Hub will be supported in the OpenShift Enterprise /Origin V3.0, we have several services with different plans that we want to expose via Marketplace.

Many thanks

[smarterclayton]

There will be no direct integration (from Enterprise or Origin) to the Marketplace when 3.0 is available. Hub integration will come a bit later, although OSE3.0 will have a built in hub that means organizations can publish their own content.

w.r.t. the marketplace, what integration are you looking for?

[roldancer]

HI @smarterclayton we would like to instantiate and bind corporate services from OpenShift V3, we are looking for something similar to Cloud Foundry service broker API http://docs.cloudfoundry.org/services/api.html, OSE V3.0 will have something similar?

[smarterclayton]

We've already started documenting how you bind external services here: http://docs.openshift.org/latest/using_openshift/integrating_external_services.html

As far as automatic provisioning, that's something we've been working upstream in Kubernetes on and so there should be an OpenShift/Kubernetes specific solution that allows pluggable provisioning of resources on demand. I don't think it will be part of OSE v3.0, but I expect to see something soon.

----- Original Message -----

HI @smarterclayton we would like to instantiate and bind corporate services
from OpenShift V3, we are looking for something similar to Cloud Foundry
service broker API http://docs.cloudfoundry.org/services/api.html, OSE V3.0
will have something similar?

---

Reply to this email directly or view it on GitHub:
#1612 (comment)

[roldancer]

Hi @smarterclayton , thanks for your response, but it is not exactly I'm looking for, I would like to see something automatic, I mean the ENV variables for the endpoints injected automatically by the PaaS runtime.

[smarterclayton]

That sort of automatic injection is on the roadmap, but not currently implemented. kubernetes/kubernetes#1768 tracks the underlying upstream issue with injecting and mutating the variables provided by a service. The extra environment for a service being injected is something we can track in this issue.

----- Original Message -----

Hi @smarterclayton , thanks for your response, but it is not exactly I'm
looking for, I would like to see something automatic, I mean the ENV
variables for the endpoints injected automatically by the PaaS runtime.

---

Reply to this email directly or view it on GitHub:
#1612 (comment)

[smarterclayton]

A design previously discussed was loading environment variables from a service (defined as annotations) when a deployment was calculated.

[palonsoro]

Yes. It would be interesting to automatically inject not only URLs but also other information from a service, such as credentials, only to containers consuming that service. Maybe the best way would be to define a variable (or group of variables) where a service can inject any kind of data to its consumers (thus, the content of that variable would be service-dependant).

[palonsoro]

On the other hand, what I think that should be interesting is having a catalog of service kinds, from which someone can provision and de-provision services. Those provisioned services would then be bindable to applications.

A very very concrete example would be: If I offer the "MySQL shared database" service kind, I would be able to:

• Provision a service of that kind: I create a new schema inside a shared MySQL instance.
• Bind an application to a service of that kind: I create an user for that application and inject its credentials, together with the connection information and the schema name, to the application.
• Unbind an application to a service of that kind: I remove the created user, as well as any tables created by that user and not accessible by anyone else.
• Deprovision the service: I would drop the schema as well as any created users.

This was a very concrete example but we should think in a much more abstract way. What 'provision', 'deprovision', 'bind' or 'unbind' means should be service-kind-dependent, although the way in which service information is injected to bound applications should be general (always the same environment variable, for example).