Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130719/698cecee/attachment.html>