Re: [Openstack] Future of Launchpad OpenStack mailing list (this list)
Guess the only advantage would be to minimize the chance of someone missing the security related messages in the noise of a heavy traffic mailing list. Even if there were a specialized list, I'd think you'd want to cross post security issues to all lists, depending on severity (and with security, all issues are generally severe). syd From: openstack-bounces+slogan=broadcom@lists.launchpad.net [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of Asher Newcomer Sent: Wednesday, September 12, 2012 5:38 PM To: Kevin Jackson Cc: Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] Future of Launchpad OpenStack mailing list (this list) To chime in as a lurker around here, this sounds good, but why add the security list? It seems like security specific topics would interest those subscribed to the general list as well. On Wed, Sep 12, 2012 at 4:54 PM, Kevin Jackson ke...@linuxservices.co.ukmailto:ke...@linuxservices.co.uk wrote: My two penneth worth: I'd be confused as to what the difference between general and operators would be and would result in people posting to both - so that goes for openstack@... openstack-general@... and openstack-operators@ It would seem that there is a clear distinction between development questions (-dev), announcements (-announce) and then anything else (people asking for help from a variety of skill levels) - so: openstack@... openstack-dev@ openstack-announce@ openstack-security@ Would be my vote (sorry for adding in -security, would that be considered?) Cheers, Kev On 4 September 2012 10:37, Thierry Carrez thie...@openstack.orgmailto:thie...@openstack.org wrote: Stefano Maffulli wrote: Now, the main question is still open: where should the General mailing list go? Anybody disagrees that we should merge this list into 'Operators'? I think there are two options: Option A1: openstack-gene...@lists.openstack.orgmailto:openstack-gene...@lists.openstack.org openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org openstack-annou...@lists.openstack.orgmailto:openstack-annou...@lists.openstack.org openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org ... openstack-general makes it clear this is about general questions and things that address the whole community. This would be a straight replacement of the current openstack@launchpad mailing-list. Option A2: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org openstack-annou...@lists.openstack.orgmailto:openstack-annou...@lists.openstack.org openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org ... Same, using openstack instead of openstack-general. Makes it clear it's the default list. Option B: openstack-u...@lists.openstack.orgmailto:openstack-u...@lists.openstack.org openstack-annou...@lists.openstack.orgmailto:openstack-annou...@lists.openstack.org openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org ... User would be a merge of the current list with the operators list. The benefit is that it matches a recognized pattern in open source project lists (-user, -dev, -announce). The drawback is that there is no default list for newcomers or general discussion, and operators-specific topics will get lost on the -user list, the same way the dev topics used to be. Personally, I prefer option A. On one side you have a general list where almost everyone lurks, on the other you have several topic- or team-oriented lists with sharper focus. One issue is that it's difficult to spot important things on the (noisy) general list, but we also have a (moderated) -announce list that we can more actively use for things we want to make sure everyone sees. Any other option ? Which one do you prefer ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Kevin Jackson @itarchitectkev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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
Re: [Openstack] Quantum features in the folsom release
In addition to looking at blueprints in launchpad, you might want to (start by) view(ing) the following slide decks produced by some of the principal engineers behind quantum. They were helpful to me in getting my arms around the motivations behind quantum and openstack in general. As they say, a picture is worth a thousand words. In no particular order: http://www.slideshare.net/salv_orlando/quantum-virtual-networks-for-openstack http://www.slideshare.net/danwent/quantum-openstack-meetup-feb-9th-2012 http://www.slideshare.net/sumit_naik/openstack-quantum syd -Original Message- From: openstack-bounces+slogan=broadcom@lists.launchpad.net [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of Bilel Msekni Sent: Monday, September 10, 2012 11:07 AM To: openstack@lists.launchpad.net Subject: [Openstack] Quantum features in the folsom release Hi Stackers, Can someone here help me out by detailing the new Quantum features that will be available in the Folsom release. Even a link or anything could help ! i can't seem to find any proper documentation and i have to persuade my boss about the potentials of Quantum :) Thanks ___ 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
Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum? Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach? Thanks, syd -Original Message- From: openstack-bounces+slogan=broadcom@lists.launchpad.net [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Friday, September 07, 2012 9:57 AM To: OpenStack Development Mailing List Cc: openstack-operat...@lists.openstack.org; andi abes; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu mathieu.ro...@gmail.com wrote: great work thanks; As you said the main missing feature of quantum is the multi-host L3-agent. So I wonder if we can combine nova-network and quantum in a way that nova-network is only used for L3 features? I agree that it would be great if there was a simple work around like that, but I think the core of the problem is the multi_host logic in nova-network is closely tied to the IP Address Management (IPAM) logic in nova. Quantum has its own IPAM logic, as it supports more advanced scenarios like overlapping IP addresses on different networks. As a result, I think trying to get the nova-network multi_host logic working with Quantum would be on the same order of difficultly has getting a multi_host equivalent working in Quantum. I don't think its fundamentally hard, we just need to be spending our current Quantum cycles on testing, bug fixing, and documentation and so had to drop this feature for the Folsom release. Dan On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt d...@nicira.com wrote: On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu mathieu.ro...@gmail.com wrote: There is still the security filtering issue (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering) which prevent some cloud operator from using OVS. Do you have a workaround to use security group with OVS in folsom? Yes, it merged into Nova yesterday. https://bugs.launchpad.net/quantum/+bug/1039400 We're still working on the new Quantum docs for Folsom, but if you're already familiar with using Quantum + Nova, the key difference is that you use should a libvirt vif-plugging config of LibvirtHybridOVSBridgeDriver, rather than just LibvirtOpenVswitchDriver . Dan On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt d...@nicira.com wrote: On Wed, Sep 5, 2012 at 5:23 AM, andi abes andi.a...@gmail.com wrote: late to the party... but I'll dabble. On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright chr...@sous-sol.org wrote: * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote: 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. To what end? OVS provides much more robust monitoring and operational facilities (e.g sFlow monitoring, better switch table visibility etc). You won't find any disagreement from me about OVS having more advanced capabilities :) It also provides a linux-bridge compatibility layer (ovs-brcompatd [1]), which should work out-of-box with the linux-bridge. As such, switching to using OVS rather than the linux bridge could be done without any code changes to nova, just deployment changes (e.g. ensure that ovs-brcompatd is running to intercept brctl ioctl's - [2]). Using ovs-brcompatd would be possible, though some distros do not package and run it by default and in general it is not the preferred way to run things according to email on the OVS mailing list. For the more adventurous, there could be any number of interesting scenarios enabled by having access to ovs capabilities (e.g. tunneling) Tunneling is definitely a huge benefit of OVS, but you still need someone to setup the tunnels and direct packets into them correctly. That's is exactly what the Quantum OVS plugin does and it is completely open source and freely available, so if people want to experiment with OVS tunneling, using Quantum would seem like the obvious way to do this. Dan -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list openstack-...@lists.openstack.org
Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
I've observed and studied the OVS L3oL3 tunneling in a multi-node configuration with F3 by packet sniffing VM to VM pings, and have a basic understanding about how the mesh of tunnels comes into existence. Pretty cool. Guessing https://github.com/openstack/quantum/commit/3005d16fe3588bdf4b928e79f640b991df9fae3b is the merge you are referring to that implements the blueprint. There was also a link to a quantum fork created by CISCO that was mentioned in the blueprint, not sure how the code relates (I'm reading both right now). How this ties in with VXLAN and NVGRE (which I guessed from the blueprint both would be plugin instances) is still a bit of a mystery to me, so I look forward to whatever documentation appears. Thanks, syd -Original Message- From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Friday, September 07, 2012 11:11 AM To: Syd (Sydney) Logan Cc: OpenStack Development Mailing List; openstack-operat...@lists.openstack.org; andi abes; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom Hi Syd, On Fri, Sep 7, 2012 at 10:34 AM, Syd (Sydney) Logan slo...@broadcom.com wrote: I'm I correct in believing that the Quantum L3 Abstractions and API Framework (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api) is the current plan of record for bringing L2toL3 functionality (e.g., VXLAN/NVGRE) into Quantum? Several Quantum plugins already have L3-over-L3 overlay tunneling capability to provide private L2 tenant networks without VLANs. These plugins include the Open vSwitch plugin (completely free/open source) and the Nicira NVP plugin (commercial). I suspect others will add this capability as well in the future, and in general its a great example of the new network technologies that Quantum enables. The blueprint above is actually complete and merged, but is actually about letting tenants define routers that connect multiple L2 Quantum networks (e.g., to make multi-tier web applications). These routers can also provide access to external networks and implement floating IPs. We're still wrapping up the Folsom Quantum docs, but hopefully this capability will be more clear soon. Thanks, Dan Is anyone signed up to do this or has this blueprint been deprecated in favor of some other approach? Thanks, syd -Original Message- From: openstack-bounces+slogan=broadcom@lists.launchpad.net [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Friday, September 07, 2012 9:57 AM To: OpenStack Development Mailing List Cc: openstack-operat...@lists.openstack.org; andi abes; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom On Fri, Sep 7, 2012 at 8:36 AM, rohon mathieu mathieu.ro...@gmail.com wrote: great work thanks; As you said the main missing feature of quantum is the multi-host L3-agent. So I wonder if we can combine nova-network and quantum in a way that nova-network is only used for L3 features? I agree that it would be great if there was a simple work around like that, but I think the core of the problem is the multi_host logic in nova-network is closely tied to the IP Address Management (IPAM) logic in nova. Quantum has its own IPAM logic, as it supports more advanced scenarios like overlapping IP addresses on different networks. As a result, I think trying to get the nova-network multi_host logic working with Quantum would be on the same order of difficultly has getting a multi_host equivalent working in Quantum. I don't think its fundamentally hard, we just need to be spending our current Quantum cycles on testing, bug fixing, and documentation and so had to drop this feature for the Folsom release. Dan On Thu, Sep 6, 2012 at 6:29 PM, Dan Wendlandt d...@nicira.com wrote: On Thu, Sep 6, 2012 at 12:50 AM, rohon mathieu mathieu.ro...@gmail.com wrote: There is still the security filtering issue (https://blueprints.launchpad.net/quantum/+spec/ovs-security-filtering) which prevent some cloud operator from using OVS. Do you have a workaround to use security group with OVS in folsom? Yes, it merged into Nova yesterday. https://bugs.launchpad.net/quantum/+bug/1039400 We're still working on the new Quantum docs for Folsom, but if you're already familiar with using Quantum + Nova, the key difference is that you use should a libvirt vif-plugging config of LibvirtHybridOVSBridgeDriver, rather than just LibvirtOpenVswitchDriver . Dan On Wed, Sep 5, 2012 at 7:01 PM, Dan Wendlandt d...@nicira.com wrote: On Wed, Sep 5, 2012 at 5:23 AM, andi abes andi.a...@gmail.com wrote: late to the party... but I'll dabble. On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright chr...@sous-sol.org wrote: * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote: We've been discussing using Open vSwitch as the basis for non
Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom
Backporting *would* duplicate work, by definition. This is nothing new in the industry, the need to innovate and move forward is always at odds with the need to support legacy deployments. Seems to me quantum is a bit of an inflection point in the life of this rather young platform, and should be considered a forcing function for those who were earlier adopters to move forward. Here's why: One of the strongest points of quantum (in the scope of this discussion) is that it is a decoupling from nova, which should make issues like upgradability easier (assuming good API management) because it introduces an abstraction layer + implementation encapsulation. I would argue that while it might be painful to upgrade now, doing so just to get the encapsulation that quantum provides now is reason enough to want to push forward, especially since the gulf between the two will only widen going forward. This topic of upgrading is an interesting one (perhaps one already discussed, I'm still a noob). Devstack, as useful as it is, hasn't reached its potential -- imagine it being shipped with a set of schemas (localrcs) for various deployments styles, e.g., multi-node vs single node, VXLAN vs NVGRE, X vs Y vs Z, or maybe providing a tool something like make menuconfig, or (eventually) the ability to size up a prior deployment and seamlessly upgrade it to a version with not much, if any, user interaction, as one might experience in the majority of cases when upgrading Ubuntu LTS releases. Worlds like this are going to be more easily implemented on top of a platform that has good API management, modularity, and encapsulation of its core components, and standardizations for how the metadata of a deployment is specified and recorded (/etc/nova/nova.conf, etc. probably already fill that role). Quantum seems to me to be a necessary (IMHO) step in that direction. Just my two cents. syd -Original Message- From: openstack-bounces+slogan=broadcom@lists.launchpad.net [mailto:openstack-bounces+slogan=broadcom@lists.launchpad.net] On Behalf Of Kyle Mestery (kmestery) Sent: Wednesday, September 05, 2012 1:15 PM To: OpenStack Development Mailing List Cc: openstack-operat...@lists.openstack.org; andi abes; openstack@lists.launchpad.net Subject: Re: [Openstack] [openstack-dev] Quantum vs. Nova-network in Folsom On Sep 5, 2012, at 2:25 PM, Chris Wright wrote: * Dan Wendlandt (d...@nicira.com) wrote: On Wed, Sep 5, 2012 at 5:23 AM, andi abes andi.a...@gmail.com wrote: late to the party... but I'll dabble. On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright chr...@sous-sol.org wrote: * rob_hirschf...@dell.com (rob_hirschf...@dell.com) wrote: 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. To what end? OVS provides much more robust monitoring and operational facilities (e.g sFlow monitoring, better switch table visibility etc). You won't find any disagreement from me about OVS having more advanced capabilities :) It also provides a linux-bridge compatibility layer (ovs-brcompatd [1]), which should work out-of-box with the linux-bridge. As such, switching to using OVS rather than the linux bridge could be done without any code changes to nova, just deployment changes (e.g. ensure that ovs-brcompatd is running to intercept brctl ioctl's - [2]). Using ovs-brcompatd would be possible, though some distros do not package and run it by default and in general it is not the preferred way to run things according to email on the OVS mailing list. Indeed. While it's doable, it's not something that will hit upstream Linux, and therefore will not be supported by some distros. But, in general...while adding OVS support to nova networking (in the simplest layer 2 switch mode), may not be much work. It's adding a (not particularly useful) feature to a code base that we hope to deprecate. And making it more useful (adding things like tunnelling) support are really the point of Quantum. I think that's what this really boils down to: The entire point of Quantum was to add feature-rich networking as it's own service to OpenStack. Hedging by adding piecemeal features to nova-net at this point may seem ok, but it's a slippery slope, and may end up duplicating work which has already happened in Quantum. Thanks, Kyle thanks, -chris ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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] Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-(
Hi Aaron, Thanks as usual for the reply. I mostly root caused the horizon error last night and filed a bug that ultimately was resolved as duplicate to the following: https://bugs.launchpad.net/horizon/+bug/1040956, which I am sure the horizon people are all over now. Until that bug is fix, horizon is pretty much useless with Quantum since you can't spin up instances. Suspect the fix is easy enough - detect that user is dealing with a quantum based deployment somehow and don't try querying nova about floating ips when computing quotas. I think while I wait for the fix to come in, I'm going to learn more about command line. Horizon has been a huge help (as has been devstack) to get me playing with, and learning about, quantum and OVS (it's quantum and OVS I am particularly interested in, not installing openstack or spinning up VMs), so eager to see the bug get fixed asap. I'm definitely using the latest code, and was aware v1 was yanked from the codebase (I figured my setting v2 in localrc was a no-op). Didn't know the quantum/keystone stuff got worked out. Two questions for you: Is the gw- interface missing on the controller node a symptom of a problem? Or is it not yet supported with F3 Quantum/OVS plugin? I see tap interfaces being built, just not seeing the gw- interface. Is it correct that I don't need q-dhcp and n-net any longer? Thanks! syd From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Tuesday, August 28, 2012 10:17 PM To: Syd (Sydney) Logan Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-( Hi Syd, Unfortunately, I don't believe there are any tools to upgrade the ovs_quantum db to it's current format. That said, I don't believe it would be that hard to write one to migrate your setup. If you read though this page http://wiki.openstack.org/RunningQuantumV2Api it gives an example of creating a network and boot vms on it. I'm not familiar with horizon (maybe someone else who is can help you out). One last thing. Are you running the latest devstack code? The v1 api code has been removed from quantum so you can remove the following line from rclocal NOVA_USE_QUANTUM_API=v2 I'd also suggest also removing this line since devstack can now configure quantum to use keystone by default. Q_AUTH_STRATEGY=noauth Best, Aaron On Wed, Aug 29, 2012 at 12:53 AM, Syd (Sydney) Logan slo...@broadcom.commailto:slo...@broadcom.com wrote: I played around with horizon a bit more and discovered that the demo project page does have a Create Instance button, but when I try and do so I get an error message saying that horizon is unable to get quota information. I tracked down a bug that was filed 5 days ago on someone seeing the same message, and it was punted over to nova after the horizon guys concluded that it was a nova bug. I'm going to see if I can work around this problem in horizon (or rootcause it) tomorrow only because I have no other obvious course of action at the moment. Here is my localrc, the same as what was working well before I grabbed latest devstack (and it grabbed the latest git versions of the openstack apps): HOST_IP=192.168.4.1 FLAT_INTERFACE=eth1 FIXED_RANGE=10.4.128.0/20http://10.4.128.0/20 FIXED_NETWORK_SIZE=4096 FLOATING_RANGE=192.168.4.128/25http://192.168.4.128/25 MULTI_HOST=True Q_INTERFACE=eth1 LOGFILE=/opt/stack/logs/stack.sh.log ADMIN_PASSWORD=password MYSQL_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=xyzpdqlazydog LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,mysql,rabbit,openstackx,q-svc,quantum,q-agt Q_PLUGIN=openvswitch Q_AUTH_STRATEGY=noauth NOVA_USE_QUANTUM_API=v2 syd From: Syd (Sydney) Logan Sent: Tuesday, August 28, 2012 2:19 PM To: 'openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net' Subject: Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-( Hi, Is there a recommended procedure for upgrading nodes that were configured pre-Folsom 3 to use quantum V1/OVS that were deployed with devstack? I probably should have asked this question before trying, but I went ahead and tried. I had a multi-node setup that I was driving with Horizon that was working very well. Now I'm just trying to get a single node setup working, and not getting far. To get sync'd up with the latest, I did the following: $ rm -rf /opt/stack (this is where devstack pulled things to) $ rm -rf /etc/quantum; rm -rf /etc/nova In the devstack localrc: Removed n-net from ENABLED_SERVICES Added q-dhcp to ENABLED_SERVICES (I had this disabled in pre-F3 after e-mails with Aaron Rosen when he helped me get going earlier, I've tried both ways and seems not to make a difference) Added NOVA_USE_QUANTUM=v2 (but this doesn't seem to make a difference either) And I ran
[Openstack] Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-(
Hi, Is there a recommended procedure for upgrading nodes that were configured pre-Folsom 3 to use quantum V1/OVS that were deployed with devstack? I probably should have asked this question before trying, but I went ahead and tried. I had a multi-node setup that I was driving with Horizon that was working very well. Now I'm just trying to get a single node setup working, and not getting far. To get sync'd up with the latest, I did the following: $ rm -rf /opt/stack (this is where devstack pulled things to) $ rm -rf /etc/quantum; rm -rf /etc/nova In the devstack localrc: Removed n-net from ENABLED_SERVICES Added q-dhcp to ENABLED_SERVICES (I had this disabled in pre-F3 after e-mails with Aaron Rosen when he helped me get going earlier, I've tried both ways and seems not to make a difference) Added NOVA_USE_QUANTUM=v2 (but this doesn't seem to make a difference either) And I ran devstack. I got no errors when I ran devstack. When I launched Horizon, some problems are evident. There is no launch instance button on the Instances page. Because I don't yet know the command UI enough to spin up and configure VMs, I figured I'd try running the devstack exercise.sh script to see what happens. It creates a few VMs, but none get an IP address (before I used to get IPs in 10.4.128.0). It reports all tests passed, as well. If I click through in the UI on the VM, I see that for networking address it assigns all VMs is the value Net1. I've looked at console logs for the VMs created and see failures trying to dhcp (that's why I naively added q-dhcp back to ENABLED_SERVICES), but as I mentioned above, adding q-dhcp didn't help, and I'm wondering if it was a good idea anyway since Aaron steered me away from it before. Output of ps shows expected services running (e.g., OVS daemon, plugins, agents) and services lists displayed by Horizon (e.g., nova, quantum, etc.) all seem normal to me. Notably missing is the OVS gw- interface that was present before I upgraded (at http://wiki.openstack.org/RunningWQuantumV2Api there is this: Note: with v2, Quantum no longer uses the L3 + NAT logic from nova-network. Quantum will not have the equivalent functionality until F-3, so you won't be able to ping the VMs from the nova controller host. Is that the reason?) The gw interface is the way I could ping VMs from the host. The missing gateway, horizon UI missing the create instance button, and not getting networks for VMs spun up by devstack's exercise script are the major symptoms. I trust that devstack is up to sync with what is happening in Folsom, and that I am actually pulling down F3 code at this point (I've not tried to verify this). I'm not aware of any need to tweek the devstack exercise script, I am assuming it is designed to work as is. I'm thinking of wiping my entire disk and starting from scratch in case blowing away /etc/nova etc. and /opt/stack were not enough to reset state, but before I do this, any pointers to links or mail messages (I've scanned for relevant posts but missed finding any) that would be helpful before I do this? Thanks, syd ___ 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] Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-(
I played around with horizon a bit more and discovered that the demo project page does have a Create Instance button, but when I try and do so I get an error message saying that horizon is unable to get quota information. I tracked down a bug that was filed 5 days ago on someone seeing the same message, and it was punted over to nova after the horizon guys concluded that it was a nova bug. I'm going to see if I can work around this problem in horizon (or rootcause it) tomorrow only because I have no other obvious course of action at the moment. Here is my localrc, the same as what was working well before I grabbed latest devstack (and it grabbed the latest git versions of the openstack apps): HOST_IP=192.168.4.1 FLAT_INTERFACE=eth1 FIXED_RANGE=10.4.128.0/20 FIXED_NETWORK_SIZE=4096 FLOATING_RANGE=192.168.4.128/25 MULTI_HOST=True Q_INTERFACE=eth1 LOGFILE=/opt/stack/logs/stack.sh.log ADMIN_PASSWORD=password MYSQL_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=xyzpdqlazydog LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,mysql,rabbit,openstackx,q-svc,quantum,q-agt Q_PLUGIN=openvswitch Q_AUTH_STRATEGY=noauth NOVA_USE_QUANTUM_API=v2 syd From: Syd (Sydney) Logan Sent: Tuesday, August 28, 2012 2:19 PM To: 'openstack@lists.launchpad.net' Subject: Upgrading from devstack pre-F3/quantum v1/OVS to latest not going well :-( Hi, Is there a recommended procedure for upgrading nodes that were configured pre-Folsom 3 to use quantum V1/OVS that were deployed with devstack? I probably should have asked this question before trying, but I went ahead and tried. I had a multi-node setup that I was driving with Horizon that was working very well. Now I'm just trying to get a single node setup working, and not getting far. To get sync'd up with the latest, I did the following: $ rm -rf /opt/stack (this is where devstack pulled things to) $ rm -rf /etc/quantum; rm -rf /etc/nova In the devstack localrc: Removed n-net from ENABLED_SERVICES Added q-dhcp to ENABLED_SERVICES (I had this disabled in pre-F3 after e-mails with Aaron Rosen when he helped me get going earlier, I've tried both ways and seems not to make a difference) Added NOVA_USE_QUANTUM=v2 (but this doesn't seem to make a difference either) And I ran devstack. I got no errors when I ran devstack. When I launched Horizon, some problems are evident. There is no launch instance button on the Instances page. Because I don't yet know the command UI enough to spin up and configure VMs, I figured I'd try running the devstack exercise.sh script to see what happens. It creates a few VMs, but none get an IP address (before I used to get IPs in 10.4.128.0). It reports all tests passed, as well. If I click through in the UI on the VM, I see that for networking address it assigns all VMs is the value Net1. I've looked at console logs for the VMs created and see failures trying to dhcp (that's why I naively added q-dhcp back to ENABLED_SERVICES), but as I mentioned above, adding q-dhcp didn't help, and I'm wondering if it was a good idea anyway since Aaron steered me away from it before. Output of ps shows expected services running (e.g., OVS daemon, plugins, agents) and services lists displayed by Horizon (e.g., nova, quantum, etc.) all seem normal to me. Notably missing is the OVS gw- interface that was present before I upgraded (at http://wiki.openstack.org/RunningWQuantumV2Api there is this: Note: with v2, Quantum no longer uses the L3 + NAT logic from nova-network. Quantum will not have the equivalent functionality until F-3, so you won't be able to ping the VMs from the nova controller host. Is that the reason?) The gw interface is the way I could ping VMs from the host. The missing gateway, horizon UI missing the create instance button, and not getting networks for VMs spun up by devstack's exercise script are the major symptoms. I trust that devstack is up to sync with what is happening in Folsom, and that I am actually pulling down F3 code at this point (I've not tried to verify this). I'm not aware of any need to tweek the devstack exercise script, I am assuming it is designed to work as is. I'm thinking of wiping my entire disk and starting from scratch in case blowing away /etc/nova etc. and /opt/stack were not enough to reset state, but before I do this, any pointers to links or mail messages (I've scanned for relevant posts but missed finding any) that would be helpful before I do this? Thanks, syd ___ 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] Configuring with devstack for multiple hardware nodes
Hi, I just posted the following at http://forums.openstack.org/viewtopic.php?f=15t=1435, then realized this mailing list might be a better place to ask the question. In summary, I've cobbled together devstack-based nodes to exercise quantum/openvswitch (when I say cobbled, I mean my result is the combination of information from wiki and from devstack, and elsewhere to create my localrc files, since there is no one definitive template that I could use, and it seems that devstack examples are not current with what is happening on Folsom). One node is a controller, one is a compute node. I can launch using horizon on the controller, VMs launched on the controller are pingable, but ones launched on the compute node are not. The big difference I can see is a missing gateway interface on the controller (on gw-* displayed when I run ifconfig). By inspection of the logs, I can see that the VMs are unable to establish a network, and I think the missing gateway interface may be the root cause for that. Below are details: Two hosts, one configured as a controller, the other configured as a compute node. Each host is dual homed, network for eth0 is connected to the local intranet, network for eth1 is configured as a local net 192.168.3.0 On the controller host, I used devstack with the following localrc (which is an aggregation of stuff I found on the devstack site, and stuff I found recently on the quantum wiki -- it would be nice if complete templates for a controller and compute node supporting devstack and openvswitch were published on the devstack site or the wiki, perhaps since we are not yet at Folsom it makes sense they don't exist, if I get something working, I will share my configuration in the entirety at whatever is the most appropriate place). Anyway, controller host localrc is: HOST_IP=192.168.3.1 FLAT_INTERFACE=eth1 FIXED_RANGE=10.4.128.0/20 FIXED_NETWORK_SIZE=4096 FLOATING_RANGE=192.168.3.128/25 MULTI_HOST=True LOGFILE=/opt/stack/logs/stack.sh.log ADMIN_PASSWORD=password MYSQL_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=xyzpdqlazydog ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-net,n-sch,n-vnc,horizon,mysql,rabbit,openstackx,q-svc,quantum,q-agt,q-dhcp Q_PLUGIN=openvswitch Q_AUTH_STRATEGY=noauth If I run stack on this host, I get the following nova.conf: [DEFAULT] verbose=True auth_strategy=keystone allow_resize_to_same_host=True root_helper=sudo /usr/local/bin/nova-rootwrap /etc/nova/rootwrap.conf compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler dhcpbridge_flagfile=/etc/nova/nova.conf fixed_range=10.4.128.0/20 s3_host=192.168.3.1 s3_port= network_manager=nova.network.quantum.manager.QuantumManager quantum_connection_host=localhost quantum_connection_port=9696 quantum_use_dhcp=True libvirt_vif_type=ethernet libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtOpenVswitchDriver linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions my_ip=192.168.3.1 public_interface=br100 vlan_interface=eth0 flat_network_bridge=br100 flat_interface=eth1 sql_connection=mysql://root:password@localhost/nova?charset=utf8 libvirt_type=kvm libvirt_cpu_mode=none instance_name_template=instance-%08x novncproxy_base_url=http://192.168.3.1:6080/vnc_auto.html xvpvncproxy_base_url=http://192.168.3.1:6081/console vncserver_listen=127.0.0.1 vncserver_proxyclient_address=127.0.0.1 api_paste_config=/etc/nova/api-paste.ini image_service=nova.image.glance.GlanceImageService ec2_dmz_host=192.168.3.1 rabbit_host=localhost rabbit_password=password glance_api_servers=192.168.3.1:9292 force_dhcp_release=True multi_host=True send_arp_for_ha=True logging_context_format_string=%(asctime)s %(color)s%(levelname)s %(name)s [^[[01;36m%(request_id)s ^[[00;36m%(user_name)s %(project_name)s%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m logging_default_format_string=%(asctime)s %(color)s%(levelname)s %(name)s [^[[00;36m-%(color)s] ^[[01;35m%(instance)s%(color)s%(message)s^[[00m logging_debug_format_suffix=^[[00;33mfrom (pid=%(process)d) %(funcName)s %(pathname)s:%(lineno)d^[[00m logging_exception_prefix=%(color)s%(asctime)s TRACE %(name)s ^[[01;35m%(instance)s^[[00m compute_driver=libvirt.LibvirtDriver firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver enabled_apis=ec2,osapi_compute,osapi_volume,metadata If I run horizon, I can launch vms and ping them. If I look at the logs generated by the VMs, they are able to get a network. Furthermore, I get the following network interface in addition to the tap interfaces generated for each VM: gw-4f16e8db-20 Link encap:Ethernet HWaddr fa:16:3e:08:e0:2d inet addr:10.4.128.1 Bcast:10.4.143.255 Mask:255.255.240.0 inet6 addr: fe80::f816:3eff:fe08:e02d/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0
