<div dir="ltr">Another area that a decision has to be made in the opinionated installs is around nova-conductor, which receives requests over RPC. It was introduced in Grizzly to proxy database calls and API calls. It decouples nova-compute and the database, to enable rolling upgrades. However the Security Guide calls it out as too insecure to run because it cannot verify who messages come from. So in the opinionated install you'd have to discuss when to use nova-conductor. <div>
<br></div><div style>I'll keep bringing up decision points until you tell me to stop! :)</div><div style><br></div><div style>Anne</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 3:22 PM, Anne Gentle <span dir="ltr"><<a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.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">Ah yes, good questions for clarifying.<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">
On Fri, Jul 19, 2013 at 10:50 AM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>----- Original Message -----<br>
> From: "Anne Gentle" <<a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>><br>
> To: "Shaun McCance" <<a href="mailto:shaunm@gnome.org" target="_blank">shaunm@gnome.org</a>><br>
> Cc: <a href="mailto:openstack-docs@lists.openstack.org" target="_blank">openstack-docs@lists.openstack.org</a><br>
> Sent: Thursday, July 18, 2013 12:30:45 PM<br>
> Subject: Re: [Openstack-docs] Intro and example installations<br>
><br>
> Great work Shaun! Here are my thoughts for the example architectures.<br>
><br>
> Simplest possible architecture: Compute with KVM, local ephemeral<br>
> nova-volumes shared storage, nova-networks in multi-host, MySQL, nova-api,<br>
> default scheduler, RabbitMQ for Ubuntu, Qpid for RHEL, Identity, Image with<br>
> local storage, Dashboard. Use as many defaults as you can, as identified by<br>
> the deployment program, TripleO. Single node or two node.<br>
><br>
> Operations Guide example architecture:<br>
> <a href="http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html" target="_blank">http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html</a><br>
<br>
</div>I have two questions here, the answers to which would help me better form my thoughts on this:<br>
<br>
1) Wasn't nova-volumes removed in Grizzly ( <a href="https://blueprints.launchpad.net/nova/+spec/delete-nova-volume" target="_blank">https://blueprints.launchpad.net/nova/+spec/delete-nova-volume</a> )?<br></blockquote>
<div><br></div></div><div>Yes. I shouldn't have said "nova-volumes" in my simplest possible, I should have said ephemeral storage on the local compute node, not attachable storage. See <a href="http://docs.openstack.org/trunk/openstack-ops/content/storage_decision.html" target="_blank">http://docs.openstack.org/trunk/openstack-ops/content/storage_decision.html</a>. I believe that's the very simplest you can do, let the compute nodes use the local storage available to them, managed by nova alone.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2) Isn't nova-network slated to be deprecated in Havana ( <a href="https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network" target="_blank">https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network</a> )?<br>
<br></blockquote><div><br></div></div><div>Yes but neutron is not yet an acceptable replacement, nor do we know if it will be in Havana. So my guess is that the work to deprecate nova-network will be delayed again. I don't know this for certain, though, so the safest thing for docs to do is to have the easiest/simplest still use nova-networks. Happy to hear dissension around this point but with lack of HA in L3 plus major complexity of SDN I just don't think it's right to use neutron for the simplest install.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I know the intent is to "keep it simple stupid" but is it realistic to continue to avoid Cinder and Neutron at this point if their predecessors are on the way out the door? Admittedly networking in neutron is more complicated for the simple case than it is in nova-network, and deprecation doesn't (yet) mean removal, but thought I would pose the question. It is of course possible I have misinterpreted the outcomes of the above blueprints :).<br>
<br></blockquote><div><br></div></div><div>Again I think we mitigate the risk of docs being incorrect by plainly having a simple non-neutron option available. </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think you could get away with not doing block storage using nova-volumes or Cinder at all in the most basic architecture and then provide it as the first "bolt on" component.<br></blockquote><div><br></div></div>
<div>
Yep, you're correct on block storage, my bad. Thanks for pointing it out!</div><div>Anne</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Steve<br>
<div><div><br>
<br>
> If you can do these two for your first draft, then here are some additional<br>
> alternatives. The most "exciting" is probably Neutron. Block Storage is<br>
> most common.<br>
><br>
> Pivots on Ops Guide example:<br>
> 1. Substitute Neutron for nova-network, keep everything else the same.<br>
> 2. Substitute Block Storage for nova-volumes, keep everything else the same.<br>
> 3. Keep Ops Guide example but backend Image storage with Object Storage.<br>
> 4. Include Compute, Image, Identity, Block Storage, Object Storage,<br>
> Dashboard, Monitoring and Orchestration.<br>
><br>
> Lower priority:<br>
> Sub Xen for KVM.<br>
><br>
><br>
> Anyone else have input for choosing adventures?<br>
<br>
</div></div></blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a>
</div>