Re: [Openstack] quantum: two ips one vif
On Tue, 2012-10-23 at 15:14 -0700, Dan Wendlandt wrote: can you post your libvirt xml for the VM? It maybe well be libvirt filtering if you are using the OVS Hybrid vif driver: for example, a VM would have xml like: filterref filter='nova-instance-instance-0001-fa163e0569ba' parameter name='DHCPSERVER' value='10.0.0.2'/ parameter name='IP' value='10.0.0.3'/ parameter name='PROJMASK' value='255.255.0.0'/ parameter name='PROJNET' value='10.0.0.0'/ /filterref I'm not sure what the nova code would generate for multiple IPs. Libvirt's driver only supports 1 ip per interface. It needs to be updated to use the newer network models and not depend on the code in nova.virt.netutils.get_injected_network_template. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Use of MAC addresses in Openstack VMs
On Tue, 2012-10-23 at 08:43 +0800, Shake Chen wrote: On Mon, Oct 22, 2012 at 8:08 PM, Gary Kotton gkot...@redhat.com wrote: # Base MAC address. The first 3 octets will remain unchanged. If the # 4h octet is not 00, it will also used. The others will be # randomly generated. # 3 octet # base_mac = fa:16:3e:00:00:00 # 4 octet # base_mac = fa:16:3e:4f:00:00 as my know, the fa:16:3e would on behalf of a company. 0xfa has the Locally Administrated bit set. The IEEE won't allocate OUIs with this bit set. Happy Hacking! 7-11 ___ 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] Openstack-Common ZeroMQ
The zeromq tests are failing in jenkins. I created bug https://bugs.launchpad.net/openstack-common/+bug/1023060 for this. Anyone with an interest in ZeroMQ support, please help to resolve this bug. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack-Common ZeroMQ
On Tue, 2012-07-10 at 13:36 -0400, Eric Windisch wrote: The bigger issue is getting people to do the reviews... Here is the link for those that want to help: https://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z Cool rebase those off trunk, and I'll push them in. The problem is that now that pyzmq is installed on the jenkins boxen, it will prevent merging if we revert the skip tests. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Don't bypass code-review.
On Tue, 2012-07-10 at 13:52 -0400, Eric Windisch wrote: I've had code reviews sitting out for over a week, looking to fix issues with the ZeroMQ driver in openstack-common. I'd love to get it fixed, and nudged a couple of people to get the reviews in, but figured that it would get in eventually - and if not, I'd prod harder, or perhaps someone else that would want to see these problems fixed, would help review. Instead... Today, I had someone ignore my reviews in progress, push his own review, and even APPROVED his own review. What the hell? Review in question: https://review.openstack.org/#/c/9594/ (My) Reviews in progress: https://review.openstack.org/#/q/status:open+project:openstack/openstack-common+branch:master+topic:bug/1021459,n,z Jenkins was failing to merge *ANY* code reviews for openstack-common. The root of the dependency tree of your patch sets is insufficient to make the test suite pass. The set of patches needed to go in in one commit. I was ping'd on IRC to check into the tests that were failing when the build hosts got pyzmq installed on them by another patch set. I'm sorry that I bypassed the code review, but in light of nothing getting through due to the ZeroMQ tests being broken to begin with, there was not much I could do. The RPC bits got added in prior to test gating, and further these tests only trigger when pyzmq is installed. I am also to blame for ZeroMQ to be broken to begin with since I +2'd https://review.openstack.org/#/c/8372/ when it was imported from which I should have been vigilant now that I look at it closer since the commit states that the tests in nova also failed. If you would like, squash all your commits down to 1 commit so the test suite will pass, and combine that with the revert. This will allow us to proceed forward. That's the hell. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Don't bypass code-review.
On Tue, 2012-07-10 at 15:32 -0400, Eric Windisch wrote: Jenkins was failing to merge *ANY* code reviews for openstack-common. The root of the dependency tree of your patch sets is insufficient to make the test suite pass. The set of patches needed to go in in one commit. I was ping'd on IRC to check into the tests that were failing when the build hosts got pyzmq installed on them by another patch set. I'm sorry that I bypassed the code review, but in light of nothing getting through due to the ZeroMQ tests being broken to begin with, there was not much I could do. The RPC bits got added in prior to test gating, and further these tests only trigger when pyzmq is installed. I understand the dilemma, but it wasn't like I didn't have reviews in progress to address this. If the patches weren't sufficient, contacting me or giving me a -1 would have been a better option. Alternatively, you could have investigated why pyzmq might have gotten installed, and seen if it could have been disabled. Instead, you merged your change 30 minutes before contacting the mailing list or otherwise attempting communication. It took, what, 10 minutes for me to receive, read, and reply to your post? I asked on irc if anyone was interested in the ZeroMQ code prior to fixing it. But I realize I am at fault on this one. I've already pushed an updated change that collapses the changes into a larger patch that should get Jenkins going again (tests pass locally, we'll see how Jenkins feels about it) Right now, I'd just like to get past this. I'm sorry if I've been at all too rough on you. I'd just appreciate that in the future, even if the build is broken, that code review is not bypassed. Additionally, if there is a reasonable way to approach the author of code, especially if there is already a patch in review, that opposing patches aren't shoe-horned in without review or oversight. Agreed. Perhaps we should update each file with contact information for the responsible parties for each module openstack-common wide since many times the author of the code is not that who shows up in git blame. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Passing parameters from Quantum manager to Nova compute
On Wed, 2012-06-06 at 21:35 +0300, Rami Cohen wrote: Hi, While Quantum manager may communicate with compute nodes using a quantum agent, in some cases when Quantum is integrated with Nova, the agent may not be needed (while it can be used for enhanced services). In this cases, when the Quantum VIF driver (which is part of Nova compute) is used for VM provisioning/terminating/restarting utilizing the existing Nova infrastructure, it may be required to pass parameters from the quantum manager to the Quantum driver. Nevertheless, in current Nova architecture the Nova network does not pass the values returned from the quantum Manager to the compute nodes. I really think that passing the Quantum manager values to the Quantum VIF driver is really important for Quantum agent less implementation and it is quite an easy change to make. You can pass any values you want in the NetworkModel's various metadata fields, with the caveat that you must ensure that it is not required for other network managers. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] running HA cluster of guests within openstack
On Fri, 2012-04-13 at 12:31 +0300, ikke wrote: 1. Private networks between guests - Doable now using Quantum 1.1. Defining VLANs visible to guest machines to separate clusters internal traffic, VLAN tags should not be stripped by host (QinQ) VLANs and Quantum private networks are pretty much the same thing, why would you want both? 1.2. Set pre-defined MAC addresses for the guests, needed by non-IP traffic within the guest cluster (layer2 addressing) - will Melange do this, according to docs it's not in plans? If you send the mac address to Melange when you create the interface it will record it for that instance: http://melange.readthedocs.org/en/latest/apidoc.html#interfaces Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Melange Unittests
On Fri, 2012-04-06 at 13:11 +, Vaze, Mandar wrote: I tried to run ./run_tests.sh (without virtualenv) I kept on getting error related to unable to find config file I ran the tests from /opt/stack/mélange Same errors when I run python run_tests.py /opt/stack/mélange/etc/mélange/mélange.conf is present and valid. How do I pass the config file to run_tests ? (Shouldn't it pick it up automatically) The nova test runner is busted. We had converted it to use tox, but as Brian/James has found out there is an issue with the openstack.nose_plugin and something in melange causing tests to not be picked up by the collector. For the time being edit setup.cfg and comment out lines 32-EOF. Since melange is merging with quantum, my plan is to fix them as I merge them into the quantum tests. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Melange Unittests
On Fri, 2012-04-06 at 00:04 +, Brian Lamar wrote: Can anyone enlighten me as to why the gate-melange-unittests-python26 job is only running a single test? The first time it ran it correctly found all 500+ tests but now it seems to be just running one. :( This is happening locally for me too and I'm not quite sure where the disconnect is. I don't see any obvious changes in the code between the good/bad test runs that might account for this discrepancy. Any pointing in the right direction would be appreciated! Good Run: https://jenkins.openstack.org/job/gate-melange-unittests-python26/1/console Bad Run: https://jenkins.openstack.org/job/gate-melange-unittests-python26/2/console I haven't looked at it at all, but my gut instinct is its another namespace issue. Try moving the tests directory out of the package's namespace into the root of the repo and see if it picks up the tests correctly there. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] melange_ipam : get_tenant_id_by_net_id - possible bug (and fix)
Hi Mandar, Thanks for taking the time to look into Melange! Currently Nova + Quantum + Melange is in a huge state of development flux. The current code gets us enough to play with some features and be backwards compatible with all the features in the legacy network managers. In the Folsom development cycle many things in regards to QuantumManager will be changing. See below for (some) specifics. On Wed, 2012-03-28 at 05:20 -0700, Mandar Vaze wrote: I've setup nova+quantum+mélange using devstack. devstack creates networks using tenant_id =default (This in itself looks incorrect, since it should be valid UUID for one of the tenant from keystone DB - but I can imagine that stack.sh can't get UUID for demo or admin tenants easily) Since nova-manage doesn't do any auth, the project_id in the call to create the initial network is None, this triggers the QuantumManager to fall back to using the value of FLAGS.quantum_default_tenant_id which defaults to the value 'default'. There really isn't a good way to get around this right now (without manually specifying the project_id as mentioned below). Since some data is stored in the Nova networks table, some in melange and some (possibly) by whatever quantum plugin is running. In the next iteration, using nova-manage to create Quantum/Melange blocks magically in the background will be removed, and will require that each service be setup through their native tools/apis. So I updated nova.networks, quantum.networks and mélange.ip_blocks tables manually and put tenant_id to use UUID of the demo tenant. Question : What is the right way to create network entries for demo tenant, that are used by nova/quantum as well as mélange DB ? I think (although never tried) you can pass --project_id to nova-manage and it should create it with the right tentat_id. (I tried mélange ip-block create for 10.0.0.0/24 but I got an error that that cidr is already being used (by tenant_id=default) - so I updated the DB manually. Also this would work only take care of mélange DB - what about nova and quantum DB ?) You can pass the -t flag to the melange cli to switch the tenant name. The quantum and nova db's will need to be updated manually at the moment. Once I did these changes, my instances could not launch, they would get stuck in Networking/Error state - with NetworkNotFound error in the logs for network UUID which I know is valid for tenant demo So depending on where the error was poping up at, it might have been that it was getting a UUID where the code was expecting the network id from the nova table. This is part of the problem of having 3 masters of information, and work has begin to reduce this to 2 and eventually just 1 with melange merging with quantum. Tracing this further, I came across the following code which tries to get_allocated_ips for default tenant, before user specified project_id In my opinion, this is incorrect. Once I switched the order i.e. try project_id before default everything started working. Please comment whether the following code change makes sense (I'm not even sure, if I were to submit this code change - what would I write in the bug description - hence need comments from you) diff --git a/nova/network/quantum/melange_ipam_lib.py b/nova/network/quantum/melange_ipam_lib.py index c68d83c..ea39f60 100644 --- a/nova/network/quantum/melange_ipam_lib.py +++ b/nova/network/quantum/melange_ipam_lib.py @@ -152,7 +152,8 @@ class QuantumMelangeIPAMLib(object): def get_tenant_id_by_net_id(self, context, net_id, vif_id, project_id): ipam_tenant_id = None -tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None] +#tenant_ids = [FLAGS.quantum_default_tenant_id, project_id, None] +tenant_ids = [project_id,FLAGS.quantum_default_tenant_id, None] # This is confusing, if there are IPs for the given net, vif, # tenant trifecta we assume that is the tenant for that network for tid in tenant_ids: The order shouldn't matter since the idea is to match the first block that the network exists in. The problem is that its triggering moving on to the next block in the list via a KeyError which won't be caught if the default_tenant_id lookup throws a 404 (which it will if the block doesn't exist ;). If you change the `except KeyError` to `except Exception` since the melange_connection raises a bare Exception when the response is 400. I filed bug 967261 at https://bugs.launchpad.net/nova/+bug/967261 and submitted the fix at https://review.openstack.org/5912 . The current QuantumManger tries (much like nova) to be very flexible and make no assumptions about how things are setup. I've been playing with a new network manager that I would like to see as the next iteration of Quantum + Melange + Nova that is very opinionated and stripped down. It assumes you are using melange and quantum only, it only communicates with nova over rpc (no nova db tables are
[Openstack-poc] [Bug 951197] [NEW] openstack namespace does not play nicely with checkedout repos
Public bug reported: Both openstack.common and openstack.nose_plugin declare the 'openstack' namespace. When one package is installed it breaks pythons search path of ./ for modules. This breaks update.py for example which is meant to be run out of the os-common checkout directory. It imports cfg from openstack.common, but since it is not installed it cannot be found: site-packages$ ls openstack* openstack.nose_plugin-0.5-py2.7-nspkg.pth openstack: nose_plugin.py nose_plugin.pyc openstack.nose_plugin-0.5-py2.7.egg-info: dependency_links.txt installed-files.txt PKG-INFO SOURCES.txt entry_points.txt namespace_packages.txt requires.txt top_level.txt common$ python update.py Traceback (most recent call last): File update.py, line 64, in module from openstack.common import cfg ImportError: No module named common Since update.py is a temporary workaround for incubation we *could* hack it to inject ./openstack/common into the openstack namespace, but there might be a better way. Need to research. ** Affects: openstack-common Importance: Undecided Assignee: Jason Kölker (jason-koelker) Status: Confirmed ** Changed in: openstack-common Assignee: (unassigned) = Jason Kölker (jason-koelker) ** Changed in: openstack-common Status: New = Confirmed -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/951197 Title: openstack namespace does not play nicely with checkedout repos Status in openstack-common: Confirmed Bug description: Both openstack.common and openstack.nose_plugin declare the 'openstack' namespace. When one package is installed it breaks pythons search path of ./ for modules. This breaks update.py for example which is meant to be run out of the os-common checkout directory. It imports cfg from openstack.common, but since it is not installed it cannot be found: site-packages$ ls openstack* openstack.nose_plugin-0.5-py2.7-nspkg.pth openstack: nose_plugin.py nose_plugin.pyc openstack.nose_plugin-0.5-py2.7.egg-info: dependency_links.txt installed-files.txt PKG-INFO SOURCES.txt entry_points.txt namespace_packages.txt requires.txt top_level.txt common$ python update.py Traceback (most recent call last): File update.py, line 64, in module from openstack.common import cfg ImportError: No module named common Since update.py is a temporary workaround for incubation we *could* hack it to inject ./openstack/common into the openstack namespace, but there might be a better way. Need to research. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-common/+bug/951197/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug launching instance in Essex packages on Precise - for nw, info in nw_info: too many values to unpack (network/manager.py)
On Thu, 2012-02-16 at 14:56 +, Kevin Jackson wrote: Hi Jason, This has worked - but introduced some further bugs. The instance spawns, but there is no float_ip information presented to my client tools. $ nova list +--+--+++ | ID | Name | Status |Networks| +--+--+++ | ef06e2f4-0d38-46b6-ba54-944f36aa1f40 | Server 2 | ACTIVE | vmnet=10.0.0.5 | +--+--+++ But looking at the database it has been assigned a floating ip that I can connect to. I submitted the previous patch for review and added in some debug statements. Can you pull in the changes to nova/api/openstack/common.py from https://review.openstack.org/4236 and let me know what the values being logged are? Happy hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Bug launching instance in Essex packages on Precise - for nw, info in nw_info: too many values to unpack (network/manager.py)
On Tue, 2012-02-14 at 20:43 +, Kevin Jackson wrote:
Dear cloud folk,
I raised https://bugs.launchpad.net/nova/+bug/928819 last week that's
not getting any love so was wondering if it was user error rather than
a bug (as its a show stopper for my setup that I previously didn't
have).
I think this diff might fix it:
diff --git a/nova/network/manager.py b/nova/network/manager.py
index e42e066..502baba 100644
--- a/nova/network/manager.py
+++ b/nova/network/manager.py
@@ -299,10 +299,8 @@ class FloatingIP(object):
self.db.floating_ip_set_auto_assigned(context,
floating_address)
# get the first fixed address belonging to the instance
-for nw, info in nw_info:
-if info.get('ips'):
-fixed_address = info['ips'][0]['ip']
-break
+fixed_ips = nw_info.fixed_ips()
+fixed_address = fixed_ips[0]['address']
# associate the floating ip to fixed_ip
self.associate_floating_ip(context,
I unfortunately do not have the setup to test it. If it works for you
let me know, and I'll merge prop it to trunk.
Happy Hacking!
7-11
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Remove Zones code - FFE
On Wed, 2012-02-15 at 00:00 +, Monsyne Dragon wrote: On Feb 14, 2012, at 1:25 PM, Jay Pipes wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection - Set - Cell - Huddle - Constellation - Herd/Flock//Pod/Animal metaphor of choice. - System % Flange ;) Happy Hacking! 7-11 ___ 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-poc] [Bug 925775] [NEW] utils.import_object sometimes masks the failed import
Public bug reported:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
** Affects: openstack-common
Importance: Undecided
Status: Confirmed
--
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/925775
Title:
utils.import_object sometimes masks the failed import
Status in openstack-common:
Confirmed
Bug description:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/925775/+subscriptions
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 925775] Re: utils.import_object sometimes masks the failed import
** Changed in: openstack-common
Status: New = Confirmed
--
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/925775
Title:
utils.import_object sometimes masks the failed import
Status in openstack-common:
Confirmed
Bug description:
146 def import_class(import_str):
147 Returns a class from a string including module and class
148 mod_str, _sep, class_str = import_str.rpartition('.')
149 try:
150 __import__(mod_str)
151 return getattr(sys.modules[mod_str], class_str)
152 except (ImportError, ValueError, AttributeError):
153 raise exception.NotFound('Class %s cannot be found' % class_str)
From time to time we are seeing the exception raised without the
class_str being filled in making it fun to track down what is not
installed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/925775/+subscriptions
___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] openstack-common
On Tue, 2012-01-03 at 21:38 +, Mark McLoughlin wrote: As a related note, I'm going to get the current repo moved in to gerrit today or tomorrow. It's more Jason's call, but I think we're basically asking you to hold off on that for a little while. We may decide to start a new repo. I've got Melange going off a non-master branch from my github repo at the moment, so we could start with a clean repo and not have to worry about breaking melange while we figure out the api on our side should look like after surveying the other projects. I'm 50/50 on the blank slate approach. I'm leaning towards just taking what is there as is, and just start refactoring it as needed. Since melange is running off the other branch, we won't have to worry about compat at first and can make sweeping changes. One thing I would like to ask is if we could not use run_tests.sh/run_tests.py in the jenkins job as I'd like to remove it. Currently in the setup.cfg there is a note on how to get the same output (style wise) with nosetests. The only downside is I haven't written a nose venv plugin yet, but if we move it to tox, then that shouldn't be needed anyway. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] openstack-common
On Tue, 2012-01-03 at 13:49 -0800, Monty Taylor wrote: It's more Jason's call, but I think we're basically asking you to hold off on that for a little while. We may decide to start a new repo. Oh - ok. My bad - I'll learn to read entire threads next time... Let let me know when it's ready to go or if there's anything you want from me helpwise. Sorry, my bad on not keeping up with things ;). If you get a chance go ahead and pull it into gerrit as is, we can handle any changes we want through reviews. (See my note in the other email about preferring to run the tests with nosetests vs run_tests.sh though). Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Database stuff
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote: It seems I've talked myself into preferring option e). It's too much work to do on my own, though, and it's going to be disruptive, so we need to do it real soon. I think it'll be worth it, though. I agree. This will also make it easier to swap out the storage with other Non-SQLAlchemy datastores *cough* ElasticSearch *cough*. On the network side of things, I've spend the last few weeks untie-ing network FK's and joinloads for the untie-nova-network-models blueprint. Those will be merge prop'd as soon as I get some merge conflicts squared away. Also Trey is working on a standardized Network Model objects that is really just a dict++ so serialization is easy. Our plan on in the network fiefdom is to pass around only these objects eventually to get us off relying on the underlying SQLAlchemy objects. Happy Hacking! 7-11 ___ 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] openstack.common module (was: Re: [RFC] Common config options module)
On Mon, 2011-11-28 at 20:57 +, Mark McLoughlin wrote: Hi Jason, On Mon, 2011-11-28 at 10:24 -0600, Jason Kölker wrote: On Mon, 2011-11-28 at 08:06 -0800, Monty Taylor wrote: The idea is to unify option handling across projects with this new API. The module would eventually (soon?) live in openstack-common. Awesome. So - whaddya think about making openstack-common an installable/consumable module? I've extracted openstack-common as a stanalone module from openstack-skeleton at https://github.com/jkoelker/openstack-common for melange. I also converted the rest of openstack-skeleton to a paster template in the openstack-paste repo. Its there for the picking if anyone wants to use it. I'd love to see a unified effort on some front extracting bits and moving them into the openstack namespace as an official gerrit, et. al. project. Happy Hacking! Cool stuff. I'll dig into it soon and send you a pull request with the cfg module. So along these lines. Melange currently relies on that openstack-common repo/namespace. As it Melange is moving to gerrit, are there any objections to promoting that openstack-common repo to gerrit as well? Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [RFC] Common config options module
On Mon, 2011-11-28 at 08:06 -0800, Monty Taylor wrote: The idea is to unify option handling across projects with this new API. The module would eventually (soon?) live in openstack-common. Awesome. So - whaddya think about making openstack-common an installable/consumable module? I've extracted openstack-common as a stanalone module from openstack-skeleton at https://github.com/jkoelker/openstack-common for melange. I also converted the rest of openstack-skeleton to a paster template in the openstack-paste repo. Its there for the picking if anyone wants to use it. I'd love to see a unified effort on some front extracting bits and moving them into the openstack namespace as an official gerrit, et. al. project. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New git-review tool ready for people to try
On Thu, 2011-10-13 at 13:03 -0400, Monty Taylor wrote: Amongst things git-review does: Rebases against the branch you're submitting to, rather than against the place you cloned from Allows you to skip rebasing if you want Submit against a named branch Explicitly set the topic Downloads commit-msg hook if needed Sets up the gerrit remote if needed - and knows how to map having cloned the repo from somewhere else to the gerrit repo you mean. I'm wondering why not just use android's `repo` tool that does most of this already and just add extra hooks or features to it (not sure if it does named branch submission or topics currently). Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] dns issue?
On Mon, 2011-10-10 at 16:07 -0400, Sharif Islam wrote: I am still stuck with this problem: my instances can ping only with ip addresses. I deleted nova-network and created it again and then fired up an instance. But still resolv.conf shows nameserver 10.0.1.1. I only have one instance running now, this is not the route looks (a.b.c.d is my public ip. v.x.y.z is my nova network host): # iptables -L -t nat|grep 10.0 DNAT all -- anywhere a.b.c.d to:10.0.1.2 ACCEPT all -- 10.0.0.0/8 10.128.0.0/24 ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 DNAT all -- anywhere a.b.c.d to:10.0.1.2 SNAT all -- 10.0.1.2 anywhereto:a.b.c.d SNAT all -- 10.0.0.0/8 anywhereto:v.x.y.z mysql select * from networks \G *** 1. row *** created_at: 2011-10-10 18:32:06 updated_at: 2011-10-10 18:32:54 deleted_at: NULL deleted: 0 id: 24 injected: 0 cidr: 10.0.1.0/24 netmask: 255.255.255.0 bridge: br100 gateway: 10.0.1.1 broadcast: 10.0.1.255 dns: 8.8.4.4 vlan: NULL vpn_public_address: NULL vpn_public_port: NULL vpn_private_address: NULL dhcp_start: 10.0.1.2 project_id: NULL host: i26 cidr_v6: NULL gateway_v6: NULL label: public netmask_v6: NULL 1 row in set (0.00 sec) root@i-0499:~# cat /etc/resolv.conf domain novalocal search novalocal nameserver 10.0.1.1 How does nova assign the nameserver to the VMs? Can I change it someone so it has 8.8.4.4? I assume you are using Vlan or Flatdhcp? If so add --dns-server=8.8.4.4 to your flags file. The network managers that use dnsmasq do not respect the db entries. Happy Hacking! 7-11 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova-manage network modifications feedback request
On Mon, 2011-07-11 at 19:33 -0700, Dan Wendlandt wrote: Given that we're reworking the commands (and potentially breaking peoples' scripts), it might make sense to add a type field to the network create command to provide future flexibility to introducing different types of networks that can be created by nova-manage, particularly Quantum networks. Nova's existing model of L2 networking is very specific to Linux bridging and fields like [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] don't really make sense, but other fields will. I would think that type would be inferred by which network_manager is running, but I'm not opposed to adding it. I could see it being useful to trigger a separate subcommand for arguments something like: nova-manage network create TYPE [...] Then depending on type the rest of the flags would change so we would have: nova-manage network create nova [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] and nova-manage network create quantum [QUANTUM_SPECIFIC_OPTION, ...] The only thing I'm concerned about then is the divergence of the api entry to the network_manager(s) and ending up with overloaded command structures like we currently have. I would really like to see the network_management functions completely removed from nova proper and the current network_managers repackaged as a reference implementation. Interaction with the network_manager to/from nova should only occur over the rpc mechanism through a defined protocol. In this situation, I think each network_management implementation would have its own command set. It would be great to coordinate these changes. Do you know when you expect your branch ( https://code.launchpad.net/~jason-koelker/nova/separate_networks, I believe?) to hit? I have a little bit more cleaning up to do, mainly just the commands, then some testing, hopefully by the end of the week or early next week I'll be ready to merge-prop it. Happy Hacking! 7-11 -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? ___ 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-manage network modifications feedback request
Hi all, I am work on being able to use ipv6 without the ipv4 requirement. To do this I am generalizing the concept of subnets so that any data link (bridge) can be assigned more than one subnet of which any number of them may be an ipv4 or an ipv6 subnet. I've seen some bugs popping up with the the syntax of the nova-manage and would like to solicit feedback on altering the `network create` commands. Currently the command is in the form of: nova-manage network create LABEL CIDR [NUM_NETWORKS] [NETWORK_SIZES] [VLAN_START] [VPN_START] [FIXED_RANGE_V6] [GATEWAY_V6] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] I would propose this be changed to: nova-manage network create LABEL [VLAN_START] [FLAT_NETWORK_BRIDGE] [BRIDGE_INTERFACE] nova-manage subnet create NETWORK_ID CIDR [GATEWAY] [DBS] [VPN_START] I would also update the `network create` and `network list` to print out the network id so it can easily be looked up for creating subnets. As with the current command, a '0' will indicate a skipped option. The largest distinction here is that the command (and nova) does not differentiate between v4 and v6 subnets and should use netaddr to do the right thing. It also removes the automatic subnetting the current command allows and forces the user to explicitly create each subnet. Thoughts? Happy Hacking! 7-11 -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
