Allow stored templates to be referenced from osc process

[mfojtik]

Examples:

osc process -f template.json
osc process stored-template

[mfojtik]

@bparees @smarterclayton PTAL

[smarterclayton]

Add a hack/test-cmd and you'll get sign off :)

[mfojtik]

@smarterclayton done, waiting for travis

[smarterclayton]

LGTM [merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1145/) (Image: devenv-fedora_1009)

[openshift-bot]

Evaluated for origin up to 053bb3e

[bparees]

don't you need to check this error in case the template didn't exist?

[bparees]

@smarterclayton @mfojtik given that @fabianofranz is implementing the "create from template" CLI with a full wizard flow, do we really want to have two code paths doing the same thing?

[smarterclayton]

Eh, templates are lower than apps. Apps won't give you all the flow that process does, nor the same flexibility.

On Mar 10, 2015, at 9:24 PM, Ben Parees [email protected] wrote:

@smarterclayton @mfojtik given that @fabianofranz is implementing the "create from template" CLI with a full wizard flow, do we really want to have two code paths doing the same thing?

—
Reply to this email directly or view it on GitHub.

[bparees]

My understanding was that what fabiano was doing was create from template, not create an app, and that it would have wizard flows, which would be as much or more flexibility than this offers. If that's incorrect then we probably should not have deleted the "create from template cli" card this morning that we decided was a dupe.

Ben Parees | OpenShift

-----Original Message-----
From: Clayton Coleman [[email protected]]
Received: Tuesday, 10 Mar 2015, 23:22
To: openshift/origin [[email protected]]
CC: Ben Parees [[email protected]]
Subject: Re: [origin] Allow stored templates to be referenced from osc process (#1269)

Eh, templates are lower than apps. Apps won't give you all the flow that process does, nor the same flexibility.

On Mar 10, 2015, at 9:24 PM, Ben Parees [email protected] wrote:

@smarterclayton @mfojtik given that @fabianofranz is implementing the "create from template" CLI with a full wizard flow, do we really want to have two code paths doing the same thing?

—
Reply to this email directly or view it on GitHub.

---

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

[smarterclayton]

He would be integrating into new-app, which already has partial support for create from template. You can use templates as pieces parts and put them together.

On Mar 10, 2015, at 11:56 PM, Ben Parees [email protected] wrote:

My understanding was that what fabiano was doing was create from template, not create an app, and that it would have wizard flows, which would be as much or more flexibility than this offers. If that's incorrect then we probably should not have deleted the "create from template cli" card this morning that we decided was a dupe.

Ben Parees | OpenShift

-----Original Message-----
From: Clayton Coleman [[email protected]]
Received: Tuesday, 10 Mar 2015, 23:22
To: openshift/origin [[email protected]]
CC: Ben Parees [[email protected]]
Subject: Re: [origin] Allow stored templates to be referenced from osc process (#1269)

Eh, templates are lower than apps. Apps won't give you all the flow that process does, nor the same flexibility.

On Mar 10, 2015, at 9:24 PM, Ben Parees [email protected] wrote:

@smarterclayton @mfojtik given that @fabianofranz is implementing the "create from template" CLI with a full wizard flow, do we really want to have two code paths doing the same thing?

—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#1269 (comment)
—
Reply to this email directly or view it on GitHub.

[fabianofranz]

@smarterclayton @bparees Originally the story targeted creating from templates in a wizardy way, but it's pretty old and surely some of the original targets might be deprecated. I know that at some point we decided to avoid user prompts and wizards in places other than osc login for example.

We should adapt the work to what makes more sense today, either involving new-app or not. Would you guys like to have a quick chat today to sync?

[smarterclayton]

I'm out of the pocket but Cesar knows the vision

On Mar 11, 2015, at 11:17 AM, Fabiano Franz [email protected] wrote:

@smarterclayton @bparees Originally the story targeted creating from templates in a wizardy way, but it's pretty old and surely some of the original targets might be deprecated. I know that at some point we decided to avoid user prompts and wizards in places other than osc login for example.

We should adapt the work to what makes more sense today, either involving new-app or not. Would you guys like to have a quick chat today to sync?

—
Reply to this email directly or view it on GitHub.

[bparees]

@smarterclayton I don't see anything in new-app that deals with create from template... can you elaborate on what's there?

@csrwng welcome to the party.

[csrwng]

@smarterclayton you give me too much credit. I wish I knew the vision :-) Is the thinking that a template would be a source for components so that new-app can help put them together with other things?

[smarterclayton]

Just a bit left - it would be wired in like a component type and have equal weight with image repository names (above the docker registry).

On Mar 12, 2015, at 5:39 PM, Ben Parees [email protected] wrote:

@smarterclayton I don't see anything in new-app that deals with create from template... can you elaborate on what's there?

@csrwng welcome to the party.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Yes

On Mar 12, 2015, at 5:48 PM, Cesar Wong [email protected] wrote:

@smarterclayton you give me too much credit. I wish I knew the vision :-) Is the thinking that a template would be a source for components so that new-app can help put them together with other things?

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Template would be a single component. So "mysql" template would have slightly higher priority over "mysql" image

