Re: [Openstack] OpenStack and IGMP
Thanks for the answer Dan, Now I know everything I need. On Fri, Aug 24, 2012 at 10:32 PM, Dan Wendlandt wrote: > Hi Juris, > > Some more detail would be useful here. It sounds like you're trying > to use multicast, for which IGMP is a control protocol. Is it that > you're trying to run nova VMs and make sure they can participate in > multicast groups? Basic flat Nova networking connects VMs directly to > a physical network, so the configuration of multicast on the routers > (and IGMP snooping on the switches) is generally something that would > happen outside the scope of openstack configuration. For private > networks in VlanManager mode or with Quantum, the existing L3 > forwarding logic does not run a daemon that participates in IGMP, so > there's no out-of-the box way to get IGMP working between a private > network and the external network in your data center, I suspect (my > guess is that you'd have to muck with making the host running > nova-network or the quantum-l3-agent also run a multi-cast aware > routing software, like Quagga). In the future, Quantum will enable > pluggable back-ends for "logical routers", in which case you'll be > able to get routing back-ends from different vendors and projects, > many of which will support IGMP. > > Dan > > > On Fri, Aug 24, 2012 at 3:59 AM, Juris wrote: >> Hi all, >> >> Do you have any experience configuring OpenStack to work with IGMP traffic? >> If I have IGMP server and appropriate network infrastructure, what is >> the best way to bound it with one of OpenStack's private networks? >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > > -- > ~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~ ___ 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] Cannot create snapshots of instances running not on the controller
Il giorno 25/ago/2012, alle ore 01:15, Vishvananda Ishaya
ha scritto:
> Actually it looks like a different error. For some reason container format is
> being sent in as none on the second node.
>
> Is it possible the original image that you launched the vm from has been
> deleted? For some reason it can't determine the container format.
Nope, the image from which the instance has been created is still there.
>
> If not, can you also make sure that your versions of glance and
> python-glanceclient are the same on both nodes?
>
> you should be able to do `pip freeze` to see the installed versions.
I'm using the latest version from ubuntu 12.04 repo, btw, i can see only:
glance==2012.1
from pip freeze, no python-glanceclient there.
>
>
> Vish
>
> On Aug 24, 2012, at 12:10 AM, Alessandro Tagliapietra
> wrote:
>
>> Hi Vish,
>>
>> I had already a setting:
>>
>> glance_api_servers=10.0.0.1:9292
>>
>> i've also tried to add
>>
>> glance_host=10.0.0.1
>>
>> but i got the same error.. Also, after changing configuration and restarting
>> nova-compute restarts all instances, is that normal?
>>
>> Best
>>
>> Alessandro
>>
>> Il giorno 23/ago/2012, alle ore 20:24, Vishvananda Ishaya
>> ha scritto:
>>
>>> looks like the compute node has a bad setting for glance_api_servers on the
>>> second node.
>>>
>>> because glance_api_servers defaults to $glance_host:$glance_port, you
>>> should be able to fix it by setting:
>>>
>>> glance_host =
>>>
>>> in your nova.conf on the second node.
>>>
>>> Vish
>>>
>>> On Aug 23, 2012, at 10:15 AM, Alessandro Tagliapietra
>>> wrote:
>>>
Hi all,
i've a controller which is running all service and a secondary controller
which is un multi_host so it's running compute network and api-metadata.
From the dashboard i can successfully create snapshots of instances
running on the controller but when i try to create a snapshot of an
instance on a compute node i get in its logs:
==> /var/log/nova/nova-compute.log <==
2012-08-23 19:08:14 ERROR nova.rpc.amqp
[req-66389a04-b071-4641-949b-3df04da85d08 a63f5293c5454a979bddff1415a216f6
e8c3367ff91d44b1ab1b14eb63f48bf7] Exception during message handling
2012-08-23 19:08:14 TRACE nova.rpc.amqp Traceback (most recent call last):
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/rpc/amqp.py", line 253, in
_process_data
2012-08-23 19:08:14 TRACE nova.rpc.amqp rval = node_func(context=ctxt,
**node_args)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/exception.py", line 114, in wrapped
2012-08-23 19:08:14 TRACE nova.rpc.amqp return f(*args, **kw)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 183, in
decorated_function
2012-08-23 19:08:14 TRACE nova.rpc.amqp sys.exc_info())
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/contextlib.py", line 24, in __exit__
2012-08-23 19:08:14 TRACE nova.rpc.amqp self.gen.next()
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 177, in
decorated_function
2012-08-23 19:08:14 TRACE nova.rpc.amqp return function(self, context,
instance_uuid, *args, **kwargs)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 952, in
snapshot_instance
2012-08-23 19:08:14 TRACE nova.rpc.amqp self.driver.snapshot(context,
instance_ref, image_id)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/exception.py", line 114, in wrapped
2012-08-23 19:08:14 TRACE nova.rpc.amqp return f(*args, **kw)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py", line
714, in snapshot
2012-08-23 19:08:14 TRACE nova.rpc.amqp image_file)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/image/glance.py", line 306, in
update
2012-08-23 19:08:14 TRACE nova.rpc.amqp
_reraise_translated_image_exception(image_id)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/nova/image/glance.py", line 304, in
update
2012-08-23 19:08:14 TRACE nova.rpc.amqp image_meta =
client.update_image(image_id, image_meta, data)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/glance/client.py", line 195, in
update_image
2012-08-23 19:08:14 TRACE nova.rpc.amqp res = self.do_request("PUT",
"/images/%s" % image_id, body, headers)
2012-08-23 19:08:14 TRACE nova.rpc.amqp File
"/usr/lib/python2.7/dist-packages/glan
Re: [Openstack] Quantum vs. Nova-network in Folsom
Stackers, I think this is a reasonable approach and appreciate the clarification of use-cases. We've been discussing using Open vSwitch as the basis for non-Quantum Nova Networking deployments in Folsom. While not Quantum, it feels like we're bringing Nova Networking a step closer to some of the core technologies that Quantum uses. I'm interested in hearing what other's in the community think about this approach. Rob -Original Message- From: openstack-bounces+rob_hirschfeld=dell@lists.launchpad.net [mailto:openstack-bounces+rob_hirschfeld=dell@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Friday, August 24, 2012 5:39 PM To: openstack@lists.launchpad.net; OpenStack Development Mailing List Subject: [Openstack] Quantum vs. Nova-network in Folsom tl;dr both Quantum and nova-network will be core and fully supported in Folsom. Hi folks, Thierry, Vish and I have been spending some talking about OpenStack networking in Folsom, and in particular the availability of nova-network now that Quantum is a core project. We wanted to share our current thinking with the community to avoid confusion. With a project like OpenStack, there's a fundamental trade-off between the rate of introducing new capabilities and the desire for stability and backward compatibility. We agreed that OpenStack is a point in its growth cycle where the cost of disruptive changes is high. As a result, we've decided that even with Quantum being core in Folsom, we will also continue to support nova-network as it currently exists in Folsom. There is, of couse, overhead to this approach, but we think it is worth it. With this in mind, a key question becomes: how do we "direct" users to the networking option that is right for them. We have the following guidelines: 1) For users who require only very basic networking (e.g., nova-network Flat, FlatDHCP) there's little difference between Quantum and nova-network is such basic use cases, so using nova's built-in networking for these basic use cases makes sense. 2) There are many use cases (e.g., tenant API for defined topologies and addresses) and advanced network technologies (e.g., tunneling rather than VLANs) that Quantum enables that are simply not possible with nova-network, so if these advanced capabilities are important to someone deploying OpenStack, they clearly need to use Quantum. 3) There are a few things that are possible in nova-network, but not in Quantum. Multi-host is the most significant one, but there are bound to be other gaps, some of which we will uncover only when people try their particular use case with Quantum. For these, users will have to use nova-network, with the gaps being covered in Quantum during Grizzly. As a result, we plan to structure the docs so that you can do a basic functionality Nova setup with flat networking without requiring Quantum. For anything beyond that, we will have an "advanced networking" section, which describes the different advanced use of OpenStack networking with Quantum, and also highlight reasons that a user may still want to use nova-networking over Quantum. Moving beyond Folsom, we expect to fully freeze the addition of new functionality to nova-network, and likely deprecate at least some portions of the existing nova-network functionality. Likely this will leave the basic flat and flat + dhcp nova networking intact, but reduce complexity in the nova codebase by removing more advanced networking scenarios that can also be achieved via Quantum. This means that even those using nova-network in Folsom should still be evaluating Quantum if they networking needs beyond flat networking, such that this feedback can be incorporated into the Grizzly deliverable of Quantum. Thanks, Dan -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
