Open Stack

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.

I'll keep bringing up decision points until you tell me to stop! :)

Anne


On Fri, Jul 19, 2013 at 3:22 PM, Anne Gentle
<annegentle at justwriteclick.com>wrote:

> Ah yes, good questions for clarifying.
>
>
> On Fri, Jul 19, 2013 at 10:50 AM, Steve Gordon <sgordon at redhat.com> wrote:
>
>> ----- Original Message -----
>> > From: "Anne Gentle" <annegentle at justwriteclick.com>
>> > To: "Shaun McCance" <shaunm at gnome.org>
>> > Cc: openstack-docs at lists.openstack.org
>> > Sent: Thursday, July 18, 2013 12:30:45 PM
>> > Subject: Re: [Openstack-docs] Intro and example installations
>> >
>> > Great work Shaun! Here are my thoughts for the example architectures.
>> >
>> > Simplest possible architecture: Compute with KVM, local ephemeral
>> > nova-volumes shared storage, nova-networks in multi-host, MySQL,
>> nova-api,
>> > default scheduler, RabbitMQ for Ubuntu, Qpid for RHEL, Identity, Image
>> with
>> > local storage, Dashboard. Use as many defaults as you can, as
>> identified by
>> > the deployment program, TripleO. Single node or two node.
>> >
>> > Operations Guide example architecture:
>> >
>> http://docs.openstack.org/trunk/openstack-ops/content/example_architecture.html
>>
>> I have two questions here, the answers to which would help me better form
>> my thoughts on this:
>>
>> 1) Wasn't nova-volumes removed in Grizzly (
>> https://blueprints.launchpad.net/nova/+spec/delete-nova-volume )?
>>
>
> 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
> http://docs.openstack.org/trunk/openstack-ops/content/storage_decision.html.
> 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.
>
>
>> 2) Isn't nova-network slated to be deprecated in Havana (
>> https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network )?
>>
>>
> 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.
>
>
>
>> 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
>> :).
>>
>>
> Again I think we mitigate the risk of docs being incorrect by plainly
> having a simple non-neutron option available.
>
>
>> 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.
>>
>
>  Yep, you're correct on block storage, my bad. Thanks for pointing it out!
> Anne
>
>
>>
>> Thanks,
>>
>> Steve
>>
>>
>> > If you can do these two for your first draft, then here are some
>> additional
>> > alternatives. The most "exciting" is probably Neutron. Block Storage is
>> > most common.
>> >
>> > Pivots on Ops Guide example:
>> > 1. Substitute Neutron for nova-network, keep everything else the same.
>> > 2. Substitute Block Storage for nova-volumes, keep everything else the
>> same.
>> > 3. Keep Ops Guide example but backend Image storage with Object Storage.
>> > 4. Include Compute, Image, Identity, Block Storage, Object Storage,
>> > Dashboard, Monitoring and Orchestration.
>> >
>> > Lower priority:
>> > Sub Xen for KVM.
>> >
>> >
>> > Anyone else have input for choosing adventures?
>>
>>
>
>
> --
> Anne Gentle
> annegentle at justwriteclick.com
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130719/3fcb2fe5/attachment-0001.html>