You should be able to provide a default provider within Nulecule

[cdrage]

An issue that we're facing is that there is no way to assign a default provider outside of the answers.conf.

If an Atomic App is packaged with only a Docker provider, by running atomic run cdrage/testimage the container by default will try to run k8s if no answers.conf is provided.

I propose we add (somewhere) to the Nulecule graph a default provider.

metadata:
  name: Hello Apache App
  appversion: 0.0.1
  description: Atomic app for deploying a really basic Apache HTTP server
graph:
  - name: helloapache-app
  - defaultprovider: docker
    params:
      - name: image
        description: The webserver image
        default: centos/httpd
      - name: hostport
        description: The host TCP port as the external endpoint
        default: 80
    artifacts:
      docker:
        - file://artifacts/docker/hello-apache-pod_run
      kubernetes:
        - file://artifacts/kubernetes/hello-apache-pod.json

[dustymabe]

seems reasonable. @vpavlin @goern ^^

[vpavlin]

IMO this should be added as a top level key - it is a "whole app" configuration. So something like:

---
specversion: 0.0.2
id: guestbook-app
defaultprovider: docker

metadata:
  name: Guestbook Application
  appversion: 0.0.1
  description: Atomic app for deploying the guestbook Python app
graph:

Or we just create another section like metadata

---
specversion: 0.0.2
id: guestbook-app

config:
  defaultprovider: docker

metadata:
  name: Guestbook Application
  appversion: 0.0.1
  description: Atomic app for deploying the guestbook Python app
graph:

Also, this is probably a spec change rather then just extension for Atomic App, so it should be a Nulecule repo issue:)

And last thing - provider choice is mostly on the user who deploys the app, not on the developer. If the app contains only a docker provider metadata, we should be able to figure this out (that's one of the purposes of the refactoring done by @rtnpro!) and change the behaviour accordingly - i.e. don't blindly try to talk to kubernetes if the app does not support it.

If we agree that the paragraph above is what we are trying to solve here, then you have my +1 to work on it and fix it (and then the issue obviously belongs here). Otherwise, I'd like to hear more reasons to why the defaultprovider is needed in Nulecule file.

[cdrage]

@vpavlin I totally agree in regards to the provider choice being able to select a default. If there is only one provider it should default to it, or if there are two providers that aren't k8s, then it should default to at least one of them.

[vpavlin]

Can we also try to figure out which providers are available in the user's environment rather than hardcode this into an app?

[aweiteka]

I agree this should be a global config, not in the graph. I would suggest it land in the metadata section, not as a first level item.

@vpavlin we have a start towards auto-detection in #346

[aweiteka]

From an end-user perspective I think this scenario validates this as long as we can override the default via answers/cli opt.

1. I have a system that supports multiple providers, say kubernetes and Docker. I'm trying out a new application to play with it. I want the lowest barrier to get it running (hello, world). The quickstart docs suggest I can "just run it." I will rely on the default provider that's selected for this application. In this case the developer chose Docker as the default provider.
2. I have played with the application and now want to deploy it on a stage (pre-production) system. I have planned the deployment (storage requirements, config, etc) using documentation. I know what provider I want, this time kubernetes. I want to select which provider, overriding the default.

[kadel]

How about if we just say that first provider in io.projectatomic.nulecule.providers label is default provider? This way we don't need another configuration option.

[vpavlin]

@kadel I think this splits metadata into 2 locations, which doesn't sound right to me. Also there have been some requests on being able to use Nulecule as a tar ball instead of Docker image and if somebody decides to do that, he would lose the ability to specify default provider

[rtnpro]

@vpavlin

we don't need to add another key, as in

defaultprovider: docker

We just need to update Nulecule spec to support params in the root level, to incorporate params in general section in the Nulecule spec file.

[cdrage]

@rtnpro

Could you post in projectatomic/nulecule#184 about your proposal?

[cdrage]

timeout... ping @rtnpro

[vpavlin]

@rtnpro You are right

[rtnpro]

@cdrage Global params have been supported in atomicapp from a long time. We just need to update Nulecule spec docs.