<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Matthias,</div>
<div><br>
</div>
<div>Copying the response to the mailing list since this is all technical in nature and I don't have all the answers.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Mathias Ewald <<a href="mailto:mewald@evoila.de">mewald@evoila.de</a>><br>
<span style="font-weight:bold">Date: </span>Sunday, July 3, 2016 at 12:19 PM<br>
<span style="font-weight:bold">To: </span>Steven Dake <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>><br>
<span style="font-weight:bold">Subject: </span>OpenStack Kolla - External Ceph<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">Hi Steven,
<div><br>
</div>
<div>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. <br clear="all">
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>1. Deploy Ceph (already there: enable_ceph="yes")</div>
<div>2. Use Ceph with Glance (enable_ceph_glance="yes")</div>
<div>3. Use Ceph with Cinder (enable_ceph_cinder="yes")</div>
<div>4. Use Ceph with Nova (enable_ceph_nova="yes")</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Ack</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>
<div><br>
</div>
<div>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, ...)</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>
<div><br>
</div>
<div>Pretty much all we need is: </div>
<div><br>
</div>
<div>1. Make custom configs to (glance|cinder|nova).conf to enable RBD backend</div>
<div>2. Create /etc/ceph/ceph.conf</div>
<div>3. Create keyring in /etc/ceph</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Regards</div>
<div>-steve</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>
<div><br>
</div>
<div>What do you think?</div>
<div><br>
</div>
<div>cheers</div>
<div>Mathias</div>
<div><br>
</div>
-- <br>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Mobil: <a href="tel:%2B49%20176%2010567592" value="+4917610567592" target="_blank">
+49 176 10567592</a><br>
E-Mail: <a href="mailto:mewald@evoila.de" target="_blank">mewald@evoila.de</a><br>
<br>
evoila GmbH<br>
Wilhelm-Theodor-Römheld-Str. 34 <br>
55130 Mainz<br>
Germany<br>
<br>
Geschäftsführer: Johannes Hiemer<br>
<br>
Amtsgericht Mainz HRB 42719<br>
<br>
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.<br>
<br>
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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>