Replace foreman_installer role #516

sean797 · 2017-08-15T14:13:08Z

This replaces foreman_installer role with https://github.com/sean797/ansible-role-foreman_installer (https://galaxy.ansible.com/sean797/foreman_installer/)

A couple of benefits this provides:

Generates Proxy Certs on the fly (replaces the current foreman_proxy_content role)
Automatically get oauth key's and secrets from the Foreman or Katello Server.

I've added it via git submodule as its also on Galaxy and I think it makes sense to not host it in forklift. I'm happy to define it in requirements.yml and/or move it to theforeman GitHub org.

I haven't changed pipelines/pipeline_katello_31.yml or pipelines/pipeline_katello_30.yml. Happy to do so, but I think they may be worth removing now, considering how old they are?

ekohl · 2017-08-15T17:16:32Z

While I'm open to the idea, this will take some time to review I think.

We should also look at the bigger picture: is a submodule the way to go? @ehelms also started https://github.com/theforeman/foreman-ansible-modules so perhaps there's more we can converge on in terms of using external repositories and how we do that.

ehelms · 2017-08-15T17:46:31Z

I will also take a bit of time to review and consider this. I do have some preliminary questions and thoughts.

On Tue, Aug 15, 2017 at 10:13 AM, sean797 ***@***.***> wrote: This replaces foreman_installer role with https://github.com/sean797/ ansible-role-foreman_installer (https://galaxy.ansible.com/ sean797/foreman_installer/) A couple of benefits this provides: - Generates Proxy Certs on the fly (replaces the current foreman_proxy_content role) Can you better explain "on the fly" and the benefits? As well, what is the

benefit of replacing the narrowly focused foreman_proxy_content role?

- Automatically get oauth key's and secrets from the Foreman or Katello Server. As opposed to? - Supports HA Foreman/Katello's Can you talk about this more? I've added it via git submodule as its also on Galaxy and I think it makes sense to not host it in forklift. I'm happy to define it in requirements.yml and/or move it to theforeman GitHub org.

Why do you think it makes sense not to host it in Forklift? I am not a huge fan of submodules as they go out of date easily.

…

-- Eric D. Helms Red Hat Engineering

sean797 · 2017-08-15T19:38:42Z

I agree with your points about submodules, I opted for that because requirements.yml is in .gitignore and defining roles in requirements.yml would require another step to pull down the role(s). Not the end of the world I guess, either way works. There are pros and cons of both.

A flexible foreman_installer Ansible role is missing on Galaxy, so I want to be able to publish there. AFAIK its 1 git repo -> 1 role mapping (requiring a /meta/main.yml file), hosting it in Forklift would result in problems importing it into Galaxy I think.

Proxy certs tar generation:
You provide a generate_proxy_certs_from var and it will go and generate the certs, copy them over, make all the oauth stuff correct and do the install.

HA support:
See https://github.com/sean797/ansible-role-foreman_installer#katello-cluster-with-custom-certificates
Basically it can setup oauth, other password answers, /etc/foreman/encryption_key.rb so they're the same.

Automatically get oauth key's and secrets from the Foreman or Katello Server.

As opposed to?

With the current role you have to do something like https://github.com/theforeman/forklift/blob/master/pipelines/pipeline_katello_nightly.yml#L61 supply the options you get, whereas this role will do that for you providing you supply generate_proxy_certs_from var.

The main reason behind this is I've created a flexible foreman_installer role, and it seem unnecessary for the me or the project to maintain both (and I want to share it ;-) )

ehelms · 2017-08-15T20:17:19Z

On Tue, Aug 15, 2017 at 3:38 PM, sean797 ***@***.***> wrote: I agree with your points about submodules, I opted for that because requirements.yml is in .gitignore and defining roles in requirements.yml would require another step to pull down the role(s). Not the end of the world I guess, either way works. There are pros and cons of both.

Yea - but you do it once and you're good. Not sure why we set it to be ignored.

A flexible foreman_installer Ansible role is missing on Galaxy, so I want to be able to publish there. AFAIK its 1 git repo -> 1 role mapping (requiring a /meta/main.yml file), hosting it in Forklift would result in problems importing it into Galaxy I thing.

So this gets us to tension between how Ansible chooses to share and manage roles and how we treat and maintain Forklift. I find this same issue to be true with puppet. Creating stand-alone roles, to facilitate the Galaxy/forge workflow, increases development complexity. If I need to fix an issue, I now have to make 1 or more commits across repositories, and hope their maintainers are on point (note I am speaking in the general, not speaking against you as a maintainer). So it becomes balancing the value of a stand alone role with development complexity. This type of change also moves us to a third party maintainer which has pros and cons. For example, we now have one less thing we are maintaining, but we have to trust that updates to it do not break out primary workflows and tend to match our standards.

*Proxy certs tar generation:* You provide a generate_proxy_certs_from var and it will go and generate the certs, copy them over, make all the oauth stuff correct and do the install.

I'm on the fence, as I can see your point but in some ways the cert generation (and collection of answers such as oauth, etc) is separate from the running of the installer itself. We've pushed for small, single minded roles in Forklift to allow easier composition. I'll look at the code a bit.

*HA support:* See https://github.com/sean797/ansible-role-foreman_ installer#katello-cluster-with-custom-certificates Basically it can setup oauth, password other answer, /etc/foreman/encryption_key.rb so they're the same. - Automatically get oauth key's and secrets from the Foreman or Katello Server. As opposed to? With the current role you have to do something like https://github.com/theforeman/forklift/blob/master/ pipelines/pipeline_katello_nightly.yml#L61 supply the options you get, whereas this role will do that for you providing you supply generate_proxy_certs_from var. See

That aspect does simplify things quite a bit for what needs to be defined. These are the things that make me think we need an installer module instead of a role, so it can be called from any location without having to overload a role for all cases or redefine calls to the installer.

The main reason behind this is I've created a flexible foreman_installer role, and it seem unnecessary for the me or the project to maintain both (and I want to share it ;-) )

There is a wrinkle I need to think about as well, with respect to plugins or other projects using Forklift and its roles and expectations on them. In that if we change this, and the "API" is not 1:1 we can break others :/

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#516 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR586Lop7SYZJhnJyv50Gfjm0MpuIH3ks5sYfPEgaJpZM4O3owG> .

-- Eric D. Helms Red Hat Engineering Ph.D. Student - North Carolina State University

ehelms · 2017-08-15T20:19:04Z