Matthias, Copying the response to the mailing list since this is all technical in nature and I don't have all the answers.
From: Mathias Ewald <mew...@evoila.de<mailto:mew...@evoila.de>> Date: Sunday, July 3, 2016 at 12:19 PM To: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>> Subject: OpenStack Kolla - External Ceph Hi Steven, I am beginning to work on the external Ceph integration for OpenStack Kolla and wanted to share some thoughts with someone more involved in the project: I've been digging into to the code a bit and the work that was already in in this direction. From the code I read so far, the current approach uses global.yml to configure everything necessary to connect to external ceph. Service config, ceph.conf and keyring are then generated via Ansible. At this point, I feel we are going a direction in which we try to wrap everything anybody could possibly want to configure with Kolla by making extensive use of global.yml. We would have to introduce flags indicating a couple of different scenarios: 1. Deploy Ceph (already there: enable_ceph="yes") 2. Use Ceph with Glance (enable_ceph_glance="yes") 3. Use Ceph with Cinder (enable_ceph_cinder="yes") 4. Use Ceph with Nova (enable_ceph_nova="yes") I disagree. If ceph is enabled, then ceph should be used, if ceph is not enabled, then ceph shouldn't be used. That implies all of OpenStack either uses Ceph or not. So we really just need enable_ceph. If enable_ceph is "yes" and enable_ceph_X="yes" we can follow the code that is active right now: Generate ceph.conf, create cephx credentials, generate keyring file, generate e.g. cinder.conf and configure backend. Ack If enable_ceph is "no" but enable_ceph_X are set to "yes", we need many more parameters in global.yml to tell Kolla the username, password, monitor nodes and some other stuff. You see how adding configuration for each option creates a whole lot of configuration options. I just don't see the use case and its a violation of our philosophy. Now what if I wanted to have some custom parameter in my ceph.conf? As far as I understand Kolla now, we can provider custom configuration that is merged into the generated default file, but that's only true for the standard config files of services, right? (cinder.conf, nova.conf, neutron.conf, ...) Kolla can only merge ini files. I don't know what format ceph.conf is in (on PTO atm and don't have access to my lab). If the format of ceph.conf is ini it could be merged. Pretty much all we need is: 1. Make custom configs to (glance|cinder|nova).conf to enable RBD backend 2. Create /etc/ceph/ceph.conf 3. Create keyring in /etc/ceph We already have (1) as Kolla has that INI merging functionality, so /etc/cinder/cinder.conf and others are already taken care of. (2) and (3) can be dealt with by allowing to copy arbitrary files into the container. Only Nova is a bit more complex as Libvirt secret must be created. Allowing to copy arbitrary files into the container would also solve another problem at the same time: Keystone allows per domain backend configuration of identity and assignment backends. This is typically used to connect Keystone to different LDAP directories for different tenants. This involves creating the domain via API and placing a file in /etc/keystone/domains/keystone.<domainname>.conf for each domain. We clearly need to handle the ldap case - we have been asked as a community by 5+ people for ldap integration. I think to prioritize this we need someone with ldap setup to do the actual development. I don't have an LDAP environment. I'm not opposed to setting one up, but I have a lot of high priority stuff and my plate is already full. Maybe another developer (or you) would be interested? Regards -steve What do you think? cheers Mathias -- Mobil: +49 176 10567592<tel:%2B49%20176%2010567592> E-Mail: mew...@evoila.de<mailto:mew...@evoila.de> evoila GmbH Wilhelm-Theodor-Römheld-Str. 34 55130 Mainz Germany Geschäftsführer: Johannes Hiemer Amtsgericht Mainz HRB 42719 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If You are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
