-
Notifications
You must be signed in to change notification settings - Fork 71
You should be able to provide a default provider within Nulecule #378
Comments
IMO this should be added as a top level key - it is a "whole app" configuration. So something like:
Or we just create another section like
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 |
@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. |
Can we also try to figure out which providers are available in the user's environment rather than hardcode this into an app? |
From an end-user perspective I think this scenario validates this as long as we can override the default via answers/cli opt.
|
How about if we just say that first provider in |
@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 |
we don't need to add another key, as in
We just need to update Nulecule spec to support params in the root level, to incorporate params in |
Could you post in projectatomic/nulecule#184 about your proposal? |
timeout... ping @rtnpro |
@rtnpro You are right |
@cdrage Global params have been supported in atomicapp from a long time. We just need to update Nulecule spec docs. |
@dustymabe, @vpavlin, do we have a go for updating Nulecule spec on this? |
Hmm, so if the global params PR are implemented, I'm assuming this will work just by passing Just need to update the spec and change a tiny bit of code and we're golden! |
Per previous comments I still recommend we make this an optional extension of the metadata. No spec change is needed. Ideally this is a fallback directive. atomicapp should intelligently determine the default based on capability and an ordered list. If nothing specified, try these providers in order if available. |
So from aarons comment if we just use the metadata section then a spec file would look like this: metadata:
name: Hello Apache App
appversion: 0.0.1
description: Atomic app for deploying a really basic Apache HTTP server
defaultprovider: docker
... That seems reasonable and wouldn't require an update to the spec. @rtnpro what would an example nulecule file look like if we implemented this in global params? |
@dustymabe the above looks much cleaner compared to
|
No, it does not look cleaner:) It looks like adding another layer of indirection to params
My preference is using global params - but I wouldn't use |
I think we should use a poll here: http://poll.gitrun.com/ :) |
@vpavlin - With your suggestion of using global params and using @rtnpro do you think using global params as he suggested is reasonable? |
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 noanswers.conf
is provided.I propose we add (somewhere) to the Nulecule graph a default provider.
The text was updated successfully, but these errors were encountered: