Re: [Openstack] [Keystore] "pip install -r requirements.txt" can't work under python 2.7
Caused by using an old version of pip. The minimum we support at the
moment is 7.1
-Rob
On 5 March 2016 at 22:19, yewgang wrote:
> Hi,
>
> Is this caused by syntax error of requirements.txt in Keystore or some else?
> Thank you for help.
>
> # pip install -r requirements.txt
> Exception:
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 126, in
> main
> self.run(options, args)
> File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 200,
> in run
> for req in parse_requirements(filename, finder=finder, options=options):
> File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1257, in
> parse_requirements
> req = InstallRequirement.from_line(line, comes_from)
> File "/usr/lib/python2.7/dist-packages/pip/req.py", line 98, in from_line
> return cls(req, comes_from, url=url)
> File "/usr/lib/python2.7/dist-packages/pip/req.py", line 38, in __init__
> req = pkg_resources.Requirement.parse(req)
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2582, in
> parse
> reqs = list(parse_requirements(s))
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2507, in
> parse_requirements
> line, p, specs = scan_list(VERSION,LINE_END,line,p,(1,2),"version spec")
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2485, in
> scan_list
> "Expected ',' or end-of-list in",line,"at",line[p:]
> ValueError: ("Expected ',' or end-of-list in",
> "Routes!=2.0,!=2.1,>=1.12.3;python_version=='2.7' # MIT", 'at',
> ";python_version=='2.7' # MIT")
>
> Storing complete log in /root/.pip/pip.log
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Trying compiling the OpenStack Swift
On 31 March 2015 at 04:05, Christian Schwede wrote: > Hello, > > actually there is a small gap in the docs you stumbled upon :( > The Swift developers are currently working on integrating Erasure > Coding, and thus a new dependency was added. The dependency itself > requires a library that is not available on your system. Actually no - the dependency vendors the C library in. (The tastefulness of that is a separate discussion :)). The actual issue is likely one of: - the C tooling needed to build the 3 dependent C libraries is not present. It needs make, and a C compiler. - PyECLib was uninstalled after installing its vendored versions, which breaks subsequent installs: https://bitbucket.org/kmgreen2/pyeclib/issue/62/pip-install-uninstall-install-errors-with I found that removing the .so and .h's from the installed vendored library was enough to allow the setup.py glue to succeed on a subsequent install. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Feature wish list somewhere? 2 Devs looking to contribute
On 23 January 2015 at 16:56, Michael Gale wrote: > Hey, > > Does anyone know where I could find a feature wishlist? Ideally a list > of outstanding features or functionality that is wanted. But is currently > missing from OpenStack and not being worked on or has been started but needs > a lot of dev help? > > I am looking for a way that 2 full time python devs could contribute to the > project. The most significant way IMO would be to work on stability and robustness bugs across the projects: much of OpenStack has a huge set of folk working on features that their orgs need, and stability and robustness, which are the underpinnings of anything really advanced don't get as much of a lookin as I think we need :) Starting as Joe says on bugs would be a good way to find such issues. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [diskimage-builder] How can I build my own undercloud or overcloud image ?
Hi, they are built by the scripts in https://git.openstack.org/openstack/tripleo-incubator. HTH -Rob On 30 July 2014 14:06, 严超 wrote: > Hi, All: > > I want to build my own undercloud. But I don't even know how the following > images are built. > > Is there any good examples for diskimage-builder or good docs? > > > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/undercloud.qcow2 > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/deploy-ramdisk.initramfs > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/deploy-ramdisk.kernel > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/overcloud-compute.qcow2 > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/overcloud-control.qcow2 > curl -L -O > http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/user.qcow2 > > Best Regards！ > Chao Yan > -- > My twitter：Andy Yan @yanchao727 > My Weibo：http://weibo.com/herewearenow > -- > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Single NIC deployment
On 18 July 2014 03:29, Gastón Keller wrote: > Hello, community. > > I'm working on a 3-node deployment (i.e., controller, network and > compute) of OpenStack Icehouse in CentOS 6.4, following the official > installation guide for CentOS found in openstack.org. > > These machines with which I'm working have only one NIC available. > Since the guide indicates that the different nodes require one to > three NICs, I've created aliases for the one NIC as follows (e.g., > network node): > > ** Network node ** > > [root@ecco-vmhost-id19 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 > DEVICE=eth0 > ONBOOT=yes > NM_CONTROLLED=no > BOOTPROTO=dhcp > DELAY=0 > > [root@ecco-vmhost-id19 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0.1 > DEVICE=eth0.1 > ONBOOT=yes > NM_CONTROLLED=no > BOOTPROTO=none > VLAN=yes > IPADDR=10.18.23.21 > NETMASK=255.255.255.0 > > [root@ecco-vmhost-id19 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0.2 > DEVICE=eth0.2 > TYPE=Ethernet > ONBOOT=yes > NM_CONTROLLED=no > BOOTPROTO=none > VLAN=yes > > > Is there any reason why this setup wouldn't work? Yes, once the br-ex integration bridge is configured, regular IPs will stop working on that interface - the actual interface, not the alias, AIUI. So, this explains your symptom: > I have installed and configured every service in their respective > node, have created networks and subnets, a virtual router, and > connected all the required ports. However, when I try to verify > connectivity with a ping to the virtual router's external IP address, > things fail. > > [root@ecco-vmhost-id19 ~]# ping -c 4 199.241.160.101 > PING 199.241.160.101 (199.241.160.101) 56(84) bytes of data. > From 199.241.160.40 icmp_seq=2 Destination Host Unreachable > From 199.241.160.40 icmp_seq=3 Destination Host Unreachable > From 199.241.160.40 icmp_seq=4 Destination Host Unreachable > > --- 199.241.160.101 ping statistics --- > 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 12999ms > pipe 3 > > > Any help would be deeply appreciated. As Joe says, just use regular eth0, put br-ex on that, and put an IP address on br-ex (or on an access port on it). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] nova ip 169.254.169.254
The VMs typically shouldn't have a 169 route; also you can't ping the metadata server since its usually DNAT on the port (80) rather than a fully accessible IP address. -Rob On 13 May 2014 02:01, Howard Luckenbaugh wrote: > This is part of IBM Smart Cloud Orchestrator which is running openstack as > the backend. I compared my IPtables to a working environment and it looks > fine. I have rebooted and restarted. The VM's are getting a 169 route but > can't ping. > The only place I can ping is on the Region server which is where the 169 > address sits. > > > >Howard Luckenbaugh >Special Events Infrastructure/IBM.com Infrastructure >T/L-349-5884 >Fax- 1877-210-0298 >hluc...@us.ibm.com >AIX System Certified > >Please visit the sites that our team hosts: http://www.ibm.com >http://www.wimbledon.com http://www.usopen.org http://www.masters.com >http://www.austrailianopen.com http://www.usopen.com > >"Vision without Action is just a dream >Actions without Vision is just passing time >Vision with Action can change the world" > > > [image: Inactive hide details for "Gangur, Hrushikesh (R & D HP Cloud)" > ---05/11/2014 11:29:04 PM---Few troubleshooting steps (assuming]"Gangur, > Hrushikesh (R & D HP Cloud)" ---05/11/2014 11:29:04 PM---Few > troubleshooting steps (assuming neutron's metadata agent): 1. Check through > VM's console.log whe > > From: "Gangur, Hrushikesh (R & D HP Cloud)" > To: Robert Collins , Howard > Luckenbaugh/Raleigh/IBM@IBMUS > Cc: "openstack@lists.openstack.org" > Date: 05/11/2014 11:29 PM > Subject: RE: [Openstack] nova ip 169.254.169.254 > -- > > > > Few troubleshooting steps (assuming neutron's metadata agent): > 1. Check through VM's console.log whether VMs are acquiring DHCP Ip address > 2. If not, check all the bridges (on both controller and compute) up and > running s (br-int or br-tun), generally on reboot some of these bridges do > not come up. > 3. If yes to #1, restart neutron-metadata-agent > > Regards~hrushi > -Original Message- > From: Robert Collins > [mailto:robe...@robertcollins.net] > > Sent: Saturday, May 10, 2014 3:03 PM > To: Howard Luckenbaugh > Cc: openstack@lists.openstack.org > Subject: Re: [Openstack] nova ip 169.254.169.254 > > On 10 May 2014 06:16, Howard Luckenbaugh wrote: > > This box was working and listening on 169.254.169.254 to access the > > metadata of the machines. However it has stopped listening. I have > > tried rebooting and comparing networks and etc and nothing I can see > > is stopping it. Anyone had this happen before. > > If you are using neutron's nova metadata agent, it runs a process per > network, then uses a domain socket to escape the network namespace and > communicate with a parent that talks to nova. > > If you are using nova-networking, its handled by an iptables DNAT rule to > take incoming requests and forward them to the actual API IP address/port. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] nova ip 169.254.169.254
On 10 May 2014 06:16, Howard Luckenbaugh wrote: > This box was working and listening on 169.254.169.254 to access the metadata > of the machines. However it has stopped listening. I have tried rebooting > and comparing networks and etc and nothing I can see is stopping it. Anyone > had this happen before. If you are using neutron's nova metadata agent, it runs a process per network, then uses a domain socket to escape the network namespace and communicate with a parent that talks to nova. If you are using nova-networking, its handled by an iptables DNAT rule to take incoming requests and forward them to the actual API IP address/port. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Auto assign Floating IP with Neutron in Icehouse?
Same as without neutron - set these options: # Default pool for floating IPs (string value) #default_floating_pool=nova # Autoassigning floating IP to VM (boolean value) #auto_assign_floating_ip=false -Rob On 2 May 2014 11:15, Toan Ngo wrote: > Is there an option to configure automatic floating IP assignment with > Neutron? I read one reply in a December dev thread mentioning that it was > going to be a feature available in Neutron icehouse. I have been unable to > find any documentation or information supporting automatic floating IP > assignment. > > Now that I have upgraded to icehouse, I was hoping to get have that feature > available. > > Thanks, > Toan > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Tripleo] [SSL] SSL Examples
On 19 April 2014 11:02, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: > Hello, > > I am attempting to turn SSL and stunnel on with the most current DevTest > TripleO code base and am wondering if anyone has some examples of how to > configure the SSL variables and the TripleO elements. > > - SSLBASE This would be the path to your crt and key files - e.g. ./mykeyname > - PUBLIC_API_URL This is the URL being used for the API endpoint - e.g. ci-overcloud.tripleo.org > - /etc/host mappings This is taken care of by the heat template > - ssl-source.yaml Which is this ;) -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Unable to access guests in DevStack on OpenStack environment
On 27 March 2014 22:49, Juergen Brendel wrote: > > Hello! > > Thank you for your reply. You're welcome :) >> - if dhcp isn't working, try using tcp dump on the compute nodes and >> debug your overlay network (there are many blog posts on this) > > I guess that would be next. > > >> That all said - its very odd that the vm got an ip on the *public* >> network. I would have expected it to get an ip on the private network >> and be exposed on the public one via a floating ip. the public network >> probably has dhcp off (see neutron net-show and neutron subnet-show). >> >> At a guess - you booted the vm as admin, rather than the user account, >> and you got the public network as the network for the VM. Try using >> the demo user account, or make your own user. > > Yes, you are right. I changed it now so that I create the VM as the demo > user. I promptly get an IP address assigned from the private network. > Well, nova and neutron think the address is assigned, but as we saw from > the console-log, the guest never received that address... > > Maybe the above additional information is useful in determining where to > look next? Ok, so the current status is: - booting as demo user - nova and neutron assign you an address from the private network - guest doesn't pick it up via DHCP? - there's no sign of the DHCP request on the overlay network? So - I think we're back to 'debug DHCP on the overlay network'. e.g. something like http://docs.openstack.org/trunk/openstack-ops/content/network_troubleshooting.html You should be able to insert tcpdump probes at every point along the transit path from the hypervisor through to the dhcp agent - I suggest just firing a few up - network node gre endpoint interface, the DHCP netns, the tap port for the VM, the outbound interface of the hypervisor. You should see encapsulated DHCP requests on some of those - and that will tell us where it gets to. Seeing it doesn't mean its right of course - one of the failure modes I've see is bad VLAN tagging in GRE leading to the receiver dropping the packets. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Unable to access guests in DevStack on OpenStack environment
et HWaddr 96:bf:ae:d5:a0:44 > inet addr:172.24.4.225 Bcast:0.0.0.0 Mask:255.255.255.240 > inet6 addr: fe80::94bf:aeff:fed5:a044/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:6 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:468 (468.0 B) TX bytes:468 (468.0 B) > > br-intLink encap:Ethernet HWaddr 62:28:61:90:0b:47 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:6 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:468 (468.0 B) TX bytes:0 (0.0 B) > > br-tunLink encap:Ethernet HWaddr 0e:f3:a7:96:91:43 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > eth0 Link encap:Ethernet HWaddr fa:16:3e:dc:7e:82 > inet addr:10.5.5.2 Bcast:10.5.5.255 Mask:255.255.255.0 > inet6 addr: fe80::f816:3eff:fedc:7e82/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:438220 errors:0 dropped:0 overruns:0 frame:0 > TX packets:180410 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:580740049 (580.7 MB) TX bytes:14956005 (14.9 MB) > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:84427 errors:0 dropped:0 overruns:0 frame:0 > TX packets:84427 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:51372553 (51.3 MB) TX bytes:51372553 (51.3 MB) > > On the compute hosts, they are like this: > > $ ifconfig -a > br-intLink encap:Ethernet HWaddr c2:25:18:4b:8b:49 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > br-tunLink encap:Ethernet HWaddr 1e:27:74:ee:a1:45 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > eth0 Link encap:Ethernet HWaddr fa:16:3e:07:fd:48 > inet addr:10.5.5.5 Bcast:10.5.5.255 Mask:255.255.255.0 > inet6 addr: fe80::f816:3eff:fe07:fd48/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:309885 errors:0 dropped:0 overruns:0 frame:0 > TX packets:134774 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:422666082 (422.6 MB) TX bytes:10489797 (10.4 MB) > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:159 errors:0 dropped:0 overruns:0 frame:0 > TX packets:159 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:10580 (10.5 KB) TX bytes:10580 (10.5 KB) > > virbr0Link encap:Ethernet HWaddr 9a:21:30:f2:8a:3b > inet addr:192.168.122.1 Bcast:192.168.122.255 > Mask:255.255.255.0 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > If anyone has any idea what I could possibly be doing wrong, I would be > very grateful for any explanation. > > Thank you very much... > > Juergen > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] dhcp request can't reach br-int of network node
Check the outbound ofctl rules on your hypervisor nodes. If they aren't tagging traffic properly, it won't be processed by the incoming gre rules and you'll see the symptoms you have. On 8 February 2014 05:41, Chris Baker wrote: > Hi guys, > > My havana installation has 3 nodes: > control node, runs keystone APIs and neutron server; > network node, runs l3, dhcp, metadata, ovs agents; with VLAN mode > compute node, runs nova compute and ovs agents; > > repo from http://repos.fedorapeople.org/repos/openstack/openstack-havana, > and the os gets updated well with latest kernel. > > > Currently my VM can't get dhcp ack from network node. > Based the topology picture for the package flow: > http://docs.openstack.org/admin-guide-cloud/content/figures/10/a/common/figures/under-the-hood-scenario-1-ovs-network.png > > With the tcpdump result on both network and compute node, it says the dhcp > request successfully leaves compute node, and it can reach the "int-br-eth1" > of network node, but not the next step br "br-int", so the dnsmasq would not > able to ack. I think this is the problem why I can't get dhcp ipaddr. > > # uname -r > 2.6.32-358.123.2.openstack.el6.x86_64 > > # ip netns (should we say namespace works well?) > qdhcp-11f3adc1-6a2e-429b-9679-b565347e2f74 > qdhcp-4aaa7c19-7864-4b17-aebc-d6aa354d4cd5 > qdhcp-285e259e-e3ec-4149-81db-8e94e1713aa2 > qdhcp-4044cdf0-717b-4628-9ce0-a9ff49533d8f > qrouter-76c9b884-5928-42f4-a016-afab1b72066b > > Anyone can help where/which section I should check for the issue next? or > let me know if other info is needed. > Thanks a lot. > > Chris > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Is there any article for installing Havana with neutron in 2 nodes with only 2 nics?
Not sure what doc / image you're specifically referring to - you linked to the table of contents, but you can install Neutron with just one NIC. -Rob On 10 February 2014 15:51, jeffty wrote: > Hi there, > > I have 2 PC and each of them has 2 nics. One for internet access and > another for internal network. > > I want to install havana with one controller and one compute. Neutron > can be installed in any of them. > > The document illustrates 3 nics are needed for dedicated network node. > Is there any articles for installing neutron service with only 2 nics? > Any changes need to be performed based on > http://docs.openstack.org/havana/install-guide/install/apt/content/? > > Thanks. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Neutron] asymetric DHCP brokenness on tenant GRE networks
On 30 January 2014 08:16, Jonathan Proulx wrote: > On Wed, Jan 29, 2014 at 1:49 PM, Joe Topjian wrote: >> >>> however I can't tcpdump on the patch or gre devices >>> >>> # tcpdump -i patch-tun >>> tcpdump: patch-tun: No such device exists >> >> >> I can reproduce this. I suspect because patch-tun and patch-int are OVS >> patch interfaces, they are internal to OVS and not a real interface. "ip a | >> grep patch-tun" returns no results, so that supports that theory. >> > > I'm pretty sure it is the case that these are just ovs internal, just > wonder if there's a way to do the equivalent of tcpdump to see what if > anything is crossing them. It's a big gap between the tap and the eth > devices. I'm thinking ovs port mirroring may be what I need to learn, > that's what I'd to on a switch to inspect packets on a port if I > couldn't be on the device connected to it. They are internal. You should be able to plug a port in and configure it to mirror though. So yes, ovs port mirroring. >> How about "brctl show"? There should be a bridge called qbrXXX that bridges >> the tap interface to a qvb interface. The qvb interface is a veth pair to a >> qvo interface on OVS. If you can't see packets between qbr, qvb, or qvo, >> then I'd imagine the problem is somewhere with the linux standard bridging. > > This may be getting close to the issue. I don't see any interfaces > anything like that. I'm seeing two different types of bride states on > my compute nodes, which suggest something's wrong there. On the > compute node hosting the 'bad' instances and many other nodes as well > I see: > > bridge namebridge idSTP enabledinterfaces > br-int.da8ae1f32b4fno > int-eth1-br > tap217f1525-a7 > tap2216c86e-aa > tap95f49c26-c5 > tap9cf1249f-19 > tapa35c07ef-ef > tapdcc2d3c6-d6 > tapdebc0ece-86 > tapf1cf3384-6d > br-tun.f66f85d4f940no > eth1-br.60eb69dc46dfnoeth1 > phy-eth1-br > virbr08000.yes > > But a minority of systems show: > > ovs-system.6e7205af2054nobr-int > br-tun > eth1 > eth1-br > int-eth1-br > phy-eth1-br > tap0a7aca16-ad > tap4ff9d951-c1 > tap4ffca4ce-00 > tap892a01b4-93 > tapf6ddeaf5-f4 > virbr08000.yes Always use ovs-vsctl show on ovs switches - brcompat is super limited. What flows do you have defined? ovs-ofctl show br-int #(to id ports) ovs-ofctl dump-flows br-int Cheers, Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Practicality of an unusual bare-metal use-case
On 23 January 2014 03:53, Dustin J. Mitchell wrote: > I've read a bit about bare-metal support in openstack. It looks like Nova > has decent support for it, with a few bugs, and Ironic's still in > development[1]. > > We at Mozilla have a bit of an unusual use-case, and I'm wondering how > practical it will be to add support for it. I'm sure there will be a decent > amount of coding involved, and if those can be distributed as distinct > plugins or upstreamed to OpenStack, all the better! > > The case is this: we have a bunch of typical commodity servers, a bunch of > Mac Minis, and a bunch of development boards (Pandaboards, in particular). > We have tools in place for doing manual provisioning: IPMI for server power > and IP-addressable power supplies for the Minis and Pandaboards, along with > MDT for Windows, Kickstart for Linux (both PXE), Casper for OS X (Netboot), > and a PXE-based custom solution for development boards[2]. Our DNS, DHCP, > and network configuration is built from our internal inventory app[3], and > wouldn't be handled directly by Nova. We'd like to dynamically provision > OS's onto all of this hardware, with the servers getting either Linux and > Windows, the Minis getting various flavors of OS X, and the development > boards getting various flavors of Android and Firefox OS. Multiple architectures requires either multiple nova-computes with the baremetal driver (each configured for one arch), or Ironic. Windows is not yet a feature for nova-baremetal or Ironic, but we'd love it to be :) Ditto OS X. DNS support in Nova - not sure of the current status but there was a plugin interface at once point where you could query your inventory app. DHCP - you'll need to write a Neutron plugin to override the DHCP allocation policy there.I suspect some refactoring will be needed. Network configuration - model it in Neutron, should be straight forward. > My hope is that we could add plugins that would glue OpenStack to some of the > tools we're already using. Is that practical? Totally impractical? Am I > taking the wrong approach? Will I be able to support all of these various > backends in a single OpenStack instance? Yes, one OpenStack region can handle multiple baremetal flavours, which seems to be the only variation you have between the machines - client OS is always a separate layer in OpenStack :) -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] [Neutron] auto configration of local_ip
On 16 January 2014 21:41, NOTSU Arata wrote: > Hello, > > I'm trying to add a new configuration option for Neutron OVS agent. Although > I've submitted a patch and it is being reviewed [1], I'm posting to this > mailing list seeking opinion from a wider range. > > At present, when you deploy an environment using Neutron + OVS + GRE/VXLAN, > you have to set local_ip for tunnelling in neutron agent config (typically > ovs_neutron_plugin.ini). As each host has different local_ip, preparing and > maintaining the config files is a cumbersome work. It's fully automated in all the deployment systems I've looked at. I appreciate the concern for deployers, but this is a solved problem for us IMO. > Anyway, with this feature, instead of setting an actual IP address to > local_ip, you set some options (criteria) for choosing an IP address suitable > for local_ip among IP addresses assigned to the host. At runtime, OVS agent > will choose an IP address according to the criteria. You will get the same > effect as you set local_ip= by hand. > > The question is, what criteria is appropriate for the purpose. The criteria > being mentioned so far in the review are: > > 1. assigned to the interface attached to default gateway > 2. being in the specified network (CIDR) > 3. assigned to the specified interface >(1 can be considered a special case of 3) I don't think 1 is a special case of 3 - interface based connections are dependent on physical wiring, How about 4. Send a few packets with a nonce in them to any of the already meshed nodes, and those nodes can report what ip they originated from. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] quota setting
On 7 December 2013 06:07, mcheung63 wrote: > we can set quota in titan now, just a small step forward > > http://peter.kingofcoders.com/?p=956 I'm really confused; why don't you use Horizon? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat] Locked Outputs
On 13 November 2013 16:08, Andrew Plunk wrote: > Alright. > > The problem: > > If a program generates a password, and displays it on a screen over and over > again, it is more susceptible to being compromised. > > Possible solutions: > > 1).Provide a way to limit the availability of stack outputs returned from > heat. > 2).Provide a way to express metadata about stack outputs returned from heat. 3) Don't generate the password 4) Don't show the password at all (just supply it to the cluster being configured) [which the hidden output setting already implements] So - why are you generating a password - what is the password for / where it is being used ? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Is there any way to extend the ip address of subnet?
I've reopened https://bugs.launchpad.net/neutron/+bug/572 as you say it should be supported :) On 7 November 2013 22:28, Aaron Rosen wrote: > Hi Sam, > > Unfortunately we do not support updating the allocation-pools on subnets at > this time. This is something that we should definitely fix though in > neutron. > > Aaron > > > On Wed, Nov 6, 2013 at 10:46 PM, Sam Lee wrote: >> >> Hi All, >> >> I have created a subnet with 10 ips. But now I need more than >> ten instances, is there any way to extend the subnet to add ip address? >> eg: >> I have ten ips as following: >> 172.16.2.210 ~ 172.16.2.220 >> >> I want to add 20 more ips, and so the result will be >> 172.16.2.210 ~ 172.16.2.230 >> >> I try subnet-update command and create a new subnet with the same >> CIDR, but it doesn't work correctly. >> >> Thanks in advance. >> >> ___ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack@lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Flat networking, L2 access and externally assigned IP addresses
On 3 November 2013 12:37, Stuart Longland wrote: > Hi Rob, > On 24/10/13 11:06, Robert Collins wrote: >> Hi there. >> >> Create a provider network in Neutron to represent your external lan, >> and either a) use that as your only network - in which case you'll >> need your external router to handle 169.254.169.254 - the metadata >> agent - or b) add that as a second network when you spawn instances, >> in which case the private overlay network you have running will have >> addresses assigned by neutron - and you'll want to push a host route >> for 169.254.169.254 as you'll have your default route be via the >> provider network.. > > Okay, is this using Flat Networking or something else? TBH I'm not sure 'flat networking' really is a thing in Neutron, is it? I mean, you can configure an equivalent setup with provider networks - which is what I suggest, but it's not a global mode the way it is in nova-networking. > What's the significance of the 169.254.169.254 address? If I were to > add a host route at the external router, to where do I route it? To your nova API server. That address is the magic EC2 metadata API host, which cloud-init queries to do boot-time configuration of your VMs based on cloud metadata. > > Would this give the VM unfettered access to the network? I found last > time I tried flat networking, some packet filtering still occurred. It won't let you spoof traffic; but other than that you should be able to do anything (just open the appropriate ports in your security group). Or - and not recommended IMNSHO - you can use the noop firewall driver and disable security groups. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Wiping of old cinder volumes
On 2 November 2013 12:46, John Griffith wrote: > To be honest, this has been an ongoing battle. The idea of throttling > or spreading the dd's is a good one, but the problem I had here was > then the delete operation can take *even longer* than it does already. > That makes some people rather unhappy, but I think we need to take > another look at the approach, I ran into similar issues today that > drove me crazy deleting a large number of volumes, so I completely > understand/agree with what you're saying. It may actually be best to > go ahead and bight the bullet on the very long delete and lower the > priority as you suggest. > > The other alternatives to consider are: > 1. do you need secure delete, this can be disabled if the answer is no > 2. what platform are you on and could you use thin provisioned LVM > LVM does some things internally here to help us with the > security concerns around data leakage across tenants/volumes You've probably thought of this but: - seems like there is a trivial dos for non-thin provisioned setups (unless a dirty blockmap is kept): - while True: - request the largest available volume - spin up a vm and write a few blocks (defeat trivial 'ever-used' tests) - delete it - It seems to me that IO should be subject to a quota same as networking can be; otherwise in any environment folk will have nothing preventing them pushing IO to the wall and causing massive latency for smaller access pattern (but more latency sensitive) applications [like DB's :)]. - if the IO involved in deleting volumes was accrued to the same quota, you'd have protection against both the DOS, and multiple volumes in a big heat cluster being deleted all at once (and other similar triggers for this situation). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Promoting the role of +1 reviewers in our community
On 30 October 2013 12:08, Tom Fifield wrote: > Hi all, > > Recently, I did something crazy and got into the "top 10" reviewers for > OpenStack in a 30/60 day window. Admittedly, this was for documentation - > which is quite a bit different than code - but the experience did give me a > small window of insight into the challenge faced by our venerable core > reviewers. It's a really tough job! Indeed! > One of the aspects that I noticed in doing so many reviews is that a review > was much easier to perform if another reviewer had been through it > beforehand. That is, a patch had gone through a couple of -1 iterations to > finally get a +1 before I saw it. > > This made me think a little about how much emphasis we place as a community > on +2 reviews. It can seem at times like they're the only reviews we care > about. Hell, I've even heard song lyrics from a community member that imply > this :D I think the focus has to be on lifting everyone's game to the point they can contribute on reviews as effectively as -core folk do today. I waffled on about this in the hyper-v thread a couple weeks back,but in short: The cost of a patch upload is no less than 2 reviews. Therefore, if you upload a patch, you should do 2 reviews and pay it forward. If you're -core, cool, they might be +2's. If you're not core though, you *still* need to do those two reviews, or: - you don't advance along the path to being core capable yourself - the core reviewers end up bearing disproportionate load because they are doing initial reviews themselves. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Key Injection not working after upgrading from Grizzly to Havana
On 29 October 2013 18:31, Bill Owen wrote: > > No - looking at that now. > Thanks, > Bill Owen Ok, so you're still on nova-network. That means you don't have namespaced networks and don't need a namespace-escaping metadata agent. So what you should have is regular 'ip route' inspectable routing from the hypervisor out to through to the network, and an iptables DNAT rule picking up the 169.254.169.254 traffic. Firstly, it looks like the default route the instance is picking up is via 10.10.100.3, is that correct? Secondly, on your hypervisor itself, please gather and attach the output from iptables-save ip route ip address [feel free to mask out any private info] If 10.10.100.3 is the correct default route for the VM, and it's not present on the hypervisor's ip address list, then it's probably your nova network node, so can you log in to it and also gather iptables-save ip route ip address information. What we're looking for in this info is the path a packet from the VM going to 169.254.169.254 port 80 will take. Thats the magic IP address for the metadata service. It should intecepted somewhere on the default route out from the VM. HTH, Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Key Injection not working after upgrading from Grizzly to Havana
about changes in this area in release notes. Any > suggestions on what I might be missing or how to debug would be appreciated! > > In particular, is there a way to increase debug logging so I can see > when it tries to do the key injection on the new vm? > > > > FWIW, cirros image boots and I can ssh/login using cirros user and > password. > > Injection is not under active development in Havana, > and so theoretically nothing should have changed here. > > Are you using libguestfs to do the injection? > What's the value of the following in nova.conf? > > libvirt_inject_key > libvirt_inject_partition > > Note failure to inject a key does not cause a guest to error, > only failure to inject a user specified file does at present. > However at debug level, messages are printed as to why there > were errors with injecting the other components. So please > set debug=True in nova.conf, restart the nova-compute service, > and try again, keeping an eye on /var/log/nova/compute.log > > thanks, > Pádraig. > > > -- Robert Collins Distinguished Technologist HP Converged Cloud <>___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Key Injection not working after upgrading from Grizzly to Havana
On 26 October 2013 13:43, Bill Owen wrote: > I've just updated my test environment to stable-havana. > > I have booted vm instances with Fedora and Ubuntu images with a key_name > specified: > $ nova boot --key_name key --image --flavor 2 test_vm > > After the image becomes active, I try to ssh to the image, but get an error > message: > $ ssh -i key.pem fedora@ > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). This may indicate a failure in cloud-init in your instance. Can you access the machine console log? -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Migrate instances/tenants between clouds
On 25 October 2013 11:57, Joshua Harlow wrote: > Completely agree, and I think there are many people that know its an > issue, which is positive news. > > There are always people who 'pave' over there clouds instead, which to me > is not positive news; > > In fact I think such activities are detrimental to the whole community > (your opinion may vary). > > To me this is why openstack **must** provide a reference cloud and do as > many of these rigorous activities "checking" automatically. > > -Josh https://wiki.openstack.org/TripleO/TripleOCloud :) -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Migrate instances/tenants between clouds
On 25 October 2013 10:20, Shane Johnson wrote: > > > But doesn't that responsibility lie with the package maintainers for > Openstack in each distro? No. The responsibility for making it possible to upgrade in place *reliably* and *with confidence* is an entirely upstream problem. Rigorous backwards compatibility, rigorous testing for performance regressions, reliable upgrade paths, being able to achieve low/no downtime on the cloud during upgrade. All upstream problems. Putting the code into packages and making the packages install well is a distribution problem. For distributions with orchestration code tied into them, orchestrating the upgrade is also a distribution problem (e.g. RDO and UO both offer fully orchestrated deployments, so any upgrade orchestration will be bundled there). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Directional network performance issues with Neutron + OpenvSwitch
> url error [[Errno 113] No route to host] > > -- > > > > > > Do you see anything interesting in the neutron-metadata-agent log? Or it > looks like your instance doesn't have a route to the default gw? > > > > > > Is this problem still around?! > > > > Should I stay away from GRE tunnels when with Havana + Ubuntu 12.04.3? > > > > Is it possible to re-enable Metadata when ovs_use_veth = true ? > > > > Thanks! > > Thiago > > > > On 3 October 2013 06:27, James Page wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 02/10/13 22:49, James Page wrote: >>> sudo ip netns exec qrouter-d3baf1b1-55ee-42cb-a3f6-9629288e3221 >>>> traceroute -n 10.5.0.2 -p 4 --mtu traceroute to 10.5.0.2 >>>> (10.5.0.2), 30 hops max, 65000 byte packets 1 10.5.0.2 0.950 >>>> ms F=1500 0.598 ms 0.566 ms >>>> >>>> The PMTU from the l3 gateway to the instance looks OK to me. >> I spent a bit more time debugging this; performance from within >> the router netns on the L3 gateway node looks good in both >> directions when accessing via the tenant network (10.5.0.2) over >> the qr-X interface, but when accessing through the external >> network from within the netns I see the same performance choke >> upstream into the tenant network. >> >> Which would indicate that my problem lies somewhere around the >> qg-X interface in the router netns - just trying to figure out >> exactly what - maybe iptables is doing something wonky? > > OK - I found a fix but I'm not sure why this makes a difference; > neither my l3-agent or dhcp-agent configuration had 'ovs_use_veth = > True'; I switched this on, clearing everything down, rebooted and now > I seem symmetric good performance across all neutron routers. > > This would point to some sort of underlying bug when ovs_use_veth = False. > > > > - -- > James Page > Ubuntu and Debian Developer > james.p...@ubuntu.com > jamesp...@debian.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSTTh6AAoJEL/srsug59jDmpEP/jaB5/yn9+Xm12XrVu0Q3IV5 > fLGOuBboUgykVVsfkWccI/oygNlBaXIcDuak/E4jxPcoRhLAdY1zpX8MQ8wSsGKd > CjSeuW8xxnXubdfzmsCKSs3FCIBhDkSYzyiJd/raLvCfflyy8Cl7KN2x22mGHJ6z > qZ9APcYfm9qCVbEssA3BHcUL+st1iqMJ0YhVZBk03+QEXaWu3FFbjpjwx3X1ZvV5 > Vbac7enqy7Lr4DSAIJVldeVuRURfv3YE3iJZTIXjaoUCCVTQLm5OmP9TrwBNHLsA > 7W+LceQri+Vh0s4dHPKx5MiHsV3RCydcXkSQFYhx7390CXypMQ6WwXEY/a8Egssg > SuxXByHwEcQFa+9sCwPQ+RXCmC0O6kUi8EPmwadjI5Gc1LoKw5Wov/SEen86fDUW > P9pRXonseYyWN9I4MT4aG1ez8Dqq/SiZyWBHtcITxKI2smD92G9CwWGo4L9oGqJJ > UcHRwQaTHgzy3yETPO25hjax8ZWZGNccHBixMCZKegr9p2dhR+7qF8G7mRtRQLxL > 0fgOAExn/SX59ZT4RaYi9fI6Gng13RtSyI87CJC/50vfTmqoraUUK1aoSjIY4Dt+ > DYEMMLp205uLEj2IyaNTzykR0yh3t6dvfpCCcRA/xPT9slfa0a7P8LafyiWa4/5c > jkJM4Y1BUV+2L5Rrf3sc > =4lO4 > > -END PGP SIGNATURE- > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] [NOVA][NEUTRON] Whats the correct firewall driver and interface driver to use neutron sec groups in havana
(dropping -dev, this is a deployment question). firewall_driver=neutron.agent.firewall.NoopFirewallDriver ^ thats your problem. It's a no-op driver, which means no firewall rules are applied. http://docs.openstack.org/havana/install-guide/install/yum/content/install-neutron.install-plugin-compute.ovs.html (applies to apt etc as well - just the first hit from google :)) covers this part of the setup. -Rob On 24 October 2013 01:57, Leandro Reox wrote: > Hi guys, > > Seem that i cant find the right combination to get neutron security groups > working with nova and OVS > > - I see the logs on the ovs agent like sec group updated or rule updated > - I can configure the rules on neutron without an issue > > BUT > > Seems like nova is not doing anything with the the rules itself, i dont see > any root-wrap event trying to apply an iptables chain, its like the the > agent is not passing the order to apply the rules to nova > > Here is all the nova.conf stuff, and agent logs, and iptables chains: > http://pastebin.com/RMgQxFyN > > > I dont know what to try to get this working , maybe im using the wrong > firewall driver or something ? or do i need for example that neutron and > nova connects to the same queue?? > > Best > Lean > > ___ > OpenStack-dev mailing list > openstack-...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Flat networking, L2 access and externally assigned IP addresses
Hi there. Create a provider network in Neutron to represent your external lan, and either a) use that as your only network - in which case you'll need your external router to handle 169.254.169.254 - the metadata agent - or b) add that as a second network when you spawn instances, in which case the private overlay network you have running will have addresses assigned by neutron - and you'll want to push a host route for 169.254.169.254 as you'll have your default route be via the provider network.. HTH, I'm probably being too brief here, but I get the sense you've been reading etc, so this will at minimum count as a bunch of additional pointers :) -Rob On 27 September 2013 22:42, Stuart Longland wrote: > Hi all, > > I've got a silly question regarding the flat networking in OpenStack. > It looks like it'll do what we want, but I'd like to get some further > information. Apologies if this has been answered, I did look, I didn't > find anything definitive. > > We're in the process of building up a private cloud. Currently, our > network looks much like in the attached diagram. We've got currently: > two storage nodes, running the ceph-ods service; three management nodes > running ceph-ods, MariaDB+Galera, rabbitmq, Keystone, Glance, ... etc; > and a couple of compute nodes. > > All are running Ubuntu 12.04 LTS AMD64, running Intel Core i3 3220T CPUs > at 2.8GHz. > > The storage nodes have 8GB RAM, 2×3TB hard drives and a 60GB SSD and two > network interfaces on-board, which will be joined using LACP. > The management nodes have 8GB RAM and a 60GB SSD, and will possibly gain > 10GbE network cards later for things like Glance. > > The compute nodes have a 60GB SSD two on-board network cards and a third > PCIe network card: the two on-board ones will be joined using LACP for > back-end communications, and the third used as the "public" interface. > > The Flat DHCP network manager looks like it'll be great for some of our > projects: not sure how it does its magic on IPv6 but on IPv4 (as I > understand it), the VMs get placed on a network that's private to the > node running them and the compute node simply routes the traffic, > performing NAT where necessary. > > To make the VM accessible, a floating IP is assigned to the public > interface, and all connections are DNATed to the VM. Again, not sure > how the voodoo works in IPv6-land where NAT doesn't exist, but I digress. > > This seems fine, but for some of our intended applications, particularly > Samba filesharing comes to mind, it's best if the machine were directly > bridged onto the same Ethernet segment as the clients and is either > statically assigned an IP address decided by us network admins, or > receives one from DHCP. > > As it happens, one of our legacy servers already fills the role of DHCP > server, handles dynamic DNS updates and works, so I'd like to use that. > > Maybe I haven't uncovered the magic bit of documentation yet, but it > seems no matter what I do, OpenStack seems to want to be in-charge of > the IP addressing. > > If I bridge the interface on the compute node that shares the Ethernet > segment with the DHCP server with the flat-network bridge (the docs call > this "br100"), I do indeed get our DHCP server responding to the > DHCPREQUESTs, the VM allegedly gets the reply, but then network falls > flat because there's some firewalling there that prevents the VM from > passing traffic on that IP address -- simply because it isn't the IP > that OpenStack was expecting the VM to use. > > I just want to plug the VM into the VLAN via a bridge and let the VM > have full L2 access. > > I've also tried tinkering with the firewall manager; choosing the > NoopFirewallManager just broke things, no connectivity whatsoever, even > though the VM was allegedly bridged to br100. > > How does one give a guest full L2 network access to a bridge defined on > the host? > > Regards, > -- > Stuart Longland > Contractor > _ ___ > \ /|_) | T: +61 7 3535 9619 > \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 >SYSTEMSMilton QLD 4064 http://www.vrt.com.au > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] question regarding vmdk file format for baremetal provisioning
(Dropping -dev, as thisn't a development discussion). If the image is of a single partition - just one file system - then it should work, as long as the format is supported by qemu-img. Some vendors have their kernel and ramdisk not include all drivers though, which means your 'off the shelf' kernel+ramdisk may not have the needed hardware support for your hardware. -Rob On 22 October 2013 17:14, Ravikanth Samprathi wrote: > The vmdk i have is from a VM that has not been partitioned, does it mean, it > will not work? > Meaning, i cannot use an off the shelf kernel, ramdisk and use the > qcow2-converted-image-from-vmdk? > Thanks > Ravi > > > > On Mon, Oct 21, 2013 at 8:18 PM, Robert Collins > wrote: >> >> You'll need a format qemu-img supports; diskimage-builder outputs >> qcow2 by default, for instance. >> >> Also note it must be a partition image, not a full disk image. >> >> Cheers, >> Rob >> >> On 22 October 2013 16:15, Ravikanth Samprathi wrote: >> > Hi >> > Am using a vmdk file for provisioning baremetal. But the nova failed >> > with >> > nova-compute log having the following message: >> > ERROR nova.compute.manager . Unexpected error while running command >> > qemu-img convert error while reading sector 131072 Invalid >> > argument. >> > >> > Can someone provide some help/pointers. >> > Thanks >> > Ravi >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > openstack-...@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Robert Collins >> Distinguished Technologist >> HP Converged Cloud >> >> ___ >> 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 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] question regarding vmdk file format for baremetal provisioning
You'll need a format qemu-img supports; diskimage-builder outputs qcow2 by default, for instance. Also note it must be a partition image, not a full disk image. Cheers, Rob On 22 October 2013 16:15, Ravikanth Samprathi wrote: > Hi > Am using a vmdk file for provisioning baremetal. But the nova failed with > nova-compute log having the following message: > ERROR nova.compute.manager . Unexpected error while running command > qemu-img convert error while reading sector 131072 Invalid > argument. > > Can someone provide some help/pointers. > Thanks > Ravi > > > ___ > OpenStack-dev mailing list > openstack-...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Grizzly] All "flows" on compute-node disappear & all instances lost connectivity [URGENT]
We saw a similar thing in TripleO on Fedora machines with GRE blocked by host firewalls. You might check that GRE packets are permitted. -Rob On 16 October 2013 22:26, Chu Duc Minh wrote: > I use Quantum with VLAN and ip networknamespace. > After update some packages, all cloud instances lost connectivity. > > I run "ovs-vsctl show" and "ovs-ofctl dump-flows br-int" on both > quantum-node and compute-node to check. > In Quantum node, everything is ok. > root@quantum:/etc/init.d# ovs-ofctl dump-flows br-int > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=3284.199s, table=0, n_packets=33404, n_bytes=2134467, > priority=2,in_port=156 actions=drop > cookie=0x0, duration=3199.3s, table=0, n_packets=1593, n_bytes=101952, > priority=3,in_port=156,dl_vlan=101 actions=mod_vlan_vid:14,NORMAL > cookie=0x0, duration=3090.599s, table=0, n_packets=1539, n_bytes=98496, > priority=3,in_port=156,dl_vlan=114 actions=mod_vlan_vid:23,NORMAL > cookie=0x0, duration=3125.8s, table=0, n_packets=4036, n_bytes=257248, > priority=3,in_port=156,dl_vlan=4 actions=mod_vlan_vid:21,NORMAL > v.v... > > But in compute node, all my flows disappear: > root@compute-01:~# ovs-ofctl dump-flows br-int > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=604.009s, table=0, n_packets=12897, n_bytes=823626, > priority=2,in_port=1 actions=drop > cookie=0x0, duration=604.591s, table=0, n_packets=0, n_bytes=0, priority=1 > actions=NORMAL > > I restarted nova-compute, quantum-plugin-openvswitch-agent. Also reboot > compute node. > But nothing can help. > > I checked log and did not found any error. > Do you know a quick fix for situation like that? > > Thank you very much! > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] OpenStack Core Online Forum > scheduling time for + UTC timezones
WFM -Rob On 15 October 2013 10:35, wrote: > Michael (& Community) > > Good analysis. So, we got a time (0100 UTC) but my head hurts from thinking > about the date. > > I’m looking at Tuesday 10/22 @ 0100 UTC (which would be Mon 10/21 @ 2000 for > me in Central). > > I’d be interested in seeing some +1s on this time before I set it up. > > REMINDER: we’re doing the – UTC Core Meetup on Wednesday 10/16 @ 1330 UTC. > > Rob > > -Original Message- > From: mikalst...@gmail.com [mailto:mikalst...@gmail.com] On Behalf Of > Michael Still > Sent: Monday, October 14, 2013 3:18 PM > To: Hirschfeld, Rob > Cc: openstack@lists.openstack.org > Subject: Re: [Openstack] OpenStack Core Online Forum, Oct 16 13:30 UTC > #openstack-meeting-alt > > On Sun, Oct 13, 2013 at 1:46 PM, wrote: >> I’d love some suggestions (in UTC) that people think would work best. AM? >> PM? >> >> My thought is to target 0200 UTC to catch morning without having to go >> too late for US. Would that work? > > I needed a picture to help me figure this out. One, with apologies to > timeanddate.com, is at > http://www.stillhq.com/openstack/timezones-whatiscore.png . The circles > indicate cities I am aware of meetups having happened in, the bar indicates > acceptable coverage for the first online session (assuming that acceptable > means starts after 8am local time, but not later than 8pm local time). > > So, it seems to me that a meetup time that meets these requirements is 8am > in UTC +7. That's 1am UTC. > > Michael > > -- > Rackspace Australia > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Directional network performance issues with Neutron + OpenvSwitch
I believe it's still needed: upstream kernel have pushed back against the modules it provides, but neutron needs them to deliver the gre tunnels. -Rob On 3 October 2013 13:15, Martinx - ジェームズ wrote: > Hi James, > > Let me ask you something... > > Are you using the package `openvswitch-datapath-dkms' from Havana Ubuntu > Cloud Archive with Linux 3.8? > > I am unable to compile that module on top of Ubuntu 12.04.3 (with Linux 3.8) > and I'm wondering if it is still required or not... > > Thanks! > Thiago > > > On 2 October 2013 06:14, James Page wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Hi Folks >> >> I'm seeing an odd direction performance issue with my Havana test rig >> which I'm struggling to debug; details: >> >> Ubuntu 12.04 with Linux 3.8 backports kernel, Havana Cloud Archive >> (currently Havana b3, OpenvSwitch 1.10.2), OpenvSwitch plugin with GRE >> overlay networks. >> >> I've configured the MTU's on all of the physical host network >> interfaces to 1546 to add capacity for the GRE network headers. >> >> Performance between instances within a single tenant network on >> different physical hosts is as I would expect (near 1GBps), but I see >> issues when data transits the Neutron L3 gateway - in the example >> below churel is a physical host on the same network as the layer 3 >> gateway: >> >> ubuntu@churel:~$ scp hardware.dump 10.98.191.103: >> hardware.dump >> 100% 67MB 4.8MB/s >> 00:14 >> >> ubuntu@churel:~$ scp 10.98.191.103:hardware.dump . >> hardware.dump >> 100% 67MB >> 66.8MB/s 00:01 >> >> As you can see, pushing data to the instance (via a floating ip >> 10.98.191.103) is painfully slow, whereas pulling the same data is >> x10+ faster (and closer to what I would expect). >> >> iperf confirms the same: >> >> ubuntu@churel:~$ iperf -c 10.98.191.103 -m >> - >> Client connecting to 10.98.191.103, TCP port 5001 >> TCP window size: 22.9 KByte (default) >> - >> [ 3] local 10.98.191.11 port 55330 connected with 10.98.191.103 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 60.8 MBytes 50.8 Mbits/sec >> [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) >> >> ubuntu@james-page-bastion:~$ iperf -c 10.98.191.11 -m >> >> >> - >> Client connecting to 10.98.191.11, TCP port 5001 >> TCP window size: 23.3 KByte (default) >> - >> [ 3] local 10.5.0.2 port 52190 connected with 10.98.191.11 port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 1.07 GBytes 918 Mbits/sec >> [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) >> >> >> 918Mbit vs 50Mbits. >> >> I tcpdump'ed the traffic and I see alot of duplicate acks which makes >> me suspect some sort of packet fragmentation but its got me puzzled. >> >> Anyone have any ideas about how to debug this further? or has anyone >> seen anything like this before? >> >> Cheers >> >> James >> >> >> - -- >> James Page >> Ubuntu and Debian Developer >> james.p...@ubuntu.com >> jamesp...@debian.org >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.14 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJSS+QSAAoJEL/srsug59jD8ZcQAKbZDVU8KKa7hsic7+ulqWQQ >> EFbq8Im5x4mQY7htIvIOM26BR0ktAO5luE7zMBXsA4AwPud1BQSGhw89/NvNhADT >> TLcGdQADsomeiBpJebzwUmvL/tYUoMDRA3O96mUn2pi0fySWbEuEgMDjDJ/ow23D >> Y7nEv0mItaZ4MBSI9RZcqsDUl7UbbdlGejSWhJcwp/127HMU9nYwWNz5UHJjsGZ1 >> eITyv1WZH/dYPQ1SES41qD1WvkTBugopGJvptEyrcO62A+akGOvnqpsHgPECbLb+ >> b/8rk8nB1HB74Wh+tQP4WRQCZYso15nB6ukIyIU24Qti2tXtXDdKwszEoblCwCT3 >> YZJTERNOENURlUEFwgi6FNL+nZomSG0UJU6qqDGiUJkbSF7SwJm4y8/XRlJM2Ihn >> wyxFB0qe3YdMqgDLZn11GwCDqn3g11hYaocHNUyRaj/tgxhGKbOFvix5kz3I4V7T >> gd+sqUySMVd9wCRXBzDDhCuG9xf/QY2ZQxXzyfPJWd9svPh/O6osTSQzaI1eZl9/ >> jVRejMAFr6Rl11GPKd3DYi32GXa896QELjBmJ9Kof0NDlCcDuUKpVeifIhcbQZZV >> sWyQmbb6Z/ypFV9xXiLRfH2fW2bAQQHgiQGvy9apoE78BWYdnsD8Q3Ekwag6lFqp >> yUwt/RcRXS1PbLG4EGFW >> =HTvW >> -END PGP SIGNATURE- >> >> ___
Re: [Openstack] More than one compute_driver in nova.conf
On 13 August 2013 15:15, Jake G. wrote: > > I was wondering how to handle changing the compute_driver in nova.conf? I > currently have the default > > compute_driver = libvirt.LibvirtDriver > libvirt_type=kvm > > I want to be able to add the driver for baremetal provisioning, but I am > unclear on how to do this. > Can there be more than one compute_driver or do I have to replace > compute_driver = libvirt.LibvirtDriver with the new driver. You need to have a dedicated nova cell/region/cloud for baremetal. We change the scheduler at a fairly fundamental layer - Devananda has plans to rectify this, but probably only after Ironic is stable. > If I can only replace what will happen to my existing KVM and nova > operations? I suggest spinning up a new host rather than modifying your existing one. > Also, I am just using the bearmetal driver as an example. This same question > can be applied to any other feature that requires a different > compute_driver. Baremetal is special - unlike lxc/kvm/qemu baremetal doesn't subdivide an existing hypervisors resources, rather it hands out entire machines - so it has to match exactly rather than matching a subset when comparing flavors. Cheers, Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Help with quantum/neutron provider networks (transition from nova-network)
You need to connect the exterior network to the integration bridge
yourself. This is in the deployer docs somewhere, I don't recall
offhand - sorry.
-Rob
On 12 August 2013 06:26, Jonathan Proulx wrote:
> Bad form to self-reply but it's off hours for most and this is probably
> useful new information..
>
> the vm's tap device on the compute node is being put in the bridge "int-br",
> if I remove it and put in the "trunk" bridge with the correct tag it works
> as I want:
>
> root@nova-0:~# ovs-vsctl del-port br-int tapd2799dad-27
> root@nova-0:~# ovs-vsctl add-port trunk tapd2799dad-27 tag=2113
>
> This what I wanted to happen but clearly I have something confused, can
> quantum/neutron do this & if so how do I tell it to?
>
>
> On Sun, Aug 11, 2013 at 8:07 AM, Jonathan Proulx wrote:
>>
>> HI All,
>>
>> My maintenance window is closing and I haven't yet managed the transition
>> I planned from nova-network to quantum/neutron with ovs plugin. Using
>> Ubuntu 12.04 Cloud archive packages (and puppetlabs openstack modules,
>> though I had the same results by hand so likely confusion on my part rather
>> than a typo)
>>
>> I want to create a provider network that plugs instances directly into an
>> existing vlan which already has a router, dhcp (and other non-openstack)
>> hosts. Previously this is where nova-network got it's "floating ip" ranges.
>> I have interfaces on compute nodes and network controller with this vlan
>> trunked, also their public IPs are on this vlan so they have another
>> interface i could use to provide "flat" access, but I'd rather go vlan as I
>> have other nets I want to implement too.
>>
>> I created the network with:
>> quantum net-create public-inet --shared --provider:network_type vlan
>> --provider:physical_network trunk --provider:segmentation_id 2113
>>
>> on network controller and compute node 'ovs-vsctl list-ifaces trunk' shows
>> a single physical interface as a member (bond0, and eth1 respectively) these
>> interfaces are up and are the ones with trunks defined on the attached
>> switch. Neither has an IP addr (though bond0.2113 on the controller is the
>> primary public interface, perhaps this is an issue?) an other possible issue
>> is that this is jumbo frames network so I need to set MTU...but I expect
>> that problem comes after the current one.
>>
>> in the config I have set:
>> bridge_mappings=trunk:-br
>>
>> should I have not set them to
>>
>> when I launch an instance with this network it does get an interface but
>> is seems not to be connected to the outside.
>>
>> the quantum-server log complains:
>> 2013-08-11 07:32:30 WARNING [quantum.db.agentschedulers_db] Fail
>> scheduling network {'status': u'ACTIVE', 'subnets':
>> [u'7dd56379-90f5-4c79-b127-954c0fcbdca1'], 'name': u'public-inet',
>> 'provider:physical_network': u'trunk', 'admin_state_up': True, 'tenant_id':
>> u'6f9adccbd03e4d2186756896957a14bf', 'provider:network_type': u'vlan',
>> 'router:external': False, 'shared': True, 'id':
>> u'2c3ee609-ff51-4650-8541-737b0ca72f0c', 'provider:segmentation_id': 2113L}
>>
>> The compute node shows
>> 2013-08-11 07:32:30 INFO [quantum.agent.securitygroups_rpc] Security
>> group member updated [u'e4ad30f9-e50b-49fc-9d81-26c875ac15b8',
>> u'e5209cd6-b881-4633-b955-fdde1fefea58']
>> 2013-08-11 07:32:39 INFO [quantum.agent.securitygroups_rpc] Preparing
>> filters for devices set(['96555a4a-d6c1-4c8a-a65e-31317370c08d'])
>> 2013-08-11 07:32:40 INFO
>> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Port
>> 96555a4a-d6c1-4c8a-a65e-31317370c08d added
>> 2013-08-11 07:32:40 INFO
>> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Port
>> 96555a4a-d6c1-4c8a-a65e-31317370c08d updated. Details: {u'admin_state_up':
>> True, u'network_id': u'2c3ee609-ff51-4650-8541-737b0ca72f0c',
>> u'segmentation_id': 2113, u'physical_network': u'trunk', u'device':
>> u'96555a4a-d6c1-4c8a-a65e-31317370c08d', u'port_id':
>> u'96555a4a-d6c1-4c8a-a65e-31317370c08d', u'network_type': u'vlan'}
>> 2013-08-11 07:32:40 INFO
>> [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Assigning 5 as local
>> vlan for net-id=2c3ee609-ff51-4650-8541-737b0ca72f0c
>>
>> Can anyone see what I'm misunderstanding?
>>
>> Thanks,
>> -Jon
>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] OpenStack and its brilliant future with IPv6 and, we don't need...
On 9 August 2013 07:51, Martinx - ジェームズ wrote: > 1- NAT; There's no /need/ for it in IP4 in a lot of environments. Only public cloud providers really need to do NAT in IP4. > 2- Floating IPs; Implemented via NAT, but not about NAT: they are about being able to move endpoints instantly without dns cache issues - an HA tool, and a well-known-address tool. The implementation is changable but the concept is valuable in IPv6 too IMNSHO. > 3- Use of Namespaces. I don't see how this is related : with SDN someone can define the same IPv6 range in two tenants, so namespaces are still needed. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] DB access not allowed for libvirt driver?
Thats correct, it needs to go via the conductor now. At least, thats my understanding. -Rob On 6 August 2013 23:39, Peeyush Gupta wrote: > Hi all, > > I am trying to access nova.db from nova.virt.libvirt.driver for some > experiment purposes. When I tried that, I got an error saying "DB > not allowed: nova compute". > > Why am I getting this? Is libvirt driver not allowed to talk to db? > > Thanks. > > ~Peeyush Gupta > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Robert Collins Distinguished Technologist HP Converged Cloud ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
