Saving atomicapp run config for reuse during stop

[rtnpro]

Problem statement

Currently, whenever we try to run a nulecule application using atomicapp, it tries to read configuration data from answers.conf if specified/available. During run, when it discovers, params with missing values, it asks the users for data, and runs the nulecule application. But, it does not save the data asked from the user for reuse during stop. So, stop command for stopping a nulecule application, again asks the user to enter values for params with missing values in answers.conf.

Proposed solution

We can save the config used for running the nulecule app somewhere for reuse. Now, how and where we save this config data generated during runtime is a matter of discussion. I will discuss multiple ways that come to my mind with pros and cons for each of them:

1. Write generated config (data from answers.conf and user input) data implicitly to answers.conf, if --write-answers is not specified. This approach is very simple to implement, however, the downside to this is that, we are editing user data implicitly. When a user has specified --write-answers to write the runtime config data to a file, it's highly probable that the user is going to use the output answers data in subsequent runs. But, if he has written the answers output to a file other than answers.conf, the user needs to explicitly mention the name of the output file against -a arg to use it for stopping the nulecule application. Not that user friendly, is it? This brings me to my second proposed solution.
2. We can use a file like .atomicapprc to store runtime config and use it to compliment ANSWERS data. The downside is that it will add another layer of complexity to the code, but will make usability much simpler. Most applications do it this way, i.e. having local *rc files.

[vpavlin]

I am definitely in favour of saving the data provided by user by default - answers.conf.gen ?

But I don't really understand how would .atomicapprc file work. Where would it be written?

[rtnpro]

@vpavlin answers.conf.gen sounds good to me. I was planning on saving .atomicapprc in the current app directory, with other metadata (I don't know what) in addition to answers data.

[dustymabe]

answers.conf.gen or answers.conf.lastrun sounds good to me. I think it would also be useful to have a file that contained some "state" information in it. My initial thought on state information is that it would simply hold the name of the last command that was run.. i.e 'fetch, install, run, stop, uninstall'.

[rtnpro]

@dustymabe

Merlin's beard! Those were the extra metadata: state, etc in .atomicapprc in addition to answers data.

[dustymabe]

ok. I don't like .atomicapprc for a name though. To me an rc file is one that a user modifies to adjust behavior of the application but the application itself never modifies the file. Think .vimrc, does vim ever modify the contents?

[vpavlin]

Yeah, it should definitely be named differently: http://stackoverflow.com/questions/11030552/what-does-rc-mean-in-dot-files :)

Something like .atomicapp/rundata?

[cdrage]

I agree with @vpavlin, have something within .atomicapp for the current user. Would be nice and tidy to keep track of all data there.

Now, should we use a YAML or JSON structure within it? I assume YAML since that's what most of us favor right now.

In the future, I would like to also see .atomicapp/config so we can override any default installation values (ex. always using docker as a provider, or openshift if on an openshift distro, etc.)

[rtnpro]

@charliedrage 👍

[dustymabe]

instead of .gen what do you think about .lastrun ?

[dustymabe]

@rtnpro has then been done?

[dustymabe]

Done in 3c549b7