Installer: RFE: preserve install-config.yml

[michaelgugino]

We'd like to not delete install-config.yml when running new installer.

Background:

I believe most users will not use the interactive prompts when running the new installer when deploying a production cluster. Thus, most likely, they will provide an install-config.yml directly. This install-config.yml file will most likely exist in a user's version control system (eg: git). Most likely, users will want to clone this and possibly other artifacts to a deployment host and then run the installer. Deleting the install-config.yml leaves the deployment host in question: What was actually deployed? I can observe that my git checkout is now uncommitted.

BYO Use Case:

We would like to consume install-config.yml as our 'source of truth' for installations. Instead of building a lay of abstractions in ansible to populate an install-config.yml file, we ask the user to bring this file, and we execute portions of the (new) installer on their behalf. In such a case, install-config.yml would essentially be part of their inventory variables (though not directly part of inventory in the ansible sense, but an artifact of 'how I built this cluster' nonetheless).

Workarounds do exist, so this feature is not critical, but I think it would be highly desirable from a UX standpoint.

[michaelgugino]

@kalexand-rh

[michaelgugino]

@sdodson @vrutkovs

[michaelgugino]

@dgoodwin

[aaronlevy]

@michaelgugino can you update the issue with some background / reasoning / user stories as to why? This was discussed off-thread, but it would be good to capture top-level points here.

[michaelgugino]

@aaronlevy updated first commit with more background.

[staebler]

What if we added a sub-command to openshift-install that let the user view the intermediate assets that were used? For example, after creating the cluster, the user could run the following command to see the install-config.yml used.

openshift-install view install-config

[DanyC97]

@staebler but how will that help with below use case ?

Instead of building a lay of abstractions in ansible to populate an install-config.yml file, we ask the user to bring this file, and we execute portions of the (new) installer on their behalf

i guess i'm missing s'thing here

[staebler]

@staebler but how will that help with below use case ?

Instead of building a lay of abstractions in ansible to populate an install-config.yml file, we ask the user to bring this file, and we execute portions of the (new) installer on their behalf

i guess i'm missing s'thing here

I think I'm the one that is missing something. How does having the installer remove the install-config.yml affect asking a user to bring the install-config.yml? There are not "portions" of the installer. You run stages. After running the first stage with the install-config.yml as input, the install-config.yml is no longer needed for subsequent stages. If you want to see what the install-config.yml used was for non-installer purposes, you could query the installer for the file.

[cgwalters]

Kind of related, I've been working on a new CLI wrapper for the installer: https://github.com/cgwalters/homegit/blob/master/bin/okdinst

Among its features are that it generates an initial install config via the prompt, and saves it. That config is then used to create further clusters. I'd like to support having multiple configs too.

Is this the right time to discuss possibly doing this by default in the installer? Including things like writing clusters to ~/.config/openshift-install/clusters and not $PWD etc?

[michaelgugino]

If you want to see what the install-config.yml used was for non-installer purposes, you could query the installer for the file.

Or we could just choose to not delete the file. The goal is to eliminate the need to create another abstraction in the BYO RHEL context. There's quite a few things would could do, not deleting the install-config.yml seems like the best option to me.

[eparis]

Let's assume we don't delete the installconfig and I:

1. create the install config.
2. edit the install config.
3. create the manifests
4. edit the manifests.
5. edit the install config.
6. generated the terraform state.

What should be the result.

I think the answer to that question should guide or decision making.

[kikisdeliveryservice]

@cgwalters have you seen: https://github.com/openshift/installer/blob/master/docs/user/tips-and-tricks.md#reusing-an-install-config to generate a reusable install config?

[cgwalters]

Yes, the script references that at the top: https://github.com/cgwalters/homegit/blob/master/bin/okdinst#L5

It's an automation of that workflow.

[michaelgugino]

Let's assume we don't delete the installconfig and I:

1. create the install config.

2. edit the install config.

3. create the manifests

4. edit the manifests.

5. edit the install config.

6. generated the terraform state.

What should be the result.

I think the answer to that question should guide or decision making.

@eparis step 5. can be substituted with "Replace missing install-config with new one, different values".

Is rerunning the installer with the now-present new install-config going to change it's behavior? It's confusing in either case here.

[crawford]

It's confusing in either case here.

This is why we opted to consume the intermediate assets and make this difficult to hit in practice. There really isn't a good solution here other than warning the user that you are going to discard one or the other.

[brianredbeard]

FWIW, the tips-and-tricks.md document was moved in commit 28592d0255a924b614a0f03399982ab0844e7a01 and is now located under "Multiple Invocations" section in the user doc "Overview".

[brianredbeard]

In my opinion, the behavior needs to be made clear. As a user, I have never run the installation mechanism of an application with an "answer file" (which is effectively what this is) where it _deletes_ my answer file.

Similarly, I would not have expected the installer to _fail_ in the event that it was unable to delete the answer file:

https://github.com/openshift/installer/issues/1011#issuecomment-452378241

Is there prior art of an installer behaving in this way? I would make the assumption that having that info at the ready will be useful for managing the expectations of users.

[eparis]

At this point I do not believe we plan to make changes here and apologize for the inconvenience. If you would like us to reconsider please reach out to your support representative or file a new issue in Jira.

[marun]

I don't think it is reasonable to completely nuke install-config.yaml in the case where it is provided by the user rather than created by the installer. At the least it should be renamed (e.g. install-config.yaml.bak).