<div dir="ltr">Mike,<div><br></div><div>I've started a separate thread titled 'removing single mode' so that we don't thread jack the ssl conversation.</div><div><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Aug 21, 2014 at 12:27 PM, David Easter <span dir="ltr"><<a href="mailto:deaster@mirantis.com" target="_blank">deaster@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>Hi Adam,</div><div><br></div><div> Just to clarify the subtlety of this change - you can still install a single controller, but that controller will be “HA-ready” by deploying all the projects needed for HA onto that controller.  In other words, Fuel will still be able to support smaller deployments along side larger ones for those who only need one controller and a few compute nodes.</div>
<div><br></div><div>  This also enables an environment to grow overtime without redeployment.  Since everything is in place for HA, adding another controller just extends that HA (and removes the single-controller single-point-of-failure).</div>
<div><br></div><div><div>- David J. Easter</div><div>  Director of Product Management,   Mirantis, Inc.</div><div>  <img src="cid:2101E0B5-376E-4A2A-BEDE-A013B8A364B5" type="image/png"></div><div><a href="http://openstacksv.com/" target="_blank">http://openstacksv.com/</a></div>
</div><div><br></div><span><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> Adam Lawson <<a href="mailto:alawson@aqorn.com" target="_blank">alawson@aqorn.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span> Thursday, August 21, 2014 at 12:11 PM<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [Fuel] Enable SSL between client and API exposed via public URL with HAProxy<br></div><div><div class="h5"><div><br></div><div dir="ltr">IMHO, removing non-HA mode in Fuel would be a mistake as Fuel is also used for smaller deployments. HA is required for Production sure but removing support for smaller deployments would drive consumers of smaller clouds elsewhere for orchestration. Maintaining support for smaller clouds probably isn't a priority for Mirantis but I think it should be a priority for the general community consumer base. This also goes for all of the orchestrators out there whether it's SUSE, Juju, Piston, Nebulous, etc etc.<div>
<br></div><div>Just my two cents.</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><font><div style="font-family:arial;font-size:small"><b><i><br>Adam Lawson</i></b></div><div><font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">

AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste. 58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div>
<div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: <a href="tel:%2B1%20302-387-4660" value="+13023874660" target="_blank">+1 302-387-4660</a></div>
</font><font color="#666666" size="1"><div style="font-family:arial;font-size:small">
Direct: <a href="tel:%2B1%20916-246-2072" value="+19162462072" target="_blank">+1 916-246-2072</a></div></font></font></div></font></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39"><br>
</div></div></div><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 7:24 AM, Guillaume Thouvenin <span dir="ltr"><<a href="mailto:thouveng@gmail.com" target="_blank">thouveng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div>On Thu, Aug 21, 2014 at 5:02 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><br><div>Guillaume, do I understand right that without implementation of <a href="https://blueprints.launchpad.net/fuel/+spec/ca-deployment" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ca-deployment</a>, SSL support will not be fully automated? And, consequently, we can not call it as complete production ready feature for Fuel users?</div>
<br></div></blockquote><div><br></div></div><div>Yes you are right.  Without the implementation of the CA deployment  we can not consider it as ready to use.<br></div><div>To test my deployment I manually copy a self-signed certificate on all controllers on a predefined location according to what I have in the puppet manifest. So it's really just for testing. I also write a small puppet manifest to generate a self signed certificate to deploy it automatically but it works only for one controller so this solution is also only for testing.<br>
<br></div><div>So to have the feature ready for production we need to manage certificate maybe as a new option into the fuel dashboard.<br><br></div><div>Best Regards,<br></div><div>Guillaume <br></div></div></div></div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</div></div></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Andrew<div>Mirantis</div><div>Ceph community</div></div>
</div>