On Mar 12, 2015, at 5:48 PM, Cesar Wong [email protected] wrote:

@smarterclayton you give me too much credit. I wish I knew the vision :-) Is the thinking that a template would be a source for components so that new-app can help put them together with other things?

—
Reply to this email directly or view it on GitHub.

[bparees]

@smarterclayton my fundamental confusion is over your initial statement that: "Apps won't give you all the flow that process does, nor the same flexibility"

the only flexibility process gives you today is that you can pass -v to override template parameters, and i don't think we have any additional flexibility in mind to add.

so i'm still not really seeing how "new-app mytemplate" and "process mytemplate" are going to be meaningfully different, unless you're stating that "new-app" should under no circumstance allow the explicilt specification/overriding of parameter values.

[bparees]

(keeping in mind the "osc process mytemplate" doesn't actually create anything, but neither does "osc new-app mytemplate -o json")

[smarterclayton]

On Mar 12, 2015, at 6:32 PM, Ben Parees [email protected] wrote:

@smarterclayton my fundamental confusion is over your initial statement that: "Apps won't give you all the flow that process does, nor the same flexibility"

new-app makes assumptions - it's going to check your inputs against what's in the repo, maybe give you an error if something you tried doesn't make sense. It's going to act on your behalf, assuming you want the behavior implied with "new-app". Process on the other hand is dumb - it's going to take input and generate output.
the only flexibility process gives you today is that you can pass -v to override template parameters, and i don't think we have any additional flexibility in mind to add.

so i'm still not really seeing how "new-app mytemplate" and "process mytemplate" are going to be meaningfully different, unless you're stating that "new-app" should under no circumstance allow the explicilt specification/overriding of parameter values.

—
Reply to this email directly or view it on GitHub.

[bparees]

@smarterclayton that's fair, but in the case that i just run "new-app mytemplate" with no other parameters there is no guesswork for it to do (short of the question of whether there happens to be also be a docker image named "mytemplate"), so it should have the same outcome as "process mytemplate | create -f -"

[smarterclayton]

Yes, it should.

On Mar 13, 2015, at 9:25 AM, Ben Parees [email protected] wrote:

@smarterclayton that's fair, but in the case that i just run "new-app mytemplate" with no other parameters there is no guesswork for it to do (short of the question of whether there happens to be also be a docker image named "mytemplate"), so it should have the same outcome as "process mytemplate | create -f -"

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Except for labeling.

On Mar 13, 2015, at 9:25 AM, Ben Parees [email protected] wrote:

@smarterclayton that's fair, but in the case that i just run "new-app mytemplate" with no other parameters there is no guesswork for it to do (short of the question of whether there happens to be also be a docker image named "mytemplate"), so it should have the same outcome as "process mytemplate | create -f -"

—
Reply to this email directly or view it on GitHub.

[bparees]

new-app isn't going to create labels when it processes the template? isn't that a function of the process endpoint?

[smarterclayton]

It is - label decisions are made at the app label and filtered down into the components (including the templates) in a way that is not the same as how process works.

On Mar 13, 2015, at 10:52 AM, Ben Parees [email protected] wrote:

new-app isn't going to create labels when it processes the template? isn't that a function of the process endpoint?

—
Reply to this email directly or view it on GitHub.

[bparees]

@smarterclayton so what i keep hearing is "we'll have two slightly different ways to accomplish basically the same thing with minor variations of useful, but non-overlapping, capabilities". I think it should all be in new-app since that is the most feature rich interface right now. (ie parameter overriding ought to be added to new-app and then we can remove the osc process support for template resources)

[fabianofranz]

Reviving an old thread here, because it's related to the discussion (and I kept the tab open until then).

Now that osc new-app can process and create from stored templates, I think we could should rethink the design and flows of these 3 command involved in creation (osc process, osc create, osc new-app).

In my opinion the current new-app is the creation action for end-users, and while they all have similar functionality, new-app is simpler to use but less powerful; process/create allow a deeper control of what's going to happen, but targeted at advanced users and administrators. Also, new-app is not a great name, because of the concept of applications vs. projects, etc.

I'd propose something like:

osc create // the current new-app renamed and specifically targeted for end users
osadm process // current osc process, targeted for advanced users/administrators
osadm create // current osc create, targeted for advanced users/administrators

Thoughts? @smarterclayton @bparees @mfojtik @csrwng

[smarterclayton]

If you want to script templates and inject your own custom rules you still want that as an admin.

Power user does not mean "goes under openshift admin". Probably just means "not in the regular help list for new users".

On Apr 21, 2015, at 8:54 PM, Fabiano Franz [email protected] wrote:

Reviving an old thread here, because it's related to the discussion (and I kept the tab open until then).

Now that osc new-app can process and create from stored templates, I think we could should rethink the design and flows of these 3 command involved in creation (osc process, osc create, osc new-app).

In my opinion the current new-app is the creation action for end-users, and while they all have similar functionality, new-app is simpler to use but less powerful; process/create allow a deeper control of what's going to happen, but targeted at advanced users and administrators. Also, new-app is not a great name, because of the concept of applications vs. projects, etc.

I'd propose something like:

osc create // the current new-app renamed and specifically targeted for end users
osadm process // current osc process, targeted for advanced users/administrators
osadm create // current osc create, targeted for advanced users/administrators
Thoughts? @smarterclayton @bparees @mfojtik @csrwng

—
Reply to this email directly or view it on GitHub.

[bparees]

I think that's too drastic of a change in osc create behavior at this point in time. osc create is tied to the rest interface to match with osc get, osc delete, etc.

i'm also not convinced new-app is simpler or less powerful. Granted, process/create allows total control since you can manipulate the json, but then so does new-app since it can consume template json too. And new-app has a lot of other subtle functionality that process/create does not in terms of creating services/deployments directly from Images, ImageStreams, etc, that you cannot do with process/create (without writing json).

If there's any argument here, i'd say it's that "osc process" could go away since new-app can consume templates now. (as long as new-app provides the Parameter overriding behavior that process offers, and if new-app could consume templates from disk not just storage)

[smarterclayton]

new-app changes the template as well, i don't think it would reduce to the process equivalent (today). Ben's points are valid. Create is "cat" or "vi", new-app is "emacs". new-app interprets "intent", process makes no such assumption.

On Apr 21, 2015, at 11:08 PM, Ben Parees [email protected] wrote:

I think that's too drastic of a change in osc create behavior at this point in time. osc create is tied to the rest interface to match with osc get, osc delete, etc.

i'm also not convinced new-app is simpler or less powerful. Granted, process/create allows total control since you can manipulate the json, but then so does new-app since it can consume template json too. And new-app has a lot of other subtle functionality that process/create does not in terms of creating services/deployments directly from Images, ImageStreams, etc, that you cannot do with process/create (without writing json).

If there's any argument here, i'd say it's that "osc process" could go away since new-app can consume templates now. (as long as new-app provides the Parameter overriding behavior that process offers, and if new-app could consume templates from disk not just storage)

—
Reply to this email directly or view it on GitHub.

[fabianofranz]

Ok, I got your points.

The osc/osadm proposal had actually the main intent of making clear to end users what the entry point for "creating stuff" is. Not displaying create and process in the main path, say in the regular help list for end users, would also attend that intention.

That said, I'm still not confident about the "new-app" name - we are exposing the concept of "application" that we, ourselves, are trying to avoid by making "project" our container for components. But there are both new-app and new-project. I remember we had a list of name proposals at some point, maybe we should take another look at it.

@bparees new-app supports parameter overriding already, through the -p|--param flag.

BTW as mentioned by Ben, do we plan to support templates from disk in new-app? Supporting only stored templates makes sense to me, and gives it parity with the web console - I don't see the web console allowing the upload of a json template for creation, for example.

[smarterclayton]

On Apr 21, 2015, at 11:59 PM, Fabiano Franz [email protected] wrote:

Ok, I got your points.

The osc/osadm proposal had actually the main intent of making clear to end users what the entry point for "creating stuff" is. Not displaying create and process in the main path, say in the regular help list for end users, would also attend that intention.

That said, I'm still not confident about the "new-app" name - we are exposing the concept of "application" that we, ourselves, are trying to avoid by making "project" our container for components. But there are both new-app and new-project. I remember we had a list of name proposals at some point, maybe we should take another look at it.

@bparees new-app supports parameter overriding already, through the -p|--param flag.

BTW as mentioned by Ben, do we plan to support templates from disk in new-app? Supporting only stored templates makes sense to me, and gives it parity with the web console - I don't see the web console allowing the upload of a json template for creation, for example.

Why not?
—
Reply to this email directly or view it on GitHub.

[fabianofranz]

@smarterclayton Meaning we do want to new-app from template on disk? :)

[fabianofranz]

@smarterclayton I mean probably ok from an "advanced creation" screen, just not exposed as a regular path in the current creation screen, for example.

[smarterclayton]

As a small link or button in the corner "Have your own template?" only, yes.

On Apr 22, 2015, at 12:05 AM, Fabiano Franz [email protected] wrote:

@smarterclayton I mean probably ok from an "advanced creation" screen, just not exposed as a regular path in the existing creation screen, for example.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Not right now. Maybe after 3.0

On Apr 22, 2015, at 12:01 AM, Fabiano Franz [email protected] wrote:

@smarterclayton Meaning we do want to new-app from template on disk? :)

—
Reply to this email directly or view it on GitHub.