Consistent example applications about rails-ex HOT 21 CLOSED

@rhcarvalho I think this list is great, especially the readiness and liveness probes would be super useful for testing and deploying.

Important difference between 'ready' and 'healthy' is that 'ready' will be execute just once, after the container starts and tells that the application is 'ready' to serve user requests. Which means that it can connect to database. The 'health' check is meant to be executed periodically and tells Kubernetes whether the application is healthy or not.

from rails-ex.

@mfojtik I'm working on PRs adding probes to each of the example apps today.

from rails-ex.

output should be to an ImageStreamTag

for the default route i'd make it match the out of the box default hostname that would be generated if you did not specify one. (the route hostname you'd get if you did not explicitly set one). since that's the only one that should actually work out of the box (resolvable by SkyDNS). Though i'm not sure if that DNS entry gets created if you explicilty set the hostname rather than let it be generated. needs to be tested.

from rails-ex.

@bparees should we define an ImageStream or ImageStreamTag?

Originally @ewolinetz was adding this to dancer-ex:

     {
-      "kind": "ImageStream",
+      "kind": "ImageStreamTag",
       "apiVersion": "v1",
       "metadata": {
-        "name": "dancer-example",
+        "name": "dancer-example:latest",
         "annotations": {
           "description": "Keeps track of changes in the application image"
         }
       }
     },

But after rebase it was eventually dropped from that PR. If ImageStreamTag, we can update all templates.

from rails-ex.

@rhcarvalho dancer-ex should still output to an ImageStreamTag... I think it was pulled in with your PR somehow

from rails-ex.

@rhcarvalho @ewolinetz we should be outputting to imagestreamtags. we should also be building from imagestreamtags. basically direct references to imagestreams should not be done anymore.

from rails-ex.

@bparees @ewolinetz I'm afraid we are talking about slightly different things.
One thing is BuildConfig.Output.To, and that should be and ImageStreamTag.

Now, the thing I am referring to, and one to figure out how it should be, is the "definition of the ImageStream that will keep track of images of your app". This is a top-level object inside the "objects" list in the template. Should this object be a ImageStream or ImageStreamTag object?

Option 1:

{
  "kind": "Template",
  ...
  "objects": [
     {
       "kind": "ImageStream",
       "apiVersion": "v1",
       "metadata": {
         "name": "dancer-example",
         "annotations": {
           "description": "Keeps track of changes in the application image"
         }
       }
     },

Option 2:

{
  "kind": "Template",
  ...
  "objects": [
     {
       "kind": "ImageStreamTag",
       "apiVersion": "v1",
       "metadata": {
         "name": "dancer-example:latest",
         "annotations": {
           "description": "Keeps track of changes in the application image"
         }
       }
     },

@bparees do we want to have 1 or 2?

from rails-ex.

@rhcarvalho ah. sorry. that should be an imagestream.

from rails-ex.

@mfojtik @bparees we need to decide what will be the URL pattern for the routes we define in the templates.

I was able to test that routes work by doing:

$ oadm router --create --credentials="openshift.local.config/master/openshift-router.kubeconfig" -n default
$ curl -H "Host:rails.app" 127.0.0.1

from rails-ex.

@bparees @rhcarvalho I hate to use rails.app domain :-) Assuming that we are going to show this at conferences I think we need to come with better name that is actually a valid domain ;-)

rails-example.openshift.io
django-example.openshift.io

etc...

from rails-ex.

*.openshift.io is probably better, I've only used *.app as it is nice and short for localized testing/demos. @luciddreamz Do you have any suggestions for route patterns to use for v3 that "might" look like a future openshift v3 hosted app?

from rails-ex.

End-user applications for OpenShift Online 3 will be hosted on openshiftapps.com.

OpenShift Online, PROD:

• Web Console: console.openshift.com
• Rest API endpoint: api.openshift.com
• Example User App: myapp-project.ad61.openshiftapps.com

OpenShift Online, STG:

• Web Console: console.stg.openshift.com
• Rest API endpoint: api.stg.openshift.com
• Example User App: myapp-project.ad61.stg.openshiftapps.com

OpenShift Dedicated (example: unicredit):

• Web Console: console.unicredit.openshift.com
• Rest API endpoint: api.unicredit.openshift.com
• Example User App: myapp-project.ad61.unicredit.openshiftapps.com

from rails-ex.

Thanks @luciddreamz
What does the "ad61" part stand for?

from rails-ex.

Via Thomas Wiest:

The routing tier will be broken up into shards (because each set of
routing containers can have roughly 50,000 routes / backends loaded).
We'll also have a routing tier per region, so each region will have it's
own set of 1 or more shards.

With this example app DNS: myapp-project.ad61.openshiftapps.com

myapp-project is the user defined route and project

ad61 is the routing tier DNS handling that specific route and project
name (ad61 is this shard's short unique ID).

ad61 is just an example, of course, it can be any short uuid.

from rails-ex.

In the example apps we currently name the services FRAMEWORKNAME-frontend (e.g. rails-frontend). The project name (namespace) would be something like "rails-ex" or "openshift".

If we follow the pattern, that would give rails-frontend-rails-ex.uid.openshiftapps.com as a route.

I believe we could probably skip the uid part for these example apps?

Both "rails-frontend-rails-ex.openshiftapps.com" and "rails-frontend-openshift.openshiftapps.com" look very repetitive for me...
Thoughts for this first part of the domain name?

from rails-ex.

@rhcarvalho @bparees @ewolinetz @sspeiche also please change the FRONTEND_ROUTE to APPLICATION_DOMAIN which makes more sense to users and it would be nice to set it as environment variable for the container with frontend (some apps has to know under what domain they run)

from rails-ex.

@rhcarvalho I think if we take what @mfojtik started with above "rails-example.openshift.io" and use the "openshiftapps.com" domain... Something like "rails-example.openshiftapps.com" seems a little less repetitive.

from rails-ex.

@ewolinetz do we have openshiftapps.com domain? I mean openshift.io is what we are using as a namespace for our metadata...

from rails-ex.

@mfojtik we do have that as the external facing domain for apps in v3, seems like the thing to use for demos and default. I wouldn't think end-users deploying these instantapps would see or use openshift.io for their exposed domains.

+1 for rails-example.openshiftapps.com pattern

from rails-ex.

@sspeiche we are going to use these domains for demos and presentations :-) i'm OK with rails-example.openshiftapps.com

from rails-ex.

pretty sure this is all complete now, or at least good enough (readiness probes have definitely been added)

from rails-ex.