Re: [Openstack] DHCP release
On Mar 23, 2013 4:02 AM, David Hill david.h...@ubisoft.com wrote: From: Robert Collins [robe...@robertcollins.net] Sent: March 23, 2013 02:21 To: David Hill Cc: Kevin Stevens; openstack@lists.launchpad.net Subject: Re: [Openstack] DHCP release On 23 March 2013 14:53, David Hill david.h...@ubisoft.com wrote: Hello Kevin, Thanks for replying to my question. I was asking that question because if we go there: http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-vlan-networking.html and look at the very bottom of the page, it suggests the following: # release leases immediately on terminate force_dhcp_release=true? (did I miss something?) # one week lease time dhcp_lease_time=604800 # two week disassociate timeout fixed_ip_disassociate_timeout=1209600 I tried that and if you have at some creation/destruction of virtual machines, let's say 2046 in the same week, you'll end up burning the 2046 IPs because they're never disassociated. At some point, nova-network complains with no more fixed IP are available. Changing fixed_ip_disassociate_timeout to something smaller solves this issue. Is there any reasons why fixed_ip_disassociate_timeout should be bigger than dhcp_lease_time? Also, I thought that by destroying a virtual machine, it would release/disassociate the IP from the UUID since it has been destroyed (DELETED). I've turned on the debugging and with fixed_ip_disassociate_timeout set to 600 seocnds, it disassociate stale IPs after they've been deleted for at least 600 seconds. Is it a bug in our setup/nova-network or nova-network/manage relies on the periodic task that disassociate stale IPs in order to regain those IPs? Finaly, wouldn't it be better to simply disassociate a released IP as soon as the VM is deleted? Since we deleted the VM, why keep it in the database? When you reuse an IP address you run the risk of other machines that have the IP cached (e.g. as DNS lookup result, or because they were configured to use it as a service endpoint) talking to the wrong machine. The long timeout is to prevent the sort of confusing hard to debug errors that that happen when machine A is replaced by machine C on A's IP address. My 2c: just make your pool larger. Grab 10/8 and have 16M ip's to play with. -Rob I'm not the network guy here but, if I use a 10/8 and that we already have 10/8 in our internal network, this could easily become a problem am I wrong? Also, if a VM is deleted, IMHO, it's destroyed with all it's network. I don't know if this is old minding or anything, but when I destroy a VM in VSphere, I expect it to disappear leaving no trace. This is the cloud, and when I delete something, I expect it to simply be deleted. My 2c, but I see your point and have nothing against it. Dave ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp David, I believe the biggest reason for the long timeout is historical based on bugs in dnsmasq [1]. You can probably just use the default of 600 now if you're using a new enough version of dnsmasq. [1] - https://lists.launchpad.net/openstack/msg11696.html Thanks, Nate ___ 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] Project quotas on multi-region
On Mar 23, 2013 7:59 PM, Aguiar, Glaucimar (Brazil RD-ECL) glaucimar.agu...@hp.com wrote: Hi, In a deployment scenario where one keystone has several regions registered, how the project quota are managed by, as an example, two nova services in two different regions? I am wondering if is it possible to set quota on the project for all regions or this must to be done on a region by region basis which really means a quota for a project in a region. Thanks in advance, Glaucimar Aguiar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Glaucimar, Currently quotas are maintained within each nova system so there is not a global view/management/enforcement of quotas. I would love to see a discussion of centralizing things from nova like key pairs, AZs, and quotas in keystone. Thanks, Nate ___ 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] DHCP lease not accepted when libvirt_use_virtio_for_bridges=true
On Wed, Mar 20, 2013 at 3:51 PM, Lorin Hochstein lo...@nimbisservices.comwrote: I'm doing a Folsom deployment with FlatDHCP (not multihost). When I try to boot a quantal image, the instance doesn't pick up the DHCP lease. I've confirmed that dnsmasq is sending out the DHCPOFFER, and I can see by tcpdump on the compute host that the DHCP packets are making it to the vnet0 interface. Note that I tried adding this iptables rule as mentioned here https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/issues/14, but that didn't resolve it. iptables -D POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill However, the problem goes away if I change this setting on the compute hosts in /etc/nova/nova.conf libvirt_use_virtio_for_bridges=true to: libvirt_use_virtio_for_bridges=false Anybody know what would cause this? I'm on Ubuntu 12.04 with the cloud-archive packages, with KVM as the hypervisor Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp You didn't restart nova-network without killing and restarting dnsmasq, did you? Nate ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova-compute and querying keystone for glance endpoint
On Tue, Mar 19, 2013 at 11:39 PM, Lorin Hochstein lo...@nimbisservices.comwrote: Hi All: I was doing a Folsom deployment from scratch, and when I tried to launch an instance my compute host failed to connect to the glance server to download the image, instead it tried to connect to itself. I can resolve this by putting glance_host=ip into nova.conf. But I'd prefer if my compute host fetched this information from keystone rather than hard-code (hard-configure?) like this. I assume that I don't have the right config in nova.conf (a template for that file is here: https://github.com/lorin/openstack-ansible/blob/folsom/playbooks/templates/etc/nova/nova.conf). However, tracing through the nova code, I couldn't figure out where it was that the compute host was supposed to connect to keystone to get the right endpoint for glance. Where in the nova Folsom code does the nova-compute service query the keystone service catalog to get the endpoint for glance? Lorin, I don't believe nova pulls the glance endpoint from keystone's service catalog. I believe it's based on FLAGS.glance_api_servers here https://github.com/openstack/nova/blob/stable/folsom/nova/image/glance.py#L73 Nate Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ 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] nova-compute and querying keystone for glance endpoint
On Mar 19, 2013 11:56 PM, Lorin Hochstein lo...@nimbisservices.com wrote: OK, so I'm not crazy, that means that I really do need to do something like: glance_api_servers=192.168.206.130:9292 or (since the default port is used) glance_host=192.168.206.130 Lorin Kinda, if using FLAGS.glance_api_servers you still need to specify the port because the code will default to port 80 if not specified [1]. Also if your glance server is configured with SSL you would do: glance_api_servers=https://192.168.206.130:9292 Looking back at the code, your original idea also works. If you just specify FLAGS.glance_host it will build FLAGS.glance_api_servers based on your glance_host and the default glance_port [2]. I've always specified the glance_api_servers flag since it's the only way to specify SSL. [1] - https://github.com/openstack/nova/blob/stable/folsom/nova/image/glance.py#L84 [2] - https://github.com/openstack/nova/blob/stable/folsom/nova/flags.py#L138 Nate ___ 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] git review failure
Ensure you have the ssh key(s) you are using registered here: https://review.openstack.org/#/settings/ssh-keys What error do you get when you run ssh with the verbose flags -vvv? You might need to pass the path to your private ssh key, with -i. When it works you should get this: mathrock@devstack:~/devel/openstack/$ ssh -p 29418 mathr...@review.openstack.org Welcome to Gerrit Code Review Hi Nathanael I Burton, you have successfully connected over SSH. Unfortunately, interactive shells are disabled. To clone a hosted Git repository, use: git clone ssh://mathr...@review.openstack.org:29418/REPOSITORY_NAME.git Connection to review.openstack.org closed. On Sun, Mar 17, 2013 at 4:32 PM, Ronak Shah ro...@nuagenetworks.net wrote: Hi all, As I start active contribution to openstack I am running into a basic problem where I am unable to ssh into review.openstack.org. I have read and follow the steps here: https://wiki.openstack.org/wiki/HowToContribute#Contributors_License_Agreement https://wiki.openstack.org/wiki/GerritWorkflow I am stuck @ doing following: git review -s I have done following: git remote add gerrit ssh://username@review.openstack.org:29418/openstack/nova.git ___ 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] Authorization Question
Dolph, In our deployments we often want to restrict projects to particular endpoints or regions. We've currently hacked that in to our Folsom systems by adding a 'regions' list to the 'extra' column of the tenant table. With only a few minor tweaks to keystone to return the filtered service catalog based on 'regions' and some minor tweaks to Horizon it all works out fairly well. We would prefer to do this in a much more supported configuration, something like attributes or roles on projects to achieve the same result. Thanks, Nate On Mon, Mar 4, 2013 at 5:02 PM, Dolph Mathews dolph.math...@gmail.comwrote: That's correct. Right now, all endpoints registered in keystone are returned to all users, regardless of whether they actually have any sort of authorization on those endpoints. I suspect we'll be having a planning session at the design summit on this topic -- I'd be helpful to better understand your ideal use case in suppressing endpoints from the catalog? In Grizzly, users, groups, projects, and domains have absolutely no relationship with services and endpoints within keystone. That becomes deployment specific when you consider how RBAC is applied service-side with policy.json, etc, but those services are not necessarily aware of how they appear in the service catalog, nor does keystone interpret policy files other than it's own. -Dolph On Mon, Mar 4, 2013 at 2:32 PM, Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com wrote: Hello, ** ** I have been looking over the Keystone v3 API documentation as well as the database table columns. My question concerns endpoint access restrictions. I don’t see any noticeable way to associate endpoints with domains which means that any user can access any endpoint of any domain. Is this correct? The only database column that might come into play is the region column of the endpoint table. ** ** Regards, ** ** Mark Miller ___ 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] cannot restart the instance
How did you shut off your instance? Are you sure you didn't terminate it? Does nova list or euca-describe-instances still show information about this instance? Nate On Jan 6, 2013 12:46 PM, 小盆儿 zhaopeng1...@gmail.com wrote: no one knows how to fix this? help me please 2012/12/31 小盆儿 zhaopeng1...@gmail.com hey guys~ I just shutoff one of my instance . but when I try to start it ,I got the errors like below: 2012-12-31 16:31:12 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last): 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py, line 275, in _process_data 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp rval = self.proxy.dispatch(ctxt, version, method, **args) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py, line 145, in dispatch 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return getattr(proxyobj, method)(ctxt, **kwargs) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 117, in wrapped 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp temp_level, payload) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.gen.next() 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 92, in wrapped 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return f(*args, **kw) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 181, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp pass 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.gen.next() 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 167, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return function(self, context, *args, **kwargs) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 202, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp kwargs['instance']['uuid'], e, sys.exc_info()) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.gen.next() 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 196, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return function(self, context, *args, **kwargs) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 953, in start_instance 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.power_on_instance(context, instance) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 117, in wrapped 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp temp_level, payload) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.gen.next() 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 92, in wrapped 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return f(*args, **kw) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 181, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp pass 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp self.gen.next() 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 167, in decorated_function 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp return function(self, context, *args, **kwargs) 2012-12-31 16:31:12 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 202, in decorated_function 2012-12-31 16:31:12 TRACE
Re: [Openstack] Openstack Version (Essex or Folsom)
By default, this requires the admin role to launch instances on specific hosts. Nate On Jan 6, 2013 1:24 PM, Umar Draz unix...@gmail.com wrote: Hi 1) How I can check which Release of Openstack I am using. 2) I want to boot instance on specific compute-node using this command nova boot --image uuid --flavor m1.tiny --key_name mykey --availability-zone nova:server2 but its not working. What is the correct way to do this? Best Regards, Umar ___ 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 Version (Essex or Folsom)
On Jan 6, 2013 1:43 PM, Umar Draz unix...@gmail.com wrote: I am Admin and I used this command on Controller node as root, then what else admin? Best Regards, Umar Umar, The OpenStack user account that you are using to launch instances needs to have the admin role in keystone for the tenant you are operating within. See add-user-role in http://docs.openstack.org/trunk/openstack-compute/admin/content/adding-users-tenants-and-roles-with-python-keystoneclient.html Nate ___ 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 Version (Essex or Folsom)
Ah! It looks like you've changed the default availability zone for your two nodes. Host compute1 is in AZ compute1, host compute2 is in AZ compute2. What does nova-manage service list show? How about trying the following to boot an instance on compute2 (basically the format of the value for the availability-zone parameter is availability zone name:compute node hostname): nova boot --flavor 1 --image ubuntuRebel --availability-zone compute2:compute2 myInstanceName Thanks, Nate On Sun, Jan 6, 2013 at 4:39 PM, Umar Draz unix...@gmail.com wrote: Hi thanks For your awnswers. I did everything. But nova boot not working. nova boot --flavor 1 --image ubuntuRebel --availability-zone nova:compute1 myInstanceName but the output is | Property| Value| +-+--+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-SRV-ATTR:host| compute2 | | OS-EXT-SRV-ATTR:hypervisor_hostname | compute2.yourdomain.com | | OS-EXT-SRV-ATTR:instance_name | instance-005a| | OS-EXT-STS:power_state | 0| | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building Here is the nova.conf file compute1 node_availability_zone=compute1 and here is the nova.conf file of compute2 node_availability_zone=compute2 I think there is bug in openstack ?? Best Regards, Umar On Mon, Jan 7, 2013 at 1:46 AM, Anne Gentle a...@openstack.org wrote: Answers below. On Sun, Jan 6, 2013 at 12:22 PM, Umar Draz unix...@gmail.com wrote: Hi 1) How I can check which Release of Openstack I am using. From http://docs.openstack.org/trunk/openstack-compute/install/apt/content/compute-verifying-install.html : You can find the version of the installation by using the *nova-manage*command, as root: # nova-manage version list The version number 2012.2 corresponds with the Folsom release of Compute. 2012.2 (2012.1-LOCALBRANCH:LOCALREVISION) Here's a table showing the release names corresponding to the version numbers. http://docs.openstack.org/trunk/openstack-compute/install/apt/content/version.html 2) I want to boot instance on specific compute-node using this command nova boot --image uuid --flavor m1.tiny --key_name mykey --availability-zone nova:server2 --force_hosts no longer available in Folsom. It was available in Essex. There was a recent mailing list discussion about the use of policies to enable non-admin users to use the availability-zone param: https://lists.launchpad.net/openstack/msg19784.html but its not working. What is the correct way to do this? This is how it works on Essex: http://docs.openstack.org/essex/openstack-compute/admin/content/specify-host-to-boot-instances-on.html Hope this gets you on track. Anne Best Regards, Umar ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Umar Draz Network Architect ___ 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] floating ip takes a long time to be accessible
On Dec 17, 2012 2:05 PM, Xin Zhao xz...@bnl.gov wrote: Hello, I allocate 2 public ips to instances, the first one becomes accessible almost immediately, but the second one always take a long time to be pingable. It doesn't matter which specific IP is assigned first or second, it's always the second one that is slow to be reachable, although the corresponding iptable rules are all set on the controller node almost immediately. Has anyone seen similar behavior? I am using essex (2012.1) on RHEL6. Thanks, Xin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Xin, You may need to use send_arp_for_ha=true to send a gratuitous ARP if you're using multi-host networking. Nate ___ 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 bridge mapping dhcp default route (optsfile tag:tag0 setting?)
Usually the line in dnsmasq.conf looks like this (below). Haven't used Quantum yet so don't know if the 'dhcp-option=' part being missing is the problem or not. dhcp-option=tag:'unicorns',option:router,172.16.100.1 Nate On Nov 30, 2012 12:10 PM, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: Yes the tag setting should be in the opts file. Ok, thanks, at least I do not have to look for a wrong configuration then. What version of dnsmasq are you running? dnsmasq-2.48-6.el6.x86_64 Also can you get a tcpdump of the DHCP traffic? FYI: this is a different subnet example This is the opts file: tag:tag0,option:router,172.16.51.254 The 172.16.51.100 is the dhcp server The tcpdump: 18:04:29.000231 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 338) 0.0.0.0.bootpc 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:9b:99:5a, length 310, xid 0xf1ffd930, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:9b:99:5a Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.16.51.101 Parameter-Request Option 55, length 13: Subnet-Mask, BR, Time-Zone, Classless-Static-Route Domain-Name, Domain-Name-Server, Hostname, YD YS, NTP, MTU, Option 119 Default-Gateway Vendor-Class Option 60, length 43: anaconda-Linux 2.6.32-279.el6.x86_64 x86_64 END Option 255, length 0 18:04:29.000441 IP (tos 0x0, ttl 64, id 20383, offset 0, flags [none], proto UDP (17), length 351) 172.16.51.100.bootps 172.16.51.101.bootpc: [bad udp cksum b940!] BOOTP/DHCP, Reply, length 323, xid 0xf1ffd930, Flags [none] (0x) Your-IP 172.16.51.101 Server-IP 172.16.51.100 Client-Ethernet-Address fa:16:3e:9b:99:5a Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 172.16.51.100 Lease-Time Option 51, length 4: 120 RN Option 58, length 4: 60 RB Option 59, length 4: 105 Subnet-Mask Option 1, length 4: 255.255.252.0 BR Option 28, length 4: 172.16.51.255 Default-Gateway Option 3, length 4: 172.16.51.100 Domain-Name-Server Option 6, length 4: 172.16.51.100 Domain-Name Option 15, length 14: openstacklocal Hostname Option 12, length 13: 172-16-51-101 END Option 255, length 0 ___ 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] A point in my mind which may be already implemented
On Nov 4, 2012 9:36 AM, Nah, Zhongyue zhongyue@intel.com wrote: I use the log files beneath /var/log/project name to do what you've described manually. If you want a web interface, you should implement a custom notifier class(for Nova) to gather the logs into a specific channel and implement your own web service to display the contents from the channel. -zhongyue Sent from my iPhone On Nov 4, 2012, at 10:18 PM, Hao Wang hao.1.w...@gmail.com wrote: Hi stackers, Today there is a point in my mind that is described as below. Just want to know if it's already implemented in F version. While I'm using OpenStack, I would like this kind of function to know what is going on at the background. For instance, if I click Launch button, I am able to know what message is being sent out to message queue and which component(s) the message is going, and the most important thing is where the message stuck. This would give us a direct view to do troubleshooting and do some specific steps later on. Thanks for your time. Regards, Howard ___ 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 I think the notification system is what you really want. http://wiki.openstack.org/SystemUsageData Sandy Walsh made some really useful tools to easily get at that data and make sense of everything. https://github.com/rackspace/stacktach https://github.com/rackspace/stacky Nate ___ 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] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
On Oct 21, 2012 12:11 PM, Joe Savak joe.sa...@rackspace.com wrote: +1. ;) So the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I'd like to have the same flexibility. I don't see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish. Isn't that a security issue in and of itself? Shouldn't we force re-auth to change the password? Nate ___ 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] dnsmasq stops talking to instances?
I've noticed similar behavior where dnsmasq stops working if nova-network is restarted without first killing all the dnsmasq processes. On Oct 19, 2012 10:24 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: On Thu, Oct 18, 2012 at 06:16:07PM +0100, Ronivon Costa wrote: I have noticed a similar behaviour, for example when the switch/router is rebooted. I am able to recover the communications with the VMs restarting nova network (no need to kill dnsmasq). There are no network devices being rebooted here...and since we're running in multi_host mode, both dnsmasq and the affected instances are running *on the same physical system*. It happened again last night -- which means we were without networking on our instances for about seven hours -- and restarting nova-network doesn't resolve the problem. It is necessary to first kill dnsmasq (and allow nova-network to restart it). There are no errors being logged by dnsmasq; started just after 2AM, all of the DHCPREQUEST ... traffic just stops, and the logs after that point look like this: Oct 19 02:02:34 stack-1 dnsmasq[32013]: read /etc/hosts - 2 addresses Oct 19 02:02:34 stack-1 dnsmasq[32013]: read /var/lib/nova/networks/nova-br662.conf Oct 19 02:02:35 stack-1 dnsmasq[32013]: read /etc/hosts - 2 addresses Oct 19 02:02:35 stack-1 dnsmasq[32013]: read /var/lib/nova/networks/nova-br662.conf Oct 19 02:03:12 stack-1 dnsmasq[32013]: read /etc/hosts - 2 addresses Oct 19 02:03:12 stack-1 dnsmasq[32013]: read /var/lib/nova/networks/nova-br662.conf ...until I restart things. -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Error while installing Nova (OpenStack-Essex)
Pavan, The message is not an error but a warning that a particular python call (Pool.add_listener) is deprecated and will be removed in a future version of the module. Thanks, Nate On Oct 16, 2012 11:20 AM, Pavan Kulkarni pavan.babu...@gmail.com wrote: Hi, I am trying to install Openstack Essex following the instructions from this linkhttp://docs.openstack.org/essex/openstack-compute/install/yum/content/compute-db-sync.html . But I get an error as follows which is faced by quite a number of users based on the comments. But none of them are resolved. If anyone has any idea what may be the problem, please let me know. Thanks The error is as follows as soon as i run the *db-sync comand *during nova installation. * * *Error* *2012-10-16 11:00:57 DEBUG nova.utils [-] backend module 'nova.db.sqlalchemy.migration' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/migration.pyc' from (pid=15585) __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:659 * *2012-10-16 11:00:57 WARNING nova.utils [-] /usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/pool.py:683: SADeprecationWarning: The 'listeners' argument to Pool (and create_engine()) is deprecated. Use event.listen().* * Pool.__init__(self, creator, **kw)* * * *2012-10-16 11:00:57 WARNING nova.utils [-] /usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/pool.py:159: SADeprecationWarning: Pool.add_listener is deprecated. Use event.listen() * * self.add_listener(l)* -- --With Regards Pavan Kulkarni ___ 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] Error while installing Nova (OpenStack-Essex)
nova-volume by default uses an LVM volume group (VG) named 'nova-volumes' in which it creates volumes via logical volumes. If that VG doesn't exist you'll get that error and volumes won't work. You can run 'vgs' to list your current volume groups. Nate On Oct 16, 2012 3:01 PM, Pavan Kulkarni pavan.babu...@gmail.com wrote: Thanks a lot Nathaneal. I am facing problems starting the nova-volume on RHEL. (log message- volume group nova-volumes doesn't exist) There seems to no proper documentation on resolving this for RHEL. I saw this issue being addressed for Fedora in this linkhttp://forums.openstack.org/viewtopic.php?f=16t=611 But am not sure if I can go ahead and use the same steps in RHEL. Anyone has any idea how to resolve this issue ? Any help is appreciated. Thanks On Tue, Oct 16, 2012 at 11:25 AM, Nathanael Burton nathanael.i.bur...@gmail.com wrote: Pavan, The message is not an error but a warning that a particular python call (Pool.add_listener) is deprecated and will be removed in a future version of the module. Thanks, Nate On Oct 16, 2012 11:20 AM, Pavan Kulkarni pavan.babu...@gmail.com wrote: Hi, I am trying to install Openstack Essex following the instructions from this linkhttp://docs.openstack.org/essex/openstack-compute/install/yum/content/compute-db-sync.html . But I get an error as follows which is faced by quite a number of users based on the comments. But none of them are resolved. If anyone has any idea what may be the problem, please let me know. Thanks The error is as follows as soon as i run the *db-sync comand *during nova installation. * * *Error* *2012-10-16 11:00:57 DEBUG nova.utils [-] backend module 'nova.db.sqlalchemy.migration' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/migration.pyc' from (pid=15585) __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:659 * *2012-10-16 11:00:57 WARNING nova.utils [-] /usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/pool.py:683: SADeprecationWarning: The 'listeners' argument to Pool (and create_engine()) is deprecated. Use event.listen().* * Pool.__init__(self, creator, **kw)* * * *2012-10-16 11:00:57 WARNING nova.utils [-] /usr/lib64/python2.6/site-packages/SQLAlchemy-0.7.8-py2.6-linux-x86_64.egg/sqlalchemy/pool.py:159: SADeprecationWarning: Pool.add_listener is deprecated. Use event.listen() * * self.add_listener(l)* -- --With Regards Pavan Kulkarni ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- --With Regards Pavan Kulkarni ___ 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] When will the distro (specifically Ubuntu) have package for Folsom release
From the release notes: http://wiki.openstack.org/ReleaseNotes/Folsom#Ubuntu_12.04_.2BAC8_Ubuntu_12.10 On Oct 1, 2012 1:17 PM, Matt Joyce matt.jo...@cloudscaling.com wrote: I am not sure indecently was the word you were looking for there. But I gather you are asking if Ubuntu is packaging folsom on their own (as in it's not part of openstack). So yes, Ubuntu is packaging folsom on their own. And I assume ubuntu will let people know when they are done packaging. They tend to be pretty good about that sort of thing. -Matt On Mon, Oct 1, 2012 at 10:02 AM, Ahmed Al-Mehdi ah...@coraid.com wrote: Hello, Does anybody know when will the distress, specifically Ubuntu, have packages for the OpenStack Folsom release. Is this effort done indecently of OpenStack by Ubuntu and the release date will be mentioned on Ubuntu's website? Regards, Ahmed. ___ 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 ___ 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] [nova] Disk attachment consistency
On Aug 13, 2012 11:37 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: The second proposal I have is to use a feature of kvm attach and set the device serial number. We can set it to the same value as the device parameter. This means that a device attached to /dev/vdb may not always be at /dev/vdb (with old kvm guests), but it will at least show up at /dev/disk/by-id/virtio-vdb consistently. What about setting the serial number to the volume_id? At least that way you could be sure it was the volume you meant, especially in the case where vdb in the guest ends up not being what you requested. What about other hypervisors? (review coming soon) First question: should we return this magic path somewhere via the api? It would be pretty easy to have horizon generate it but it might be nice to have it show up. If we do return it, do we mangle the device to always show the consistent one, or do we return it as another parameter? guest_device perhaps? Second question: what should happen if someone specifies /dev/xvda against a kvm cloud or /dev/vda against a xen cloud? I see two options: a) automatically convert it to the right value and return it b) fail with an error message Third question: what do we do if someone specifies a device value to a kvm cloud that we know will not work. For example the vm has /dev/vda and /dev/vdb and they request an attach at /dev/vdf. In this case we know that it will likely show up at /dev/vdc. I see a few options here and none of them are amazing: a) let the attach go through as is. advantages: it will allow scripts to work without having to manually find the next device. disadvantages: the device name will never be correct in the guest b) automatically modify the request to attach at /dev/vdc and return it advantages: the device name will be correct some of the time (kvm guests with newer kernels) disadvantages: sometimes the name is wrong anyway. The user may not expect the device number to change c) fail and say, the next disk must be attached at /dev/vdc: advantages: explicit disadvantages: painful, incompatible, and the place we say to attach may be incorrect anyway (kvm guests with old kernels) The second proposal earlier will at least give us a consistent name to find the volume in all these cases, although b) means we have to check the return value to find out what that consistent location is like we do when we don't pass in a device. I hope everything is clear, but if more explanation is needed please let me know. If anyone has alternative/better proposals please tell me. The last question I think is the most important. Vish ___ 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] Setting Expectations
I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a cloud kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system. However, that doesn't mean OpenStack ignores the user/operator/packager/distro side of things. Where we the developers and operators of OpenStack see areas to make configuration, management, development, documentation of OpenStack easier we strive to incorporate those things back into core. None of the above is meant as criticism, it's simply how I categorize OpenStack in the cloudy landscape. Nate On Aug 10, 2012 5:47 PM, Andrew Clay Shafer a...@parvuscaptus.com wrote: What is OpenStack? Clearly, OpenStack is many things to many people and organizations. What does it mean to contribute to OpenStack? What does it mean to deploy OpenStack? What does it mean to operate OpenStack? What do we mean when we say compatible? interoperable? community? branded? Is OpenStack a framework? a project? a product? Recent discussions make it clear that we have a lot of different ideas about all of these things. Our collective and individual responsibilities to each other are also a point of tension. There is a marked difference in the perspective of those developing the projects, those operating the projects as services and the final consumers/clients of those services. If OpenStack is going to live up to it's full potential and stated mission, I believe there needs to be a much stronger collective conscience about how decisions are made. I feel we will all benefit by making some things more explicit. If the expectation is that OpenStack is a framework, which is a word I've heard people use many times, then does an upgrade path have to exist? The OpenStack dashboard was essentially rewritten to upgrade to a new version of Django. Was there any expectation that Django should upgrade itself for us? Upgrading an application to use a different versions of Rails, another framework, often borders on impossible, particularly if the application happens have some feature with a dependency of a gem that hasn't been kept in sync with the upstream project. Is OpenStack more or less complicated than those frameworks? What responsibility should OpenStack core development have to consider existing deployments? Frameworks are expected be a foundation to build on. By definition, changing foundations is not easy. Clearly, OpenStack can be deployed and operated, but if OpenStack needs to be easier to deploy, operate and upgrade, and that is a responsibility of OpenStack itself, that can't be something that get's tacked on at the end. There is no 'ease of deployment' powder to sprinkle on at the end. Distributions and tooling can and do obscure the difficultly for the downstream user, but that also leads to a lot of potential fragmentation. And is that the right answer? Who can and should answer that? That OpenStack should be easy to deploy and upgrade is somewhat at odds with OpenStack supporting every possible combination of hypervisor, storage and networking option, let alone what the expectation should be with closed source customizations/integrations. Which brings up questions of compatibility. API compatibility is potentially misleading if the semantics and behaviors vary. I've heard several service provider discuss ideas about how they can be differentiated in the market, and many of those ideas lead differences in APIs to expose. Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if your core business is dependent on maintaining integrations with service providers. Taken to an extreme these decisions complicate and call into question any future of federated OpenStack services. I'm not advocating any choice here. I just want to point out there are compromises that have to be made. There are goals and desires for OpenStack that are at odds with each other. Some of that is a function of the perspective of persona, but a lot is also from fundamental differences in understanding about where OpenStack is, where OpenStack needs to be, and how to get there. If there isn't a core guiding conscience about what we are trying to accomplish that gets applied across the board, then I worry that the future of OpenStack ends up with more fragments optimizing for their perspective and inevitable
Re: [Openstack] keystone and ssl ?
Pierre,
In Diablo and Essex it is a common deployment pattern to serve Keystone via
SSL proxy or run Keystone as a mod_wsgi application directly. Running like
this provides connection security between the clients and the Keystone
server.
Adam Young provided a good example of doing this via Apache httpd on a blog
post of his: http://adam.younglogic.com/2012/04/keystone-httpd/
Best,
Nate
On Aug 3, 2012 5:23 AM, Pierre Amadio pierre.ama...@canonical.com wrote:
Hi there !
I have an essex install that works, and am trying now to do the same
thing but with SSL for keystone communication.
I am using Ubuntu 12.04
I followed http://docs.openstack.org/developer/keystone/configuration.html
On a remote box that will serve as my CA, i generated an auto signed
root certificate:
cd /etc/ssl
sudo /usr/lib/ssl/misc/CA.pl -newca
This generated a /etc/ssl/demoCA/cacert.pem file wich i think is to copy
on my keystone node wherever ca_certs in the config file points to. Right ?
So i have stored this file on /etc/ssl/cacert.pem
On my keystone box, i generate a certificate request:
sudo openssl req -nodes -out keystone-req.pem -new -newkey rsa:2048
-keyout cert.key -days 1095
sudo mv cert.key /etc/ssl/
sudo chmod 0600 /etc/ssl/cert.key
I send a copy of kesytone-req.pem on my CA box and sign it:
cd /etc/ssl
sudo openssl ca -policy policy_anything -out keystone-cert.crt -infiles
keystone-req.pem
I copy back the signed keystone-cert.crt file on my keystone box in
/etc/ssl/keystone-cert.crt
I add the following on /etc/keystone/kesytone.conf :
[ssl]
enable = True
certfile = /etc/ssl/keystone-cert.crt
keyfile = /etc/ssl/cert.key
ca_certs = /etc/ssl/cacert.pem
cert_required = True
From there, i was expecting to just have to restart keystone and start
using the keystone client with a https SERVICE_ENDPOINT environment
variable so i could create services, tenants, users and so on.
However, it looks to me like keystone is not even trying to negociate a
ssl handshake:
$ export SERVICE_ENDPOINT=https://192.168.122.3:35357/v2.0/
$ export SERVICE_TOKEN=whatever
$ keystone user-list
No handlers could be found for logger keystoneclient.client
Unable to communicate with identity service: [Errno 1] _ssl.c:504:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol.
(HTTP 400)
From a tcpdump:
#
...Pe...O..4..6wq}...V...
..!.9.8.5... ...
.3.2.E.D./...A..I.
.4.2... ...
...#...head
titleError response/title
/head
body
h1Error response/h1
pError code 400.
pMessage: Bad request syntax
('\x16\x03\x01\x00\xcd\x01\x00\x00\xc9\x03\x02P\x1b\x86\x7f\xaee\x03\xb9\x88O\x9b\xf9\xa6\xff\x85\xea\xe8\xf7\x9e\xe64\x8f\xc86w\xa1\xd7\xb6\xc3q}\x03\x00\x00V\xc0\x14\xc0').
pError code explanation: 400 = Bad request syntax or unsupported method.
/body
##
I do not understand what i am doing wrong, nor am i 100% sure this is
suppose to work yet.
According to the following blue print, i think it should be available in
essex:
https://blueprints.launchpad.net/keystone/+spec/2-way-ssl
At the bottom of the blueprint, there are 2 addressed by links with a
set of patches:
https://review.openstack.org/1038
https://review.openstack.org/7706
But i do not find trace of those patches in the ubuntu package
ii keystone
2012.1+stable~20120608-aff45d6-0ubuntu1 OpenStack identity service -
Daemons
ii python-keystone
2012.1+stable~20120608-aff45d6-0ubuntu1 OpenStack identity service -
Python library
ii python-keystoneclient 2012.1-0ubuntu1
Client libary for Openstack Keystone API
I also fail to find trace of those in a git checkout of the
refs/heads/stable/essex branch of keystone's git repository.
I am confused.
Any help would be appreciated.
___
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] Keystone: 'PKI Signed Tokens' lack support for revocation
Adam, I haven't yet had a chance to review how the new PKI signed tokens is implemented, but what you're describing sounds quite similar to online certificate status protocol (OCSP) but for tokens. Nate On Aug 2, 2012 10:24 PM, Adam Young ayo...@redhat.com wrote: On 08/01/2012 11:05 PM, Maru Newby wrote: Hi Adam, I apologize if my questions were answered before. I wasn't aware that what I perceive as a very serious security concern was openly discussed. The arguments against revocation support, as you've described them, seem to be: - it's complicated/messy/expensive to implement and/or execute - Kerberos doesn't need it, so why would we? I'm not sure why either of these arguments would justify the potential security hole that a lack of revocation represents, but I suppose a 'short enough' token lifespan could minimize that hole. But how short a span are you suggesting as being acceptable? The delay between when a user's access permissions change (whether roles, password or even account deactivation) and when the ticket reflects that change is my concern. The default in Keystone has been 24h, which is clearly too long. Something on the order of 5 minutes would be ideal, but then ticket issuance could become the bottleneck. Validity that's much longer could be a real problem, though. Maybe not at the cloud administration level, but for a given project I can imagine someone being fired and their access being revoked. How long is an acceptable period for that ticket to still be valid? How much damage could be done by someone who should no longer have access to an account if their access cannot be revoked, by anyone, at all? I realize that I had been thinking about the revocation list as something that needs to be broadcast. This is certainly not the case. A much better approach would be for the Keystone server to have a list of revoked tokens exposed in an URL. Then, as service like Glance or Nova can query the Revocation list on a simple schedule. The time out would be configurable, of course. There is a question about what to do if the keystone server cannot be reached during that interval. Since the current behavior is for authentication to fail, I suppose we would continue doing that, but also wait a random amount of time and then requery the Keystone server. In the future, I would like to make the set of Keystone servers a configurable list, and the policy for revocation checking should be able to vary per server: some Keystone servers in a federated approach might not be accessible. In those cases, it might be necessary for one Keystone server to proxy the revocation list for another server. Let me know if this scheme makes sense to you. If so, we can write it up as an additional blueprint. It should not be that hard to implement. I'm hearing that you, as the implementer of this feature, don't consider the lack of revocation to be an issue. What am I missing? Is support for revocation so repugnant that the potential security hole is preferable? I can see that from a developer's perspective, but I don't understand why someone deploying Keystone wouldn't avoid PKI tokens until revocation support became available. Thanks, Maru On 2012-08-01, at 9:47 PM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? It was discussed back when I wrote the Blueprint. While it is possible to do revocations with PKI, it is expensive and requires a lot of extra checking. Revocation is a policy decision, and the assumption is that people that are going to use PKI tokens are comfortable with out revocation. Kerberos service tickets have the same limitation, and Kerberos has been in deployment that way for close to 25 years. Assuming that PKI ticket lifespan is short enough, revocation should not be required. What will be tricky is to balance the needs of long lived tokens (delayed operations, long running operations) against the needs for reasonable token timeout. PKI Token revocation would look like CRLs in the Certificate world. While they are used, they are clunky. Each time a token gets revoked, a blast message would have to go out to all registered parties informing them of the revocation. Keystone does not yet have a message queue interface, so doing that is prohibitive in the first implementation. Note that users can get disabled, and token chaining will no longer work: you won't be able to use a
Re: [Openstack] [Nova] proposal to provide project specific instance type
unicell, I've also wanted the same functionality. I think it's an important feature for private cloud deployments. Thanks, Nate On Jul 28, 2012 1:15 AM, unicell unic...@gmail.com wrote: Hi, In our use case, there is a need to provide project-specific instance type. Meaning that this instance type is only visible and available for several projects. It's an idea kind of like private image concept for Glance project. Has this proposal been discussed before somewhere? Any comments? I'll be willing to fire a blueprint and work on patches if this concept is workable. Thanks! -- unicell ___ 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] Weird nova-network bridging problem with precise/essex
Narayan, Are you doing bonding in conjunction with your bridging + vlans? Or is it just a single interface backing the vlan_interface? Nate On Jul 16, 2012 9:55 PM, Narayan Desai narayan.de...@gmail.com wrote: We're running into what looks like a linux bridging bug, which causes both substantial (20-40%) packet loss, and DNS to fail about that same fraction of the time. We're running essex on precise, with dedicated nova-network servers and VLANManager. On either of our nova-network servers, we see the same behavior. When tracking this down, I found the following, when tcpdump'ing along the path between vm instance and n-net gateway. The packets appear to make it to the nova-network server, and are properly pulled out of dot1q tagging: root@m5-p:~# tcpdump -K -p -i vlan200 -v -vv udp port 53 tcpdump: WARNING: vlan200: no IPv4 address assigned tcpdump: listening on vlan200, link-type EN10MB (Ethernet), capture size 65535 bytes 20:34:02.377711 IP (tos 0x0, ttl 64, id 59761, offset 0, flags [none], proto UDP (17), length 60) 10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:07.377942 IP (tos 0x0, ttl 64, id 59762, offset 0, flags [none], proto UDP (17), length 60)10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378248 IP (tos 0x0, ttl 64, id 59763, offset 0, flags [none], proto UDP (17), length 60)10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378428 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 170)10.0.0.1.domain 10.0.0.3.54937: 52874 q: A? www.google.com. 6/0/0 www.google.com. [1d3h55m19s] CNAME www.l.google.com., www.l.google.com. [1m33s] A 74.125.225.209, www.l.google.com. [1m33s] A 74.125.225.208, www.l.google.com. [1m33s] A 74.125.225.212, www.l.google.com. [1m33s] A 74.125.225.211, www.l.google.com. [1m33s] A 74.125.225.210 (142) But some packets don't make it all of the way to the bridged interface: root@m5-p:~# brctl show bridge name bridge id STP enabled interfaces br200 8000.fa163e18927b no vlan200 root@m5-p:~# tcpdump -K -p -i br200 -v -vv udp port 53 tcpdump: listening on br200, link-type EN10MB (Ethernet), capture size 65535 bytes 20:34:12.378264 IP (tos 0x0, ttl 64, id 59763, offset 0, flags [none], proto UDP (17), length 60) 10.0.0.3.54937 10.0.0.1.domain: 52874+ A? www.google.com. (32) 20:34:12.378424 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 170) 10.0.0.1.domain 10.0.0.3.54937: 52874 q: A? www.google.com. 6/0/0 www.google.com. [1d3h55m19s] CNAME www.l.google.com., www.l.google.com. [1m33s] A 74.125.225.209, www.l.google.com. [1m33s] A 74.125.225.208, www.l.google.com. [1m33s] A 74.125.225.212, www.l.google.com. [1m33s] A 74.125.225.211, www.l.google.com. [1m33s] A 74.125.225.210 (142) I can't find any way that ipfilter could be implicated in this; there aren't deny rules that are hitting. Oddly enough, this seems to cause no loss in icmp traffic, even with ping -f. So far, searching hasn't netted very much. I've found this similar sounding ubuntu bug report, but it looks like no one is working on it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986043 We're at 3.2.0-24, and there is a 3.2.0-25, but it is reported to not fix this issue, and neither are 3.4 kernels. It seems sad to try backrevving to an onieric kernel, but that is on my list for tomorrow. If this is a kernel bug, it will make the precise default kernel unusable for nova-network servers with dot1q (or whatever the appropriate feature interaction is). Does this ring any bells, or is there another course of action I should attempt? thanks in advance for any suggestions. -nld ___ 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] Routing ReST API Calls by URL
Dan, Adam Young was advocating for something like this. I don't know if a consensus was ever reached, but I thought it was a good idea. https://lists.launchpad.net/openstack/msg10864.html Nate On Jul 13, 2012 5:31 PM, Dan Sneddon d...@cloudscaling.com wrote: I am attempting to find a workable solution for the following use case, and would like to get feedback from the community about it. There are some situations when it is required to put a proxy in front of multiple API endpoints and route by URL. This allows for more flexible routing/filtering in load balancers and firewalls, and makes it possible to differentiate between services in unified HTTP logs. In the current OpenStack model a typical API endpoint looks something like this: http(s)://hostname:port/api version/account/container/object In essence, separate services have similar URLs, and are separated by the port number. It is difficult to use a request-header-aware proxy to route to a particular endpoint, since there is no clear differentiation between service URLs if the hostname and port are the same. With standard HTTP, this can be handled by using several different hostnames pointing to the same IP. This is particularly a problem with SSL certificates, which need to match the hostname. If the URLs contained a service identifier at the beginning of the URL, this would allow a proxy to make decisions about where to route requests based on the beginning of the URL, for example the URL above would become: http(s)://hostname:port/service/api version/account/container/object e.g. https://api-host:443/compute/v2.0/... https://api-host:443/auth/v2.0/... etc. It seems that the API services are compatible with this through the use of the urlmap configuration by including both versions of the URL: [composite:osapi_compute] use = call:nova.api.openstack.urlmap:urlmap_factory /: oscomputeversions /v1.1: openstack_compute_api_v2 /v2: openstack_compute_api_v2 /compute/: oscomputeversions /compute/v1.1: openstack_compute_api_v2 /compute/v2: openstack_compute_api_v2 Is allowing both forms of this URL in all services likely to break anything down the line? Does this seem like a common enough use case that it should be considered as an addition to the default configuration? Also, as services change (such as nova-volume being replaced by cinder) is there a set of generic service descriptors defined that can be used to abstract from the particular name of the service? Some of these are obvious, like network, but it would be nice to be consistent across versions and instances. Thank you for your feedback, -- Dan Sneddon Senior Engineer, Cloudscaling d...@cloudscaling.com - @dxs on Twitter ___ 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] Nova Cells
That's a good question. I'm also interested in an update on cells. How is progress on cells going? Is there a blueprint for it? Is it targeted to a folsom milestone? Thanks, Nate On Thu, Jul 12, 2012 at 1:39 PM, Michael J Fork mjf...@us.ibm.com wrote: Outside of the Etherpad (http://etherpad.openstack.org/FolsomComputeCells) and presentation referenced there (http://comstud.com/FolsomCells.pdf), are there additional details available on the architecture / implementation of Cells? Thanks. Michael - Michael Fork Cloud Architect, Emerging Solutions IBM Systems Technology Group ___ 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] nova-network can't start
William, Are you running on RHEL or CentOS by chance? See this: https://lists.launchpad.net/openstack/msg02565.html Thanks, Nate On Jul 5, 2012 9:47 AM, William Herry william.herry.ch...@gmail.com wrote: the error log is here: File /usr/lib/python2.6/site-packages/nova-2012.2-py2.6.egg/nova/network/linux_net.py, line 816, in _execute 2012-07-05 06:16:43 TRACE nova return utils.execute(*cmd, **kwargs) 2012-07-05 06:16:43 TRACE nova File /usr/lib/python2.6/site-packages/nova-2012.2-py2.6.egg/nova/utils.py, line 188, in execute 2012-07-05 06:16:43 TRACE nova result = obj.communicate() 2012-07-05 06:16:43 TRACE nova File /usr/lib64/python2.6/subprocess.py, line 729, in communicate 2012-07-05 06:16:43 TRACE nova stdout, stderr = self._communicate(input, endtime) 2012-07-05 06:16:43 TRACE nova File /usr/lib64/python2.6/subprocess.py, line 1330, in _communicate 2012-07-05 06:16:43 TRACE nova self.wait(timeout=self._remaining_time(endtime)) 2012-07-05 06:16:43 TRACE nova TypeError: wait() got an unexpected keyword argument 'timeout' no much result with google, some one help Regards -- William Herry williamherrych...@gmail.com ___ 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] Managing projects roles and quotas (Dashboard -vs- nova-manage)
Jon, When manipulating quotas via 'nova-manage project quota' ensure that you are using the tenant_id and not the name. nova-manage will silently accept the project/tenant name instead of the tenant_id. Thanks, Nate On Jul 5, 2012 10:48 PM, Jonathan Proulx j...@jonproulx.com wrote: Hi All, I have a new Essex install on Ubuntu 12.04 and just starting to kick the tires. I would like to manage resource quotas for different projects/tenants but having created them in Dashboard nova-manage doesn't see them, though keystone does and I can join users to tenants with roles using keystone user-role-add. The documentation here http://docs.openstack.org/developer/nova/runnova/managing.projects.html#setting-quotas says to manage projects roles and quotas using 'nova-manage'. Should I avoid the webUI and keystone and use nova-manage for this or is there a different way to manage quotas I'm missing? Thanks, -Jon ___ 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 G naming poll
+1 for Grizzly On Jul 3, 2012 8:02 PM, Brian Waldon brian.wal...@rackspace.com wrote: TL;DR - Screw the rules, let's call the next release 'Grizzly' As California is rather lacking in the 'municipality names starting with a G that we should use for an OpenStack release' department, I have had to look *slightly* outside the ruleset to find a suitable 'G' release name - that name being 'Grizzly'. The rules clearly state that a release name must represent a city or county near the corresponding design summit and be comprised of a single word of ten characters or less - the problem here being that 'Grizzly' is actually 'Grizzly Flats.' Having already polled a small subset of the community, I feel like there would be enough support for 'Grizzly' to win if it were on the ballot. As I'm more interested in selecting a suitable name than accurately representing some arbitrary territory, I'd love to either permanently amend the rules to make this acceptable or grant an exception in this one case. As Thierry said, if this reaches critical mass, we will figure out what to do. Otherwise, I'll shut up and deal with '*Gazelle*'. Brian On Jul 3, 2012, at 3:20 PM, Thierry Carrez wrote: Yes, it's that time of the year again... time for us to choose the name of the next OpenStack release ! This time, cities and counties in California (San Diego, CA being the location of the G design summit) I set up a poll with the available options (based on our current rules of naming) at: https://launchpad.net/~openstack/+poll/g-release-naming Poll is accessible to all members of ~openstack group in Launchpad, and ends next Tuesday, 21:30 UTC. Please cast your vote! I'm aware that a subversive movement wants to try to amend the rules so that another name option becomes available. Since we can't stop (or modify) the poll now that it's been launched, if that movement reaches critical mass, we may organize a second round of polling :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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 ___ 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] multi_host not working
This is actually what multi_host should be doing when enabled. What node is that original gateway address from? Is that a different compute node? Nate On Mon, Jul 2, 2012 at 8:41 AM, Marnus van Niekerk m...@mjvn.net wrote: I have managed to get this working by changing the default gateway on the guest to the compute node it is running on. ubuntu@monitor:~$ sudo route del default gw 10.10.11.129 ubuntu@monitor:~$ sudo route add default gw 10.10.11.112 But the default gateway is assigned by DHCP - so how can I change the default gateway that nova-network assigns on each compute node? Tx M On 02/07/2012 13:50, Marnus van Niekerk wrote: Hi. I am trying to use multi_host to eliminate the controller hosts as a single point of failure. I followed the steps at http://docs.openstack.org/essex/openstack-compute/admin/content/existing-ha-networking-options.html and added thse options to the end of nova.conf. Now the guests have no connectivity to the outside world at all. (Running on ubuntu 12.04 using packages.) Controller: --multi_host=True --enabled_apis=ec2,osapi_compute,osapi_volume,metadata Compute nodes: --multi_host=True --enabled_apis=metadata I also tried changing the routing_source_ip option on each compute node to it's own ip address but it makes no difference. --routing_source_ip=10.10.20.11X What am I missing? Tx Marnus van Niekerk ___ 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] multi_host not working
Are the nova.conf files identical across all the nodes? On Jul 2, 2012 10:47 AM, Marnus van Niekerk m...@mjvn.net wrote: On 02/07/2012 16:14, Nathanael Burton wrote: This is actually what multi_host should be doing when enabled. What node is that original gateway address from? Is that a different compute node? Yes, its is the br100 ip of the controller node which is also a compute node. M ___ 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] How do I stop image-create from using /tmp?
I agree with Daniel for the qemu-img commands. For other temp file usage, I know on Fedora/RHEL there's already /var/lib/nova/tmp which is used for lock files, etc. Nate On Jul 2, 2012 4:29 PM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Jul 02, 2012 at 10:24:02AM -0700, Matt Joyce wrote: I like the idea of making this a flagfile option. In the particular case of the qemu-img command described in earlier in this thread, I'm not convinced we need a new option. Instead of using /tmp when extracting a snapshot from an existing disk image, it could just use the path where the source image already resides. ie the existing FLAGS.instances_path directory, which can be assumed to be a suitably large persistent data store. Other uses of temporary files should be analysed ona case by case basis to figure out a suitable storage location. This might perhaps identify a need for a generic temp file location for nova, such as /var/run/nova/ or /var/cache/nova or both (depending on use case). Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| ___ 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] When are hostnames okay and when are ip addresses required?
While at a minimum this is a doc bug, I would suggest we do one of the following: 1. Rename existing parameters that require the value to be an ip address such as 'metadata_host' to 'metadata_host_ip' so that it is more obvious. Make this a standard for all config parameters. 2. I agree with Lars, it would be even better if it was seamless (regardless of what was set, host or IP) and where we require IP addresses, do resolution. Nate On Jun 28, 2012 7:55 PM, Matt Joyce matt.jo...@cloudscaling.com wrote: +1 On Thu, Jun 28, 2012 at 2:27 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: those are supposed to be ip addresses, so I would go with doc bug now unless there is a good reason to change it. Vish On Jun 28, 2012, at 12:00 PM, Lars Kellogg-Stedman wrote: Maybe I sent this out too late at night; I think it slipped below everyone's radar. I'm interested in whether or not people think this behavior is a functional bug, or maybe just a documentation bug: I ran into an issue earlier today where I had metadata_host set to the *hostname* of our controller. This got stuffed into an iptables rule as... -d os-controller.int.seas.harvard.edu/32 ...which promptly failed. Setting this to an ip address fixed this particular error, leading me to wonder: - Is this expected behavior? - Should I always use ip addresses for *_host values? - Is this a bug? - Should linux_net.py resolve hostnames? -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist| http://ac.seas.harvard.edu/ Academic Computing | http://code.seas.harvard.edu/ Harvard School of Engineering and Applied Sciences | ___ 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 ___ 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] HVM + Xen Hypervisor via libvirt possible?
Seems like an attribute that could be added to instance types / flavors that could be passed on to the scheduler and virt layers. Nate On Jun 21, 2012 2:12 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jun 22, 2012 at 12:17:11AM +0800, Huang Zhiteng wrote: Of course it is possible. What kind of issue did you run into? On Thu, Jun 21, 2012 at 5:52 PM, Wang Li fox...@gmail.com wrote: hi,all I need to run virtual machines on Xen Hypervisor in HVM mode, is it possible when using libvirt? Actually, this is not currently possible. For reasons I don't know, the libvirt driver currently hardcodes use of paravirtualized guests when connected to Xen hosts. It does not allow use of HVM guests. There's no particularly good technical reason why it can't be made to work. There'd need to be a way to tag instance types with HVM vs paravirt, in addition to their architecture. The libvirt driver would have to expose whether each host supports paravirt or HVM or both. The schedular would then have to take this into account when placing guests. Until this is done, if you really need to run HVM guests, then you'll have to use KVM instead of Xen. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| ___ 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] glance_api_servers vs. glance_host vs. keystone?
What's the point of a service catalog (list of endpoints) if we don't want to use it?! Looking up endpoints should be a cacheable request and in the grand scheme of things -- low impact. Nate On Jun 18, 2012 10:13 AM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2012-06-15 at 20:54 -0400, Lars Kellogg-Stedman wrote: Thanks for the reply, makes sense. Just to make sure I understand things, it sounds like Nova does not currently query Keystone for endpoints and continues to rely on explicit configuration (or to rephrase your answer, the reason these options have not gone away is because Nova does not yet have the necessary support for Keystone). Is that approximately correct? The problem with the Keystone endpoints is that you have to make a query to Keystone to get them. We want to reduce the number of hits we make on Keystone, not increase them—there are already too many as it is. Thus, I suspect that nova may not even use the Keystone endpoints. It *does* support image URLs, however. Thus, you use the options to configure the default glance endpoint, and if you want to hit another glance, you simply give a URL to the desired image rather than a simple identifier. (My comments about the support for endpoints in this email may differ from my previous comments; chalk that up to further reflection on the problem being solved…) -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ 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] instances loosing IP address while running, due to No DHCPOFFER
Has nova-network been restarted? There was an issue where nova-network was signalling dnsmasq which would cause dnsmasq to stop responding to requests yet appear to be running fine. You can see if killing dnsmasq, restarting nova-network, and rebooting an instance allows it to get a dhcp address again ... Nate On Jun 14, 2012 4:46 PM, Christian Parpart tra...@gmail.com wrote: Hey all, I feel really sad with saying this, now, that we have quite a few instances in producgtion since about 5 days at least, I now have encountered the second instance loosing its IP address due to No DHCPOFFER (as of syslog in the instance). I checked the logs in the central nova-network and gateway node and found dnsmasq still to reply on requests from all the other instances and it even got the request from the instance in question and even sent an OFFER, as of what I can tell by now (i'm investigating / posting logs asap), but while it seemed that the dnsmasq sends an offer, the instances says it didn't receive one - wtf? Please tell me what I can do to actually *fix* this issue, since this is by far very fatal. One chance I'd see (as a workaround) is, to let created instanced retrieve its IP via dhcp, but then reconfigure /etc/network/instances to continue with static networking setup. However, I'd just like the dhcp thingy to get fixed. I'm very open to any kind of helping comments, :) So long, Christian. ___ 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] instances loosing IP address while running, due to No DHCPOFFER
There's a flag 'dhcp_lease_time' (in secs) that can be set in nova.conf. DHCP clients typically re-up every (dhcp_lease_time/2) seconds, but this varies based on client. Additionally some dhcp clients are not persistent, meaning if there's ever a network hiccup and they don't get a dhcp ACK they will give up and stop checking in, thus losing their lease and fall off the network. On RHEL/CentOS/Fedora this is fixed by setting PERSISTENT_DHCLIENT=1 in your ifcfg-eth0 file. Not sure about Ubuntu. Nate On Jun 14, 2012 7:02 PM, Christian Parpart tra...@gmail.com wrote: Hey, thanks for your reply. Unfortunately there was no process restart in nova-network nor in dnsmasq, both processes seem to have been up for about 2 and 3 days. However, why is the default dhcp_lease_time value equal 120s? Not having this one overridden causes the clients to actually re-acquire a new DHCP lease every 42 seconds (at least on my nodes), which is completely ridiculous. OTOH, I took a look at the sources (linux_net.py) and found out, why the max_lease_time is set to 2048, because that is the size of my network. So why is the max lease time the size of my network? I've written a tiny patch to allow overriding this value in nova.conf, and will submit it to launchpad soon - and hope it'll be accepted and then also applied to essex, since this is a very straight forward few-liner helpful thing. Nevertheless, that does not clarify on why now I had 2 (well, 3 actually) instances getting no DHCP replies/offers after some hours/days anymore. The one host that caused issues today (a few hours ago), I fixed it by hard rebooting the instance, however, just about 40 minutes later, it again forgot its IP, so one might say, that it maybe did not get any reply from the dhcp server (dnsmasq) almost right after it got a lease on instance boot. So long, Christian. On Thu, Jun 14, 2012 at 10:55 PM, Nathanael Burton nathanael.i.bur...@gmail.com wrote: Has nova-network been restarted? There was an issue where nova-network was signalling dnsmasq which would cause dnsmasq to stop responding to requests yet appear to be running fine. You can see if killing dnsmasq, restarting nova-network, and rebooting an instance allows it to get a dhcp address again ... Nate On Jun 14, 2012 4:46 PM, Christian Parpart tra...@gmail.com wrote: Hey all, I feel really sad with saying this, now, that we have quite a few instances in producgtion since about 5 days at least, I now have encountered the second instance loosing its IP address due to No DHCPOFFER (as of syslog in the instance). I checked the logs in the central nova-network and gateway node and found dnsmasq still to reply on requests from all the other instances and it even got the request from the instance in question and even sent an OFFER, as of what I can tell by now (i'm investigating / posting logs asap), but while it seemed that the dnsmasq sends an offer, the instances says it didn't receive one - wtf? Please tell me what I can do to actually *fix* this issue, since this is by far very fatal. One chance I'd see (as a workaround) is, to let created instanced retrieve its IP via dhcp, but then reconfigure /etc/network/instances to continue with static networking setup. However, I'd just like the dhcp thingy to get fixed. I'm very open to any kind of helping comments, :) So long, Christian. ___ 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] instances loosing IP address while running, due to No DHCPOFFER
FWIW I haven't run across the dnsmasq bug in our environment using EPEL packages. Nate On Jun 14, 2012 7:20 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Are you running in VLAN mode? If so, you probably need to update to a new version of dnsmasq. See this message for reference: http://osdir.com/ml/openstack-cloud-computing/2012-05/msg00785.html Vish On Jun 14, 2012, at 1:41 PM, Christian Parpart wrote: Hey all, I feel really sad with saying this, now, that we have quite a few instances in producgtion since about 5 days at least, I now have encountered the second instance loosing its IP address due to No DHCPOFFER (as of syslog in the instance). I checked the logs in the central nova-network and gateway node and found dnsmasq still to reply on requests from all the other instances and it even got the request from the instance in question and even sent an OFFER, as of what I can tell by now (i'm investigating / posting logs asap), but while it seemed that the dnsmasq sends an offer, the instances says it didn't receive one - wtf? Please tell me what I can do to actually *fix* this issue, since this is by far very fatal. One chance I'd see (as a workaround) is, to let created instanced retrieve its IP via dhcp, but then reconfigure /etc/network/instances to continue with static networking setup. However, I'd just like the dhcp thingy to get fixed. I'm very open to any kind of helping comments, :) So long, Christian. ___ 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 ___ 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] how to set individual gateway for each VLAN or Tenant network?
Lorin, Diego, I wrote up a pastebin of setting up an example dnsmasq.conf file, setting it within nova.conf, patching linux_net.py (in stable/essex), and showing the example dhcp leases file which set custom values for the router, ntp-server, and dns-server using the dnsmasq conf and tags based on the network label field within the network defined within nova. The same process should work with both FlatDHCP or VLANManager. http://paste.openstack.org/show/18471/ Thanks, Nate On Mon, Jun 11, 2012 at 10:17 PM, Lorin Hochstein lo...@nimbisservices.com wrote: Hey Nate: On Jun 11, 2012, at 2:17 PM, Nathanael Burton wrote: dnsmasq supports setting parameters such as the gateway IP and other settings based on tag. I have run a patched version of nova-network in the Diablo time that used the network DB label field as the network tag in dnsmasq. This then allows you to set custom configs by modifying the dnsmasq.conf file. This was done with VLANmanager. Are you able to share an exampleof a dnsmasq.conf file that uses tags to handle different config settings per network/VLAN? Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com Thanks Nate On Jun 11, 2012 2:09 PM, Lorin Hochstein lo...@nimbisservices.com wrote: On Jun 4, 2012, at 8:22 PM, romi zhang wrote: Hi, I am using VLAN network mode and will connect eth1 and eth2 of my compute node to the LAN Switch, and LAN switch will create individual VLAN IP interface for each Tenant/VLAN and then route to the NAT equipment,through SNAT/DNAT to touch internet. So, that needs I can set the default gateway of each Tenant VLAN to the different IP address of VLAN interface on the switch. I have the same question, I would love to know if you can set the gateways in VLAN mode. For example, my first tenant(auto0Tenant) is at VLAN200/br200/eth1/fix_ip range is 192.168.2.0/28 and second(aotu1Tenant) is VLAN300/br300/eth2/fix_ip_range 192.168.3.0/28, the VLAN interface ip address for them on switch is 192.168.2.9 and 192.168.3.9, I want to set the default gateway of VMs in auto0Tenant to 192.168.2.9 and 192.168.3.9 for aotu1Tenant’s VMs. I try to use two methods, the first is to use nova-command: nova-manage network create --label=auto0Tenat --fixed_range_v4=192.168.2.0/28 --num_networks=1 --gateway=192.168.2.9 --dns1=61.139.2.69 --vlan=200 --bridge=br200 --bridge_interface=eth1 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c nova-manage network create --label=aotu1Tenant --fixed_range_v4=192.168.3.0/28 --num_networks=1 --gateway=192.168.3.9 --dns1=61.139.2.69 --vlan=300 --bridge=br300 --bridge_interface=eth2 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c but the result is the newest created VM default gateway is still the IP address of br200 or br300 by the system, that means the factor of “gateway” and “dns1” in nova-mange network command did not work. The second way is to use dnsmasq.conf that Vish told me, that I set just dhcp_option=3,192.168.2.9. Yes it is useful for auto0Tenat VLAN, it can set auto0Tenant gateway to 192.168.2.9, but how to set others at the same time? Then I tried to use: Interface=vlan200 dhcp_option=3,192.168.2.9 Interface=vlan300 dhcp_option=3,192.168.3.9 Does it actually work to specify multiple interfaces in the dnsmasq conf file like that? I would have thought that the second values would override the first ones. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ 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] how to set individual gateway for each VLAN or Tenant network?
It would probably be a good idea to get the patch made to master for using dnsmasq tags to customize the dhcp server configuration. Maybe I'll submit a patch in my down time. Thanks, Nate On Jun 12, 2012 12:03 PM, Lorin Hochstein lo...@nimbisservices.com wrote: Cool, thanks. I'll try to get this into the docs. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On Jun 12, 2012, at 11:10 AM, Nathanael Burton wrote: Lorin, Diego, I wrote up a pastebin of setting up an example dnsmasq.conf file, setting it within nova.conf, patching linux_net.py (in stable/essex), and showing the example dhcp leases file which set custom values for the router, ntp-server, and dns-server using the dnsmasq conf and tags based on the network label field within the network defined within nova. The same process should work with both FlatDHCP or VLANManager. http://paste.openstack.org/show/18471/ Thanks, Nate On Mon, Jun 11, 2012 at 10:17 PM, Lorin Hochstein lo...@nimbisservices.com wrote: Hey Nate: On Jun 11, 2012, at 2:17 PM, Nathanael Burton wrote: dnsmasq supports setting parameters such as the gateway IP and other settings based on tag. I have run a patched version of nova-network in the Diablo time that used the network DB label field as the network tag in dnsmasq. This then allows you to set custom configs by modifying the dnsmasq.conf file. This was done with VLANmanager. Are you able to share an exampleof a dnsmasq.conf file that uses tags to handle different config settings per network/VLAN? Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com Thanks Nate On Jun 11, 2012 2:09 PM, Lorin Hochstein lo...@nimbisservices.com wrote: On Jun 4, 2012, at 8:22 PM, romi zhang wrote: Hi, I am using VLAN network mode and will connect eth1 and eth2 of my compute node to the LAN Switch, and LAN switch will create individual VLAN IP interface for each Tenant/VLAN and then route to the NAT equipment,through SNAT/DNAT to touch internet. So, that needs I can set the default gateway of each Tenant VLAN to the different IP address of VLAN interface on the switch. I have the same question, I would love to know if you can set the gateways in VLAN mode. For example, my first tenant(auto0Tenant) is at VLAN200/br200/eth1/fix_ip range is 192.168.2.0/28 and second(aotu1Tenant) is VLAN300/br300/eth2/fix_ip_range 192.168.3.0/28, the VLAN interface ip address for them on switch is 192.168.2.9 and 192.168.3.9, I want to set the default gateway of VMs in auto0Tenant to 192.168.2.9 and 192.168.3.9 for aotu1Tenant’s VMs. I try to use two methods, the first is to use nova-command: nova-manage network create --label=auto0Tenat --fixed_range_v4=192.168.2.0/28 --num_networks=1 --gateway=192.168.2.9 --dns1=61.139.2.69 --vlan=200 --bridge=br200 --bridge_interface=eth1 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c nova-manage network create --label=aotu1Tenant --fixed_range_v4=192.168.3.0/28 --num_networks=1 --gateway=192.168.3.9 --dns1=61.139.2.69 --vlan=300 --bridge=br300 --bridge_interface=eth2 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c but the result is the newest created VM default gateway is still the IP address of br200 or br300 by the system, that means the factor of “gateway” and “dns1” in nova-mange network command did not work. The second way is to use dnsmasq.conf that Vish told me, that I set just dhcp_option=3,192.168.2.9. Yes it is useful for auto0Tenat VLAN, it can set auto0Tenant gateway to 192.168.2.9, but how to set others at the same time? Then I tried to use: Interface=vlan200 dhcp_option=3,192.168.2.9 Interface=vlan300 dhcp_option=3,192.168.3.9 Does it actually work to specify multiple interfaces in the dnsmasq conf file like that? I would have thought that the second values would override the first ones. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ 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] how to set individual gateway for each VLAN or Tenant network?
dnsmasq supports setting parameters such as the gateway IP and other settings based on tag. I have run a patched version of nova-network in the Diablo time that used the network DB label field as the network tag in dnsmasq. This then allows you to set custom configs by modifying the dnsmasq.conf file. This was done with VLANmanager. Thanks Nate On Jun 11, 2012 2:09 PM, Lorin Hochstein lo...@nimbisservices.com wrote: On Jun 4, 2012, at 8:22 PM, romi zhang wrote: Hi, ** ** I am using VLAN network mode and will connect eth1 and eth2 of my compute node to the LAN Switch, and LAN switch will create individual VLAN IP interface for each Tenant/VLAN and then route to the NAT equipment,through SNAT/DNAT to touch internet. So, that needs I can set the default gateway of each Tenant VLAN to the different IP address of VLAN interface on the switch. I have the same question, I would love to know if you can set the gateways in VLAN mode. ** ** For example, my first tenant(auto0Tenant) is at VLAN200/br200/eth1/fix_ip range is 192.168.2.0/28 and second(aotu1Tenant) is VLAN300/br300/eth2/fix_ip_range 192.168.3.0/28, the VLAN interface ip address for them on switch is 192.168.2.9 and 192.168.3.9, I want to set the default gateway of VMs in auto0Tenant to 192.168.2.9 and 192.168.3.9 for aotu1Tenant’s VMs. ** ** I try to use two methods, the first is to use nova-command: ** ** nova-manage network create --label=auto0Tenat --fixed_range_v4= 192.168.2.0/28 --num_networks=1 --gateway=192.168.2.9 --dns1=61.139.2.69 --vlan=200 --bridge=br200 --bridge_interface=eth1 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c ** ** nova-manage network create --label=aotu1Tenant --fixed_range_v4= 192.168.3.0/28 --num_networks=1 --gateway=192.168.3.9 --dns1=61.139.2.69 --vlan=300 --bridge=br300 --bridge_interface=eth2 --network_size=16 --multi_host=T --project_id=5f9281bca6854fe3974a457d81afd78c ** ** but the result is the newest created VM default gateway is still the IP address of br200 or br300 by the system, that means the factor of “gateway” and “dns1” in nova-mange network command did not work. ** ** The second way is to use dnsmasq.conf that Vish told me, that I set just dhcp_option=3,192.168.2.9. Yes it is useful for auto0Tenat VLAN, it can set auto0Tenant gateway to 192.168.2.9, but how to set others at the same time? ** ** Then I tried to use: ** ** Interface=vlan200 dhcp_option=3,192.168.2.9 ** ** Interface=vlan300 dhcp_option=3,192.168.3.9 ** ** Does it actually work to specify multiple interfaces in the dnsmasq conf file like that? I would have thought that the second values would override the first ones. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ 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] nova-api error on centos (devstack installation)
Verify the permissions on all the files in /etc/nova including api-paste.ini. I've seen errors like that when nova can't read the conf file due to permissions. Nate On May 22, 2012 5:42 AM, Mauch, Viktor (SCC) ma...@kit.edu wrote: Hello together, In the last days a played with multi-node installation of devstack: http://devstack.org/guides/multinode-lab.html However I tried to use CentOS 6.2 machines for Computes Nodes and a normal Ubuntu 12.04 for Head Node. On the compute nodes I want to run n-cpu (nova-compute) and n-net (nova-network). However after the stack.sh run there are still missing some API modules if I try to run nova-manage. If I try to install n-cpu, n-net AND n-api, the stack.sh script will crash because of the nova-api service with the following message: CRITICAL nova [-] Could not load paste app 'ec2' from /etc/nova/api-paste.ini TRACE nova Traceback (most recent call last): TRACE nova File /usr/bin/nova-api, line 51, in module TRACE nova servers.append(service.WSGIService(api)) TRACE nova File /usr/lib/python2.6/site-packages/nova/service.py, line 326, in __init__ TRACE nova self.app = self.loader.load_app(name) TRACE nova File /usr/lib/python2.6/site-packages/nova/wsgi.py, line 391, in load_app TRACE nova raise exception.PasteAppNotFound(name=name, path=self.config_path) TRACE nova PasteAppNotFound: Could not load paste app 'ec2' from /etc/nova/api-paste.ini Does anybody have an idea, what is going wrong? Cheers Viktor ___ 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] nova-manage network create does not create the bridges/vlans immediately
On May 16, 2012 9:47 PM, Omar Lara o...@scasoftware.net wrote: Hi, i am trying to deploy a VlanManager networking model in Essex, i am not using Quantum, and my problem is when i try to do: nova-manage network create --label vlan1 --fixed_range_v4 10.0.1.0/24--num_networks 1 --network_size 256 --vlan 1 --project_id 2e744c1a2032ccb1a0cdf7c5f825d046 The bridge and the vlan are not created immediately, do you have any idea if there is another daemon that needs to run or something so or some additional advice, my nova-network is a server different from the nova-compute. Also i noticed that the ensure_bridge method from linux_net.py never is called, in this script there is the brctl addbr call to posix. root@devlabnova:~# nova-manage network list id IPv4 IPv6 start address DNS1 DNS2 VlanID projectuuid 20 10.0.1.0/24 None 10.0.1.3 None None 1 2e744c1a2032ccb1a0cdf7c5f825d046 a667af77-8ffe-42f8-a094-c2ce71d59171 root@devlabnova:~# brctl show bridge namebridge idSTP enabledinterfaces My nova.conf is as follows in terms of nova-network # nova-network # network_manager=nova.network.manager.VlanManager public_interface=eth0 vlan_interface=eth1 network_host=devlabnova fixed_range=10.0.0.0/8 network_size=1024 dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge force_dhcp_release=True fixed_ip_disassociate_timeout=30 my_ip=172.16.16.10 Thanks in advance! -- - Omar Lara CEO ScaSoftware t: +52(55) 84.21.84.43 Twitter: @elchito http://www.scasoftware.net - ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Omar, The vlan tagged interfaces and bridges are created on the fly as needed as users within the relevant projects start instances that are scheduled to the relevant compute nodes. Nate ___ 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] db notification support for API extension?
On Thu, Mar 8, 2012 at 11:53 AM, Andrew Bogott abog...@wikimedia.org wrote: I'm working on an API and implementation to support the creation of filesystems that are shared among Nova instances. http://wiki.openstack.org/SharedFS My hope is to keep this API isolated from core Nova code, partly to avoid stepping on toes and partly because I hope to be able to drop it into an existing essex install. There are two things I need which I know how to do within Nova but am not clear on how to do without modding Nova code: 1) DB support I need a database table to keep track of some filesystem metadata. My current implementation adds the table via nova/db/sqlalchemy/migrate_repo... but is it really necessary to coordinate this table with the rest of Nova? Would it be reasonable to maintain the table independently within the extension code? And, if so, are there any existing extensions that do something like this? Have you determined a cleaner way of doing this? I have the same issues as you when writing API extensions. Nate ___ 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] db notification support for API extension?
On Wed, Apr 25, 2012 at 6:04 PM, Andrew Bogott abog...@wikimedia.org wrote: Nate -- The short answer is: I'm sure that it's straightforward to create a 'private' table which doesn't collide with existing nova tables, but I have yet to do so. The longer answer is: Everything about that thread is now rolled into the topic of 'the plugin framework' which we discussed at the design summit and which I'm currently devoted to. Please consider adding your use cases to the wiki page at http://wiki.openstack.org/novaplugin, and let me know if you would like me to add you to the list of people I cc: when looking for opinions and/or reporting progress. -Andrew Wish I would have made it to that session, but that sounds exactly like what I'm looking for. I'll follow and contribute ideas as necessary. 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
Re: [Openstack] nova-network service stuck
Check in Nova's lock dir, on my system it's /var/lib/nova/tmp. Remove any files in there and restart the services. Nate On Apr 14, 2012 8:56 PM, Salman Malik salma...@live.com wrote: Hi All, I am having problem with getting nova-service to work. The last line that is shown on the screen is: 2012-04-14 19:42:39 DEBUG nova.utils [-] Attempting to grab file lock iptables for method apply... from (pid=3649) inner /opt/stack/nova/nova/utils.py:936 and the service is stuck at this point. So when I do a nova-manage service list, network service turns out to be unhappy. I haven't found much help on how to 'unlock' iptables file. Thoughts please ? Salman ___ 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] nova-network service stuck
Salman, The location for the locks is determined by the --lock_path setting in nova.conf. This is apparently set to the base path where the nova python code lives ($pybasedir) in devstack: 2012-04-14 21:35:42 DEBUG nova.service [-] lock_path : /opt/stack/nova from (pid=3700) wait /opt/stack/nova/nova/service.py:442 Since, that directory has a bunch of important files in it, certainly don't follow my previous advice and remove all the files in that directory. There is a bug (https://bugs.launchpad.net/nova/+bug/785955) about nova not cleaning up locks that should have been fixed in essex-4. As part of the fix to that Mike Pittaro wrote a cleanup locks script that should be in /opt/stack/nova/tools/clean_file_locks.py. Try running that and let us know if that fixed it. If not look for *.lock files in /opt/stack/nova Thanks, Nate On Sat, Apr 14, 2012 at 9:07 PM, Salman Malik salma...@live.com wrote: Thanks Nate for the quick reply. There is no such directory on the system (I am using devstack if that helps...) Thanks, Salman Date: Sat, 14 Apr 2012 21:00:39 -0400 Subject: Re: [Openstack] nova-network service stuck From: nathanael.i.bur...@gmail.com To: salma...@live.com CC: openstack@lists.launchpad.net Check in Nova's lock dir, on my system it's /var/lib/nova/tmp. Remove any files in there and restart the services. Nate On Apr 14, 2012 8:56 PM, Salman Malik salma...@live.com wrote: Hi All, I am having problem with getting nova-service to work. The last line that is shown on the screen is: 2012-04-14 19:42:39 DEBUG nova.utils [-] Attempting to grab file lock iptables for method apply... from (pid=3649) inner /opt/stack/nova/nova/utils.py:936 and the service is stuck at this point. So when I do a nova-manage service list, network service turns out to be unhappy. I haven't found much help on how to 'unlock' iptables file. Thoughts please ? Salman ___ 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] Agreeing a common set of Image Properties
Better yet why not add support in Glance for automatically determining those things (distro, versions, etc)[1]. That way you don't have to rely on people doing the right thing. Nate References: [1] - http://libguestfs.org/virt-inspector.1.html#getting_inspection_data_from_the_libguestfs_api On Apr 7, 2012 8:19 PM, Justin Santa Barbara jus...@fathomdb.com wrote: I'm talking here about publicly accessible attributes of images, that the image owner would set, so that API callers could select the right image with which to launch their instances. e.g. I'm trying to launch a Zookeeper cluster made up of 5 instances on 5 different clouds; how can I figure out which image is Debian Squeeze on each of ATT, Rackspace, HP, IBM, Internap, Dreamhost etc. I could code image ids or logic for each of the clouds, but that's already annoying with a handful of clouds and impractical with 100. Now imagine also that the images are being re-spun each week! There's no protection against the image uploader setting the wrong values, so the API user would definitely only want images from trusted providers. Is there an easy way to differentiate publicly shared images from 'official' cloud images? I don't believe these attributes would be suitable for billing purposes. You could make it so that certain attributes can't be changed by the user (e.g. billing codes), or that some values are system assigned (e.g. this is an official image), but I think that's a future conversation / future Glance feature. I'm just thinking this set of attributes would be a win for everyone vs. each cloud rolling their own, so we can just agree them without any need for code! Justin On Sat, Apr 7, 2012 at 3:43 PM, Jamey Meredith jamey.mered...@rackspace.com wrote: So would these accessible via a system admin API only? The problem we face as a Public cloud is that we need to know things about an image for billing purposes. If a user can snapshot one of my windows images and change the distro field to Debian to avoid license fees, that wont work for us. I need to know the distro that this image was originally based upon. I also need to denote things like managed service level for an image that might be the same base distro as an unmanaged image. Sent from my iPhone On Apr 7, 2012, at 5:14 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Is there a (de-facto) standard for image metadata/properties? I'd like to be able to able to launch e.g. the Debian Squeeze image provided by the cloud. This is particularly important for clouds that don't allow image upload, but likely this will remain useful because different clouds will have different tweaks needed (e.g installing the right drivers based on the hypervisor). I could try smart-parsing the names, but it seems like metadata is the right way to do this, and I see no reason why any cloud would gain any advantage from not adopting a common convention. I know some clouds have started implementing their own approaches, but I don't believe anyone is locked into anything. In the interest of efficiency, I'm going to make a proposal for people to attack: 3 main pieces of metadata: os:distro, os:version_major, os:version_minor I'm thinking of the os prefix as standing for OpenStack, not Operating System. I'd like to 'reserve' the os prefix for 'agreed' prefixes. Maybe this should be openstack.org:distro ? os:distro would be the primary domain name of the distro, i.e. redhat.com, ubuntu.com, debian.org, centos.org etc os:version_major would be the major version of the release: debian.org: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0 ubuntu.com: 10.04, 10.10, 11.04, 11.10, 12.04 Numbers seem more machine-friendly than codenames - 6.0, not squeeze - humans will probably use the image names. os:version_minor would be the minor version of the release (because it's a minor revision, hopefully we shouldn't normally have to check this, although we might want to select the latest always). So os:distro=debian.org os:version_major 6.0 os:version_minor 3 would be an image of debian 6.0.3. Questions / ideas for other properties: - Some clouds will automatically respin images e.g. weekly with the latest updates. This could also be exposed through metadata. os:updated_through= 20120301 ? - Some clouds will offer only bare images, some will provide a variety e.g. bare, LAMP, Hadoop, etc. Should we use the native package names to indicate additional packages? e.g. os:packages=apache2,mysql,php5 ? As a (programmatic) consumer of these images, my wishlist: - A cloud will have to put on whatever drivers / agents they need to, but ideally these should otherwise be clean images, with minimal deviation from the stock install. (Or 'clean' images should be available alongside other images) It would be great if I could be launch a 'clean' image on any OpenStack cloud and have it
Re: [Openstack] Agreeing a common set of Image Properties
Looks like Pádraig and I were thinking alike. On Apr 7, 2012 8:49 PM, Pádraig Brady p...@draigbrady.com wrote: On 04/07/2012 11:13 PM, Justin Santa Barbara wrote: Is there a (de-facto) standard for image metadata/properties? I'd like to be able to able to launch e.g. the Debian Squeeze image provided by the cloud. This is particularly important for clouds that don't allow image upload, but likely this will remain useful because different clouds will have different tweaks needed (e.g installing the right drivers based on the hypervisor). I could try smart-parsing the names, but it seems like metadata is the right way to do this, and I see no reason why any cloud would gain any advantage from not adopting a common convention. I know some clouds have started implementing their own approaches, but I don't believe anyone is locked into anything. In the interest of efficiency, I'm going to make a proposal for people to attack: 3 main pieces of metadata: os:distro, os:version_major, os:version_minor I'm thinking of the os prefix as standing for OpenStack, not Operating System. I'd like to 'reserve' the os prefix for 'agreed' prefixes. Maybe this should be openstack.org:distro ? os:distro would be the primary domain name of the distro, i.e. redhat.com http://redhat.com, ubuntu.com http://ubuntu.com, debian.org http://debian.org, centos.org http://centos.org etc os:version_major would be the major version of the release: debian.org http://debian.org: 6.0, 5.0, 4.0, 3.1, 3.0, 2.2, 2.1, 2.0 ubuntu.com http://ubuntu.com: 10.04, 10.10, 11.04, 11.10, 12.04 Numbers seem more machine-friendly than codenames - 6.0, not squeeze - humans will probably use the image names. os:version_minor would be the minor version of the release (because it's a minor revision, hopefully we shouldn't normally have to check this, although we might want to select the latest always). So os:distro=debian.org http://debian.org os:version_major 6.0 os:version_minor 3 would be an image of debian 6.0.3. Questions / ideas for other properties: * Some clouds will automatically respin images e.g. weekly with the latest updates. This could also be exposed through metadata. os:updated_through= 20120301 ? * Some clouds will offer only bare images, some will provide a variety e.g. bare, LAMP, Hadoop, etc. Should we use the native package names to indicate additional packages? e.g. os:packages=apache2,mysql,php5 ? As a (programmatic) consumer of these images, my wishlist: * A cloud will have to put on whatever drivers / agents they need to, but ideally these should otherwise be clean images, with minimal deviation from the stock install. (Or 'clean' images should be available alongside other images) It would be great if I could be launch a 'clean' image on any OpenStack cloud and have it behave more or less the same; I shouldn't have to second guess any additional tweaks. * I would like to be able to launch the clean image and install updates myself, in case I don't want a particular update. Providing a fast apt cache is much better than providing respun images, for my use-case. I would be great if old images stuck around, therefore! This overlaps a lot with the output from the virt-inspector component of libguestfs, which might help solidify ideas: $ virt-inspector /var/lib/libvirt/images/rh63.img operatingsystems operatingsystem root/dev/VolGroup/lv_root/root namelinux/name archx86_64/arch distrorhel/distro product_nameRed Hat Enterprise Linux Workstation release 6.3 Beta (Santiago)/product_name major_version6/major_version minor_version3/minor_version package_formatrpm/package_format package_managementyum/package_management hostnamelocalhost.localdomain/hostname formatinstalled/format ... applications ... application namecoreutils/name version8.4/version release18/release /application ... Note that it doesn't have an updated_through element, but that would be fairly amorphous anyway given the combinations possible through updates. cheers, Pádraig. ___ 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] Agreeing a common set of Image Properties
On Apr 7, 2012 9:25 PM, Justin Santa Barbara jus...@fathomdb.com wrote: Thanks Padraig Nathanael - virt-inspector is a great source of inspiration. Can we put the virt-inspector output into a glance property? Would all the clouds agree to do that? I still would also like simpler metadata, as it just feels like too much information and work required for what is a comparatively simple use case (launch the official Debian Squeeze image either the latest one or a known revision). I envision an inspection step after image upload in glance that would try to pull the virt-inspector info (or any other attributes). Then glance would add those attributes as individual image properties automatically (not the entire virt-inspector XML dump). The base OS distro and versioning should be easy to get as stated previously. Some of the other pieces you're looking for that involve dates/updates might be a bit more difficult to automate (it presumes that timestamps and other things are to be trusted). Most importantly, I would like to see a solution to this now, rather than with the next release... If we agree these attributes now, we won't have to solve the unification problem in 6 months. I think this would be a good discussion for the summit. If you can get people to agree on naming (always more difficult than it should be), then you can start using them while support is added in the code to automate setting them. Padraig: Can you explain the issue with updated_through? I would have thought that would define a unique set of package versions (if I'm using the standard repos)? I expect that most people will either want to pick the oldest image (with a particular minor vision) or the newest image (with the greatest minor version), so it might be that this simply doesn't matter other than to define an ordering. It might also be that the creation date is adequate here. I have no objection to whatever attributes we define today being populated automatically using these cool tools in future! Justin Nate ___ 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] Instance fails to spawn when instance_path is nfs mounted
I had a problem like this when the umask was locked down. Setting the
umask to 022 in the init script for nova-compute solved my problem.
On Tue, Apr 3, 2012 at 1:56 PM, Diego Parrilla Santamaría
diego.parrilla.santama...@gmail.com wrote:
We use nfs backed instances a lot, and this problem normally has to do with
wrong permission management in your filer and/or client.
Check if not only root can write on the nfs share (specially libvirt user).
Diego
--
Diego Parrilla
CEO
www.stackops.com | diego.parri...@stackops.com | +34 649 94 43 29
| skype:diegoparrilla
On Tue, Apr 3, 2012 at 6:43 PM, Mandar Vaze / मंदार वझे
mandarv...@gmail.com wrote:
I saw an old question posted here :
https://answers.launchpad.net/nova/+question/164689
But I am not trying live migration.
I have nfs mounted instances_path - so when I try to spawn an instance I
run into the above errors. Especially following :
File /usr/lib/python2.7/dist-packages/libvirt.py, line 372, in
createWithFlags
40842 2012-04-03 05:42:27 TRACE nova.rpc.amqp if ret == -1: raise
libvirtError ('virDomainCreateWithFlags() failed', dom=self)
40843 2012-04-03 05:42:27 TRACE nova.rpc.amqp libvirtError: internal error
Process exited while reading console log output: chardev: opening
backend file failed
But as you can see below, several files are created in this folder, so I
am not sure if mine if permissions issue (Else none of the files would
get created) The problem is reported when libvirt tries to write to
console.log (File itself is created with correct permissions - just that
this is zero byte file)
mandar@ubuntu-dev-mandar:/nfs_shared_instances_path/instance-0005$ ll
total 10944
drwxrwxr-x 2 mandar libvirtd 4096 2012-04-03 05:42 ./
drwxrwxrwx 4 root root 4096 2012-04-03 05:42 ../
-rw-rw 1 mandar libvirtd 0 2012-04-03 05:42 console.log
-rw-r--r-- 1 mandar libvirtd 6291968 2012-04-03 05:42 disk
-rw-rw-r-- 1 mandar libvirtd 4731440 2012-04-03 05:42 kernel
-rw-rw-r-- 1 mandar libvirtd 1067 2012-04-03 05:42 libvirt.xml
-rw-rw-r-- 1 mandar libvirtd 2254249 2012-04-03 05:42 ramdisk
I'm suspecting :
https://bugs.launchpad.net/ubuntu/maverick/+source/libvirt/+bug/632696
But I the above doesn't show itself in non-NFS setup
Please suggest !!!
-Mandar
___
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
___
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] Keystone should to Apache HTTPD.
I like the recommendation. Particularly with regards to using PKI authentication. On Thu, Mar 1, 2012 at 2:05 PM, Adam Young ayo...@redhat.com wrote: I wrote up why I think that, at least for Keystone, we should move the front end over to Apache HTTPD. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ I've reposted it below. Keystone and the other Openstack components run in an a href=http://www.eventlet.net;Eventlet/a based HTTP server. Eventlet and a href=http://http://pypi.python.org/pypi/greenlet; Greenlet/a (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool. For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool. Keystone is an authentication hub. As such, it is literally the Keystone of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with a title=Sarbanes Oxley Act of 2002 href=http://www.soxlaw.com/; target=_blankSarbanes-Oxley/a. Or a title=Health Information Privacy href=http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html; target=_blankHIPPAA/a. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication. IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack. There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions. What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration. Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone. The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater stability, security, and growth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe :
Re: [Openstack] RHEL / CentOS - interfaces.template
The Fedora / EPEL packaging does this. http://fedoraproject.org/wiki/OpenStack http://koji.fedoraproject.org/koji/packageinfo?packageID=12510 Thanks, Nate On Tue, Feb 14, 2012 at 1:23 PM, Leandro Reox leandro.r...@gmail.com wrote: Hi guys, Anyone already implemented networking injection to RHEL systems acting as a guest ? If no any plans to make it to Essex final ? Regards ___ 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] Keystone: Redux (Dubstep Remix)
Are keystone light and keystone redux the same thing? Or is one just a light beer? ___ 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] multi_host networking, but not on all nodes?
With the default networking there's a single nova-network service. With the --multi_host option, 'set_network_host' sets every instance to use their host as the nova-network node, effectively requiring nova-network to run on every nova-compute. The multi_host mode greatly helps HA and consolidates fault domains, but at the cost of increased complexity and IP sprawl when using the VLAN networking model, as each host in the zone now has to have an IP on every VLAN. What I think I'm looking for is a middle ground where you can run multiple nova-network nodes, but not equal to the number of compute nodes. Basically a similar ability as implemented with the nova-volume service; the ability to scale the nova-network nodes independently from the computes. The big downside is that you no longer have the benefit of combined fault domains (network/compute). Is any of this possible today? Does Quantum with OpenvSwitch handle any of this either? Thoughts? Thanks, Nate ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] Essex dead wood cutting
+1!! On Feb 6, 2012 5:38 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Feb 02, 2012 at 11:52:17AM +, Armando Migliaccio wrote: To the best of my knowledge, the ESXi support is up to date. There may be bugs, but which virt driver is perfect ;)? Sateesh may know more, because he is the main contributor/maintainer from Citrix. However, as Vish pointed out in a previous email, any driver is doomed to rot if: a) no one is deploying OpenStack using the specific driver, thus unveiling potential problems; b) a pool of developers (not necessarily the first committer) keep the code up to date, increase functionality and test coverage (both unit and functional); Clearly both xenapi and libvirt are actively developed and deployed. How about vmwareapi? Anyone? Let's make sure that vmwareapi is not going to be the next one to bite the dust. FWIW, libvirt has pretty reasonable abilities to manage VMWare ESX servers, and some very basic support for Hyper-V. It would be interesting to see if the OpenStack libvirt driver can be developed to support these targets too. If the libvirt VMWare/HyperV drivers are not currently good enough for OpenStack's needs, IMHO, it would be worth putting effort into improving libvirt. It seems like a needless duplicated effort to have the libvirt OpenStack communities both trying to write hypervisor portability layers. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:| ___ 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] Remove Zones code - FFE
+1 On Feb 1, 2012 4:13 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I would prefer that if it can be done super-super fast. :) Vish On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote: I wonder if we can use some of the architecture of the new code and move the current implementation to that model. It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc. On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months So I guess I have some questions: 1.a) is the current implementation completely broken? 1.b) if yes, is it fixable 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release? Vish On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote: As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation. More info in the merge prop: https://review.openstack.org/#change,3629 So, can I? can I? Huh? ___ 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 ___ 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] Error whence starting nova-network - iptables-restore
You've probably got a bad security group rule applied (there isn't good input validation), which causes iptables-restore to fail on the bad rule. On Oct 7, 2011 9:11 AM, Jorge Luiz Correa corre...@gmail.com wrote: Hi! I would like some help with nova-network. Yestarday it was working and now I'm having problems. 2011-10-07 08:56:20,884 AUDIT nova [-] Starting network node (version 2011.3-nova-milestone-tarball:tarmac-20110922115702-k9nkvxqzhj130av2) 2011-10-07 08:56:20,885 DEBUG nova.utils [-] Attempting to grab semaphore iptables for method apply... from (pid=20298) inner /usr/lib/python2.7/dist-packages/nova/utils.py:672 2011-10-07 08:56:20,885 DEBUG nova.utils [-] Attempting to grab file lock iptables for method apply... from (pid=20298) inner /usr/lib/python2.7/dist-packages/nova/utils.py:677 2011-10-07 08:56:20,886 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-save -t filter from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:20,920 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:20,952 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-save -t nat from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:20,989 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:21,031 DEBUG nova.utils [-] Result was 2 from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:180 2011-10-07 08:56:21,032 DEBUG nova.utils [-] ['sudo', 'iptables-restore'] failed. Retrying. from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:194 2011-10-07 08:56:22,223 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:22,241 DEBUG nova.utils [-] Result was 2 from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:180 2011-10-07 08:56:22,242 DEBUG nova.utils [-] ['sudo', 'iptables-restore'] failed. Retrying. from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:194 2011-10-07 08:56:23,684 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:23,698 DEBUG nova.utils [-] Result was 2 from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:180 2011-10-07 08:56:23,699 DEBUG nova.utils [-] ['sudo', 'iptables-restore'] failed. Retrying. from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:194 2011-10-07 08:56:24,440 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:24,456 DEBUG nova.utils [-] Result was 2 from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:180 2011-10-07 08:56:24,456 DEBUG nova.utils [-] ['sudo', 'iptables-restore'] failed. Retrying. from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:194 2011-10-07 08:56:24,817 DEBUG nova.utils [-] Running cmd (subprocess): sudo iptables-restore from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:165 2011-10-07 08:56:24,832 DEBUG nova.utils [-] Result was 2 from (pid=20298) execute /usr/lib/python2.7/dist-packages/nova/utils.py:180 2011-10-07 08:56:24,833 CRITICAL nova [-] Unexpected error while running command. Command: sudo iptables-restore Exit code: 2 Stdout: '' Stderr: Bad argument `#'\nError occurred at line: 18\nTry `iptables-restore -h' or 'iptables-restore --help' for more information.\n (nova): TRACE: Traceback (most recent call last): (nova): TRACE: File /usr/bin/nova-network, line 49, in module (nova): TRACE: service.wait() (nova): TRACE: File /usr/lib/python2.7/dist-packages/nova/service.py, line 357, in wait (nova): TRACE: _launcher.wait() (nova): TRACE: File /usr/lib/python2.7/dist-packages/nova/service.py, line 107, in wait (nova): TRACE: service.wait() (nova): TRACE: File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 166, in wait (nova): TRACE: return self._exit_event.wait() (nova): TRACE: File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait (nova): TRACE: return hubs.get_hub().switch() (nova): TRACE: File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 177, in switch (nova): TRACE: return self.greenlet.switch() (nova): TRACE: File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 192, in main (nova): TRACE: result = function(*args, **kwargs) (nova): TRACE: File /usr/lib/python2.7/dist-packages/nova/service.py, line 77, in run_server (nova): TRACE: server.start()
Re: [Openstack] some newbie questions
Actually the VNC display number varies based on how many instances may be running on the node. Login to the box and run virsh list to list the instances and get the domain id of the one in question. Then run virsh vncdisplay id and it will output the VNC display number. :0 means 5900, :1 means 5901, etc... /nate On Aug 3, 2011 7:07 PM, Mark Gius m...@markgius.com wrote: Ugh this was a few months ago and I haven't done much with nova recently. IIRC, all you have to do is connect to the :1 vnc on the nova host. So if you have VNC and a GUI on your nova host, you can do that from the host with your favorite vncviewer (ubuntu comes with remote desktop viewer) and connect to :1. So the string you would type into the remote desktop viewer program would be localhost:1 You can do this through ssh port forwarding as well. Hopefully the above is sensical. Mark On Wed, Aug 3, 2011 at 3:32 PM, Aron Matskin aron.mats...@gmail.com wrote: Mark, Thanks for the advice - I'll take a look at it tomorrow. Just to save me some time: where is the log or/and how do I display it? -AM On Thu, Aug 4, 2011 at 1:24 AM, Mark Gius m...@markgius.com wrote: A1: When I had the symptoms you are describing it was because the instance never managed to boot from the image, and was just spinning cpu cycles displaying a could not boot disk type message. I figured that out by connecting to the VNC console of the instance. IIRC, you can look through the nova logs to figure out what VNC address to hit for the instance. Mark On Wed, Aug 3, 2011 at 4:33 AM, Aron Matskin aron.mats...@gmail.com wrote: Hi all! Just joined the mailing list. I'd like to do some development on the project (probably Nova). Some questions regarding how to start: Q1. I'm trying to setup Nova in a virtual environment - http://uksysadmin.wordpress.com/2011/02/17/running-openstack-under-virtualbox-a-complete-guide/- on a Windows host. I've successfully started an instance and assigned it a network address: aron@cloud1:~/openstack/cloud/creds$ euca-describe-instances RESERVATION r-k6e14a5w myproject default INSTANCE i-0001 ami-0a892947 172.241.0.1 10.0.0.3 running openstack (myproject, cloud1) 0 m1.tiny 2011-08-02T20:28:46Z nova but I'm unable to connect to the address (neither from the guest nor from the host): From the guest: aron@cloud1:~/openstack/cloud/creds$ ping 172.241.0.1 PING 172.241.0.1 (172.241.0.1) 56(84) bytes of data. From 172.241.0.1 icmp_seq=2 Destination Host Unreachable aron@cloud1:~/openstack/cloud/creds$ ping 10.0.0.3 PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Host Unreachable From the host: C:\ping 172.241.0.1 Pinging 172.241.0.1 with 32 bytes of data: Reply from 172.241.0.1: Destination host unreachable. Pinging the guest from the host and vice versa is ok, e.g.: C:\ping 172.241.0.101 Pinging 172.241.0.101 with 32 bytes of data: Reply from 172.241.0.101: bytes=32 time=1ms TTL=64 What may be wrong? Q2. When I do succeed to setup the environment, can anybody to point me to documentation on how to write simple code for OpenStack? Something along the lines of Hello, world!, but using some features peculiar to cloud applications. Q3. I have no technical knowledge about the cloud at all. Can anybody suggest a learning path so that I quickly can gain the basic necessary general and specific knowledge to start coding (i.e. first read the code and know what's flying, then fix some bugs, etc.)? Thanks in advance, -Aron ___ 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
