Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

2012-07-11 Thread Gregory_Althaus


-Original Message-
From: openstack-bounces+gregory_althaus=dell@lists.launchpad.net 
[mailto:openstack-bounces+gregory_althaus=dell@lists.launchpad.net] On 
Behalf Of Vishvananda Ishaya
Sent: Wednesday, July 11, 2012 10:27 AM
To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)
Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

Hello Everyone,

Now that the PPB has decided to promote Cinder to core for the Folsom release, 
we need to decide what happens to the existing Nova Volume code. As far as I 
can see it there are two basic strategies. I'm going to give an overview of 
each here:

Option 1 -- Remove Nova Volume
==

Process
---
 * Remove all nova-volume code from the nova project
 * Leave the existing nova-volume database upgrades and tables in
   place for Folsom to allow for migration
 * Provide a simple script in cinder to copy data from the nova
   database to the cinder database (The schema for the tables in
   cinder are equivalent to the current nova tables)
 * Work with package maintainers to provide a package based upgrade
   from nova-volume packages to cinder packages
 * Remove the db tables immediately after Folsom

Disadvantages
-
 * Forces deployments to go through the process of migrating to cinder
   if they want to use volumes in the Folsom release

Option 2 -- Deprecate Nova Volume
=

Process
---
 * Mark the nova-volume code deprecated but leave it in the project
   for the folsom release
 * Provide a migration path at folsom
 * Backport bugfixes to nova-volume throughout the G-cycle
 * Provide a second migration path at G
 * Package maintainers can decide when to migrate to cinder

Disadvantages
-
 * Extra maintenance effort
 * More confusion about storage in openstack
 * More complicated upgrade paths need to be supported

Personally I think Option 1 is a much more manageable strategy because the 
volume code doesn't get a whole lot of attention. I want to keep things simple 
and clean with one deployment strategy. My opinion is that if we choose option 
2 we will be sacrificing significant feature development in G in order to 
continue to maintain nova-volume for another release.

But we really need to know if this is going to cause major pain to existing 
deployments out there. If it causes a bad experience for deployers we need to 
take our medicine and go with option 2. Keep in mind that it shouldn't make any 
difference to end users whether cinder or nova-volume is being used. The 
current nova-client can use either one.

Vish


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

+1 for Option 1.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


[Openstack] Ubuntu Precise 12.04 Beta 2 Swift

2012-04-14 Thread Gregory_Althaus
Hi All,

I tried starting the swift-proxy on my Ubuntu Precise Beta2 with latest 
packages (1.4.8 swift).  I get this as an error.  I was wondering if anyone 
else is seeing this.

Webob on the system 1.1.1.

Thanks,
Greg

root@d00-0c-29-e7-b3-52:/etc/swift# /usr/bin/swift-init proxy-server start
Starting proxy-server...(/etc/swift/proxy-server.conf)
Traceback (most recent call last):
  File /usr/bin/swift-proxy-server, line 22, in module
run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
  File /usr/lib/python2.7/dist-packages/swift/common/wsgi.py, line 122, in 
run_wsgi
loadapp('config:%s' % conf_file, global_conf={'log_name': log_name})
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, 
in loadapp
return loadobj(APP, uri, name=name, **kw)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 271, 
in loadobj
global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 296, 
in loadcontext
global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 320, 
in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 450, 
in get_context
global_additions=global_additions)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 562, 
in _pipeline_app_context
for name in pipeline[:-1]]
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 454, 
in get_context
section)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 476, 
in _context_from_use
object_type, name=use, global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 406, 
in get_context
global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 296, 
in loadcontext
global_conf=global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 328, 
in _loadegg
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 620, 
in get_context
object_type, name=name)
  File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 640, 
in find_egg_entry_point
pkg_resources.require(self.spec)
  File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 686, in require
needed = self.resolve(parse_requirements(requirements))
  File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 588, in resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (WebOb 1.1.1 (/usr/lib/python2.7/dist-packages), 
Requirement.parse('WebOb==1.0.8'))

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


[Openstack] Nova changes for Diablo

2011-11-21 Thread Gregory_Althaus
Hi,

I've checked in an updated barclamp for nova.  This has options cleaned up and 
simplified (I think).  Paul and I have been working on the networking options.

There are now six networking options and three proposal references.  That is 
all the config that you really need to mess with on working with Nova.  Most 
can be defaulted.  I need to think about this a little more.

The three proposal references:
Glance,
Keystone,
Mysql

You need one of each those before you can run nova.  The create proposal 
routine will take the first of them if they exist.  You should be able to take 
the defaults on all of the barclamps to get a running system. (mysql, keystone, 
glance, nova_dashboard, nova should work).

The six network options are:
dhcp_enabled - true - Tells nova to run dhcpmasq to hand out addresses.  The 
other method uses injection to put the address into the system (this only works 
for Ubuntu guests).
tenant_vlans - true -Tells nova to use custom vlans for each keystone tenant.  
The networks are automatically assigned until they are exhausted.
ha_enabled - true - Tells nova to run the system in HA networking mode.  This 
means run a network and an api service on each compute node to remove a single 
point of failure issue.

num_networks - 1 - Tells nova the number of networks that can be carved out of 
nova-fixed network
network_size - 256 - The size of the networks to carve out.  This should be a 
power of two number.

allow_same_net_traffic - false - Tells nova to allow same net traffic among vms 
on the same net.  The default is more secure.  You can use security groups to 
get around some of this.

NOTES:
While the first three options define 8 possible modes, only 6 are actually 
useable.  If tenant_vlans is true, then dhcp_enabled must be true as well.  
Nova doesn't have a concept of running custom vlans without DHCP.

The num_networks and network_size need to define a network scheme that is 
contained in the nova_fixed network.  The default nova_fixed is a class C 
address space (256 addresses).  This means that 1 256 address network can be 
defined, or 2 128 address networks, or 4 64 address networks,    Making the 
nova_fixed address space bigger or smaller will require changes to these two 
variables.

Thanks,
Greg

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp