Plugins » Katello

I'm not a Katello expert, but some notes from what I can say:

- Elasticsearch: will be gone with Katello 3.0
- MongoDB: Is used by Pulp and there's an ongoing effort to replace it with PostgreSQL in Pulp 3.0
- DB backends: foreman-installer does expose these (e.g. --foreman-db-manage=false --foreman-db-host=mydbhost --foreman-db-password=db123 and so on), no idea about katello, but at least for the main Foreman/Katello DB it would technically be possible. Note, that katello does only support PostgreSQL at the moment, AFAIK)
- Smart Proxy: I'm unsure if I do understand the requirement correctly, but have a look at the Capsule docs, mainly http://www.katello.org/docs/3.0/installation/capsule.html and http://www.katello.org/docs/3.0/user_guide/capsules/
- All the rest: for some of these things, options are exposed in our Puppet modules (which are consumed by the installer, but the Katello scenario will probably mask some of these), for some others the needed additions would need to get implemented in the respective modules.

From my experience with the usual Foreman/Puppet install with DNS/DHCP I can't imagine a manual Katello install to be really an option, so the focus here would really be to enhance the Puppet modules and installer(s) to be feasible for more use cases.

Stephan,

I appreciate the issue as it provides us with real world scenarios for how backend components might want to be deployed by users in ways other than the single box deployment. That type of information and data will prove invaluable to try and tackle this problem. In some cases, this comes down to how we have the puppet modules for certain services wrapped to ensure they are configured properly. In other cases, it may be more fundamental to how we approach installation. For example, puppet-pulp allows for use with a mongodb not under it's control. We currently do not expose that as an option due to the puppet wrapping.

I do want to reiterate what Michael said, the amount of work, dependencies and complexity involved in the install at present is more than I could fathom trying to write a manual installation guide for. I do think it would be worth while to take each of the use cases you provide and break them into individual Redmine stories that we link to a single Tracker so that we can tackle them individually but treat multi-machine installation as an epic. This would also allow us to discuss design and prioritize which particular services to tackle first (attack the constraints).

If this approach seems amenable to you, I'd ask that you begin turning each case into a Redmine issue and I can assist with the tracker. If you are unsure how to break them down, I can do my best to break them down and let you vet them. Another option would be to comment on the Redmine issue here with a the list of stories and I can then file them in Redmine.

no reaction, closing.