Ask Your Question
0

Installing Openstack; Quantum or Neutron in Grizzly??

asked 2013-07-25 22:50:44 -0500

kprad1 gravatar image

Hello, I had openstack installed using devstack with my localrc pointing to stable/grizzly Around a month ago, the installation had quantum directories and files.

Now, just a week ago, when i installed openstack in another m/c with the same localrc file, i saw the quantum directories changed to neutron. And, the some of the files themselves had different contents. My fundamental question is: 1. Is "stable/grizzly" a moving branch? Is not the current branch in Openstack "Havana"? 2. If i need to install openstack grizzly, the pre neutron release (2.2.2.a version?), how do i specify it in localrc?

Thanks, KP

edit retag flag offensive close merge delete

7 answers

Sort by ยป oldest newest most voted
0

answered 2013-08-06 09:31:16 -0500

Could somebody tell me how to install grizzly with quantum(but not neutron) step by step? Many thanks in advance!

edit flag offensive delete link more
0

answered 2013-07-27 20:40:54 -0500

pcm gravatar image

When you are specifying the *_BRANCH values, you are telling GIT which branch to clone. Without any such lines, the default is to use "master", which is the latest in the repo (Havana). However, that pulls the whole branch and not a specific version of the code on the branch, so you'll get the last commit on that branch (hence, stable/grizzly will give you the latest on a hopefully stable branch :)

If you want to use a specific version (I've never done this), I would suspect that you have to do a "git checkout" of the desired commit/tag, for each service that you want. I'm not sure if OpenStack tags the releases at all (I don't think so, but may be wrong).

However, the answer to the original question is to use the *_BRANCH settings to ensure that you have the stable/grizzly branch with quantum, instead of master (Havana) branch with neutron.

edit flag offensive delete link more
0

answered 2013-07-26 18:04:57 -0500

I am no expect, but I had a similar issue. I specified the following in localrc to get back the quantum I was used to:

NEUTRON_BRANCH=stable/grizzly

My suspicion is that they moved the repository, then created a redirect from the old location to the new location. Then devstack follows the redirect, but looses the branch specification and simply grabs the master neutron.

Somebody correct me if I am wrong.

edit flag offensive delete link more
0

answered 2013-07-26 22:47:33 -0500

pcm gravatar image

Can you share your localrc?

If you don't specify any release for the OS components, you'll get the latest version from the trunk, which is a moving target. A while back that would have been the latest Grizzly, now it is latest Havana. If you do as Matthew has mentioned, for each component, you can nail the code to a specific release/version.

edit flag offensive delete link more
0

answered 2013-07-26 22:55:05 -0500

pcm gravatar image

Here's a link with some info on the bottom about selecting a repository and branch for a service:

http://devstack.org/stackrc.html

Here's a list of lines you can use for Grizzly:

Compute service

NOVA_BRANCH=stable/grizzly

Volume Service

CINDER_BRANCH=stable/grizzly

Image Service

GLANCE_BRANCH=stable/grizzly

Web UI (Dashboard)

HORIZON_BRANCH=stable/grizzly

Auth Services

KEYSTONE_BRANCH=stable/grizzly

Quantum (Network) service

QUANTUM_BRANCH=stable/grizzly

edit flag offensive delete link more
0

answered 2013-07-27 17:01:11 -0500

kprad1 gravatar image

Thanks everyone for the answers. I already had these lines in my localrc. I also thought the same that if i specify the following as Grizzly, it will pick the same code. But that doesn't seem to be the case. Even within Grizzly, if there are tags that identify a specific version, how do i specify it in my localrc?

I pulled devstack using git clone git://github.com/openstack-dev/devstack.git git checkout stable/grizzly

Here is my localrc:

#OFFLINE=True #RECLONE=yes disable_service n-net enable_service q-svc enable_service q-agt #enable_service q-dhcp #enable_service q-l3 disable_service q-dhcp disable_service q-l3 enable_service quantum #enable_service ryu #Q_USE_NAMESPACE=False Q_PLUGIN=openvswitch HOST_NAME=$(hostname) HOST_IP=4.1.1.123 HOST_IP_IFACE=eth4 SERVICE_HOST_NAME=${HOST_NAME} SERVICE_HOST=24.2.0.123 #FLOATING_RANGE=27.7.7.xxxx Q_HOST=$SERVICE_HOST MYSQL_HOST=$SERVICE_HOST RABBIT_HOST=$SERVICE_HOST GLANCE_HOSTPORT=$SERVICE_HOST:9292 KEYSTONE_AUTH_HOST=$SERVICE_HOST KEYSTONE_SERVICE_HOST=$SERVICE_HOST ENABLE_TENANT_TUNNELS=True TENANT_TUNNEL_RANGE=8000:8500

VERBOSE=True DEBUG=True #ENABLE_TENANT_VLANS=True VNCSERVER_PROXYCLIENT_ADDRESS=3.1.1.123 VNCSERVER_LISTEN=0.0.0.0

compute service

NOVA_BRANCH=stable/grizzly

volume service

CINDER_BRANCH=stable/grizzly

image catalog service

GLANCE_BRANCH=stable/grizzly

unified auth system (manages accounts/tokens)

KEYSTONE_BRANCH=stable/grizzly

quantum service

QUANTUM_BRANCH=stable/grizzly NEUTRON_BRANCH=stable/grizzly

django powered web control panel for openstack

HORIZON_BRANCH=stable/grizzly

NOVA_INSTANCES_PATH=/opt/stack/data/nova/instances

edit flag offensive delete link more
0

answered 2013-08-07 22:32:53 -0500

pcm gravatar image

There may be some confusion on this, so let me try (feebly :) to clear things up, as once you've got the bigger picture, you may find that it's not useful to try to grab a "quantum" image. Here goes...

The OpenStack Networking component, which was named Quantum, had some copyright issue with the name. The OpenStack community then chose a new name, Neutron. Then, an effort was done (after the Grizzly release) to do the conversion. This meant renaming directories, files, CLI commands, API names, URLs, variables, messages, documentation, etc.

However, Neutron networking code IS Quantum network code. It is only a name change (and that now, new development is going forward with the new name). So, in your case, with the localrc not selecting offline mode, one run of stack.sh grabbed quantum, and a later run grabbed the new, renamed, neutron. Just two different snapshots of the same code stream, at different points in time, with the obvious point that the neutron code is newer.

For practical purposes, you may want to chose between a "stable" version of networking code with the stable/grizzly branch, or the latest "bleeding edge" network code, by not specify anything and getting the latest on the master (to eventually be the Havana release) branch.

HTHs

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-07-25 22:50:44 -0500

Seen: 70 times

Last updated: Aug 07 '13