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.

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

Names for examples should be consistent across build configs and deployment configs #3358

Closed
smarterclayton opened this issue Jun 21, 2015 · 7 comments
Assignees

Comments

@smarterclayton
Copy link
Contributor

In our examples, when we have multiple components (a build config for a frontend and a deployment config for a frontend and backend) the build config, deployment config, service name, and route name should all match.

Example, nodejs.json:

service: nodejs-frontend
route: nodejs-example
build config: nodejs-example
deployment config: nodejs-frontend
image stream: nodes-example
container name: nodejs-example
source: https://github.com/openshift/nodejs-ex.git

It's hard to switch between these mentally - it would be better if we were consistent, nodejs-example completely or nodejs-frontend completely.

@gabemontero
Copy link
Contributor

@smarterclayton All the sample repos have been updated. Close or advise of additional changes at your discretion. Thanks.

@smarterclayton
Copy link
Contributor Author

Can you link the fixes you made to this issue?

@gabemontero
Copy link
Contributor

cakephp-ex : sclorg/cakephp-ex#10
dancer-ex: sclorg/dancer-ex#18
django-ex: sclorg/django-ex#21
golang-ex: openshift/golang-ex#2
nodejs-ex: sclorg/nodejs-ex#23
rails-ex: sclorg/rails-ex#34
origin doc improvements from testing of *-ex readme's : #3522

@smarterclayton
Copy link
Contributor Author

One thing - when someone deploys these examples, are they going to then
evolve them to be their own? If so, having to find/replace "-example" in
the template is going to be somewhat annoying. I think this is fine for
now, but something we need to consider in the future for naming.

2015-07-02 15:18 GMT-04:00 Gabe Montero [email protected]:

cakephp-ex : sclorg/cakephp-ex#10
sclorg/cakephp-ex#10
dancer-ex: sclorg/dancer-ex#18
sclorg/dancer-ex#18
django-ex: sclorg/django-ex#21
sclorg/django-ex#21
golang-ex: openshift/golang-ex#2
openshift/golang-ex#2
nodejs-ex: sclorg/nodejs-ex#23
sclorg/nodejs-ex#23
rails-ex: sclorg/rails-ex#34
sclorg/rails-ex#34
origin doc improvements from testing of *-ex readme's : #3522
#3522


Reply to this email directly or view it on GitHub
#3358 (comment).

Clayton Coleman | Lead Engineer, OpenShift

@gabemontero
Copy link
Contributor

Hmm ... has there been any thought to, or how feasible is it to have, a variable substitution mechanism for these json files' contents? Especially if the name is the only variable, and folks will want to use them as-is otherwise. It would be somewhat analogous to setting ENV vars in the JSON for runtime use in the containers.

@bparees
Copy link
Contributor

bparees commented Jul 6, 2015

yes the names are all parameterizable just like we do with the DB side, like here:
https://github.com/openshift/rails-ex/blob/master/openshift/templates/rails-postgresql.json#L250

so we could do the same for the rest of the names (with useful defaults). @gabemontero if you want to open a new issue to track doing that and we can queue it up.

@gabemontero
Copy link
Contributor

3571 is opened: #3571

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants