[Yahoo-eng-team] [Bug 1257683] Re: vmware VC driver doesn't attach swap storage
This was fixed with the following patch - https://review.openstack.org/#/c/109432/. ** Changed in: nova Status: Confirmed = Fix Released ** Changed in: nova Status: Fix Released = Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1257683 Title: vmware VC driver doesn't attach swap storage Status in OpenStack Compute (Nova): Confirmed Bug description: With a vmware compute node (vcenter with 3 esxi in my case), no ephemeral storage is attache to the instance: swap or ephemeral disks. I didn't find any errors/warnings when creating instances. Let me know ig you need other information. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1257683/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1316556] Re: vmware: boot from image (create volume) is failing
This is because the time it takes to create the volume is longer than the default timeout value. You can increase the timeout value in /etc/nova/nova.conf to something greater, e.g. 3600. block_device_allocate_retries = 3600 ** Changed in: nova Status: Confirmed = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1316556 Title: vmware: boot from image (create volume) is failing Status in OpenStack Compute (Nova): Invalid Status in “nova” package in Ubuntu: In Progress Bug description: Nova fails to boot an instance from the image using create volume. Run time environment details: cinder is configured with VMDK driver nova is configured with Vmware Vc driver While nova is trying to provision a instance by creating the volume from the given VMDK image by creating a volume and booting from it, it failed to create the instance, though volume is created properly after given amount of time. This failure is occurring especially when the volume creation is taking more than 180 seconds. Exception thrown by nova compute is: Volume f36bf0ce-ef0d-4200-b15b- cf2de3689bbb did not finish being created even after we waited 221 seconds or 180 attempts. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316556/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1375531] [NEW] swap_volume does not save changes made in _connect_volume
Public bug reported: This is a bug reported by Nikola in a review - https://review.openstack.org/#/c/121965/8/nova/virt/libvirt/driver.py. swap_volume does not save changes for connection_info. In swap_volume, a call is made to _connect_volume, which modifies connection_info. For example, in the LibvirtISCSIVolumeDriver, connection_info['data']['host_device'] = host_device. However, this update is not saved to the DB, such that any updates made within swap_volume are lost. We need to save any changes made in _connect_volume to the DB, as it is done elsewhere in the code, e.g. _get_guest_storage_config https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3488. ** Affects: nova Importance: High Assignee: Thang Pham (thang-pham) Status: New ** Tags: volumes -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1375531 Title: swap_volume does not save changes made in _connect_volume Status in OpenStack Compute (Nova): New Bug description: This is a bug reported by Nikola in a review - https://review.openstack.org/#/c/121965/8/nova/virt/libvirt/driver.py. swap_volume does not save changes for connection_info. In swap_volume, a call is made to _connect_volume, which modifies connection_info. For example, in the LibvirtISCSIVolumeDriver, connection_info['data']['host_device'] = host_device. However, this update is not saved to the DB, such that any updates made within swap_volume are lost. We need to save any changes made in _connect_volume to the DB, as it is done elsewhere in the code, e.g. _get_guest_storage_config https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3488. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1375531/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1366909] Re: disk image create creates image size of atleast 1G
Ok, diskimage-builder is not a nova component. It is it's own project. ** Project changed: nova = diskimage-builder ** Changed in: diskimage-builder Status: Incomplete = New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1366909 Title: disk image create creates image size of atleast 1G Status in Openstack disk image builder: New Bug description: disk image create creates a qcow2 image with virtual size of atleast 1G. If DISK-IMAGE-SIZE is used in decimals,then, truncate command errors out as invalid number. This forces the image to be atleast 1G in size. Could this made in Mega bytes so that image less than 1 G can be created. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/diskimage-builder/+bug/1366909/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1358155] Re: Using CLI I am able to stop server when it is locked
I cannot reproduce this bug based on the steps you listed above. I get the following error, which is correct: $ nova stop test1 ERROR (Conflict): Instance f7961e90-29c8-4e5d-8e8e-34ad7e46b834 is locked (HTTP 409) (Request-ID: req-5193f0fb-3cd5-4603-80ea-74585caae612) However, if I attempt to use the admin user to stop the instance, it works, which is what I excepted. ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1358155 Title: Using CLI I am able to stop server when it is locked Status in OpenStack Compute (Nova): Invalid Bug description: I am using devstack + tempest - Operations are as - 1. [raies@localhost devstack]$ nova list +--+-+++-+---+ | ID | Name| Status | Task State | Power State | Networks | +--+-+++-+---+ | d44993fc-c81f-4e4c-9adf-09019859cb31 | test-server | ACTIVE | - | Running | public=172.24.4.7 | +--+-+++-+---+ 2. [raies@localhost devstack]$ nova lock d44993fc-c81f-4e4c-9adf- 09019859cb31 3. [raies@localhost devstack]$ nova stop d44993fc-c81f-4e4c-9adf- 09019859cb31 All the above commands are successful. But third command should raise exception (conflict) but all command are successful. Above can be confirmed from the API testing in tempest - tempest/tempest/api/compute/servers/test_server_actions.py -- test_lock_unlock_server To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1358155/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1359136] Re: vmware: display incorrect host_ip for hypervisor show
The update link is actually: http://docs.openstack.org/trunk/config- reference/content/vmware.html#VMwareVCDriver_details ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1359136 Title: vmware: display incorrect host_ip for hypervisor show Status in OpenStack Compute (Nova): Invalid Bug description: From VCenter driver, with compute node configured to be cluster01. And VCenter IP is 10.9.1.43 But with hypervisor show command, it will display the host IP for the controller node. It should be pointing to the really VCenter IP. [root@dhcp-10-9-3-83 ~]# nova hypervisor-show 29 +---+--+ | Property | Value | +---+--+ | cpu_info_model| [Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz, Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz] | | cpu_info_topology_cores | 24 | | cpu_info_topology_threads | 48 | | cpu_info_vendor | [IBM, IBM] | | current_workload | 0 | | disk_available_least | - | | free_disk_gb | 763 | | free_ram_mb | 354728 | | host_ip | 10.9.3.83 | | hypervisor_hostname | domain-c17(cluster01) | | hypervisor_type | VMware vCenter Server | | hypervisor_version| 5005000 | | id| 29 | | local_gb | 794 | | local_gb_used | 31 | | memory_mb | 362336 | | memory_mb_used| 7608 | | running_vms | 3 | | service_host | dhcp-10-9-3-83.sce.cn.ibm.com | | service_id| 6 | | vcpus | 48 | | vcpus_used| 5 | +---+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1359136/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1355661] Re: evacuate scheduler can support it?
Troy, Please post your question to the mailing list (openst...@lists.openstack.org), as opposed to an actual bug. This is a question and not a bug. Regards, Thang ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1355661 Title: evacuate scheduler can support it? Status in OpenStack Compute (Nova): Invalid Bug description: Hello everyone host-evacuate/evacuate functions can migrate a downtime in all instances to another compute node. example: nova host-evacuate --target_host compute1 compute2 whether the virtual machine scheduler all reasonable dispatch to more servers? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1355661/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1356051] [NEW] Cannot load 'instance' in the base class
] http://10.131.179.211:8774/v2/875c3f62ef75400487e4a68679f8e239/os-floating-ips returned with HTTP 500 2014-08-12 13:54:29.580 DEBUG nova.api.openstack.wsgi [req-86d8f466-cfae-42ac-8340-9eac36d6fc71 demo demo] Returning 500 to user: The server has either erred or is incapable of performing the requested operation. from (pid=12246) __call__ /opt/stack/nova/nova/api/openstack/wsgi.py:1200 With the switch to using FloatingIP objects, it is not longer necessary to call _normalize_ip in nova/api/openstack/compute/contrib/floating_ips.py. The updated code in nova/network/floating_ips.py and nova/api/openstack/compute/contrib/floating_ips.py has logic to get the instance associated with the floating IP, i.e. get_instance_by_floating_ip_addr. ** Affects: nova Importance: Undecided Assignee: Thang Pham (thang-pham) Status: New ** Tags: api network vmware -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1356051 Title: Cannot load 'instance' in the base class Status in OpenStack Compute (Nova): New Bug description: I tried the following on VMware using the VMwareVCDriver with nova- network: 1. Create an instance 2. Create and associate a floating IP with the instance It failed and printed out the following messages in n-api logs: 2014-08-12 13:54:29.578 ERROR nova.api.openstack [req-86d8f466-cfae-42ac-8340-9eac36d6fc71 demo demo] Caught error: Cannot load 'instance' in the base class 2014-08-12 13:54:29.578 TRACE nova.api.openstack Traceback (most recent call last): 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/__init__.py, line 124, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return req.get_response(self.application) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send 2014-08-12 13:54:29.578 TRACE nova.api.openstack application, catch_exc_info=False) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application 2014-08-12 13:54:29.578 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return resp(environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py, line 565, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return self._app(env, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return resp(environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return resp(environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/lib/python2.7/dist-packages/routes/middleware.py, line 131, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack response = self.app(environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack return resp(environ, start_response) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func 2014-08-12 13:54:29.578 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 908, in __call__ 2014-08-12 13:54:29.578 TRACE nova.api.openstack content_type, body, accept) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 974, in _process_stack 2014-08-12 13:54:29.578 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /opt/stack/nova/nova/api/openstack/wsgi.py, line 1058, in dispatch 2014-08-12 13:54:29.578 TRACE nova.api.openstack return method(req=request, **action_args) 2014-08-12 13:54:29.578 TRACE nova.api.openstack File /opt/stack/nova/nova/api
[Yahoo-eng-team] [Bug 1351260] Re: The host_ip in the hypervisor description is wrong; it is the controller ip.
Closing this bug, since it appears to be fixed by updating a CONF parameter. ** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1351260 Title: The host_ip in the hypervisor description is wrong; it is the controller ip. Status in OpenStack Compute (Nova): Invalid Bug description: The host_ip parameter in the hypervisor description should show the ip of the host that contains such hypervisor. However, instead of this, it is is showing the ip of the controller. There was a bug report to include this host_ip information, but after that, it is not providing a accurate information. Someone that is programming a new functionality could need such an information. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1351260/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1354587] Re: Nova list images detail can return a block_device_mapping in the metadata
** Changed in: nova
Status: New = Opinion
** Changed in: nova
Importance: Undecided = Wishlist
** Tags added: api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1354587
Title:
Nova list images detail can return a block_device_mapping in the
metadata
Status in OpenStack Compute (Nova):
Opinion
Bug description:
1. Fire up a DevStack instance from the stable/havana, stable/icehouse, or
master branches.
2. Go into Horizon
3. Launch an instance
1. Instance Boot Source: Boot from image (creates a new volume)
2. Image Name: cirros
3. Device size (GB): 1
1. For the instance that was just created, click the Create Snapshot button.
Now if you do a list images detail in the API like
/v2/{tenant_id}/images/detail ( see http://developer.openstack.org
/api-ref-compute-v2.html#compute_images )
You'll get back something like:
{
images: [
{
status: ACTIVE,
updated: 2014-08-08T04:43:36Z,
id: cd9d57a9-0978-45f3-9cbc-edb99347be6b,
OS-EXT-IMG-SIZE:size: 0,
name: t11,
created: 2014-08-08T04:43:36Z,
minDisk: 0,
progress: 100,
minRam: 0,
metadata: {
block_device_mapping: [
{
guest_format: null,
boot_index: 0,
no_device: null,
volume_id: null,
volume_size: null,
disk_bus: null,
image_id: null,
source_type: snapshot,
device_type: null,
snapshot_id: a900a56c-61b7-4438-9150-76312fa1aa10,
destination_type: volume,
delete_on_termination: null
}
],
checksum: 32c08d302f9206668030d47789b77858,
min_ram: 1,
disk_format: qcow2,
image_name: Ubuntu LTS 14.04,
bdm_v2: True,
image_id: cfefefc1-eba2-4b1e-9b07-a8c74a872d65,
root_device_name: /dev/vda,
container_format: bare,
min_disk: 8,
size: 254149120
}
},
}
The metadata should only be simple key/value pairs with strings only (
again see http://developer.openstack.org/api-ref-
compute-v2.html#compute_images )
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1354587/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1353111] Re: Deleting a tenant leaves the network orphoned
This is really a keystone problem, since it is only through keystone that you can delete a tenant, e.g. keystone tenant-delete. ** Project changed: nova = keystone -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1353111 Title: Deleting a tenant leaves the network orphoned Status in OpenStack Identity (Keystone): New Bug description: Steps using Horizon 1. Create a new tenant/project 2. Now create networks in that tenant/project 3. Delete the tenant 4. There is no warning or any message regarding the fact that there are networks under this tenant Network is just an example everything located within that tenant becomes orphaned Expected behavior: Warn the user and disallow the operation or clean up the resources allocated for that tenant Release: Openstack Icehouse Install used: RDO Packstack RHEL 7/OSP5 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1353111/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1351809] [NEW] Move _is_mapping logic to more central place
Public bug reported: This bug is a follow-up to Nikola Dipanov's comment in https://review.openstack.org/#/c/109834/2/nova/compute/manager.py. The logic to identify volumes is currently a nested function in _default_block_device_names, named _is_mapping. It should be moved to a more general place so others could utilize it. ** Affects: nova Importance: Undecided Assignee: Thang Pham (thang-pham) Status: New ** Tags: volumes -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1351809 Title: Move _is_mapping logic to more central place Status in OpenStack Compute (Nova): New Bug description: This bug is a follow-up to Nikola Dipanov's comment in https://review.openstack.org/#/c/109834/2/nova/compute/manager.py. The logic to identify volumes is currently a nested function in _default_block_device_names, named _is_mapping. It should be moved to a more general place so others could utilize it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1351809/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1292573] Re: nova cannot retrieve a fixed ip info
** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1292573 Title: nova cannot retrieve a fixed ip info Status in OpenStack Compute (Nova): Invalid Bug description: When using 'nova fixed-ip-get' command to retrieve any fixed ip, it will return a not found error(404). this result of the empty 'fixed_ips' db table. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1292573/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 977738] Re: iptables-save command executed by nova-manage network create command with QuantumManager
I do not believe this is an issue anymore. Please re-open if it is.
** Changed in: nova
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/977738
Title:
iptables-save command executed by nova-manage network create command
with QuantumManager
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Scenario :
when nova-manage network create is executed, it internally executes
iptables-save
Here is a stack trace obtained by putting a breakpoint in
nova/network/linux_net.py : apply() method
/usr/local/bin/nova-manage(7)module()
- execfile(__file__)
/opt/stack/nova/bin/nova-manage(1746)module()
- main()
/opt/stack/nova/bin/nova-manage(1733)main()
- fn(*fn_args, **fn_kwargs)
/opt/stack/nova/bin/nova-manage(812)create()
- fixed_cidr=fixed_cidr)
/opt/stack/nova/nova/network/quantum/manager.py(223)create_networks()
- self.l3driver.initialize_network(cidr)
/opt/stack/nova/nova/network/l3.py(93)initialize_network()
- linux_net.add_snat_rule(cidr)
/opt/stack/nova/nova/network/linux_net.py(434)add_snat_rule()
- iptables_manager.apply()
/opt/stack/nova/nova/utils.py(945)inner()
- retval = f(*args, **kwargs)
/opt/stack/nova/nova/network/linux_net.py(327)apply()
- current_table, _err = self.execute('%s-save' % (cmd,),
Expected Behavior :
nova-manage should only touch database, because nova-manage is not always
executed on nova-network node.
So nova-manage should NOT execute iptables-save command
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/977738/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1319619] Re: Cannot delete unused 'default' security group for removed project
According to
http://docs.openstack.org/trunk/openstack-ops/content/security_groups.html:
All projects have a default security group, which is applied to instances
that have no other security group defined. Unless
changed, this security group denies all incoming traffic.
The fact that you cannot delete a default security group seems correct.
I do not believe this a bug, at least based on the documentation.
** Changed in: nova
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1319619
Title:
Cannot delete unused 'default' security group for removed project
Status in OpenStack Compute (Nova):
Invalid
Bug description:
When creating new project, there will generates a 'default' security group.
However, after deleting the project, the 'default' security group cannot be
deleted.
Always met the error msg when run 'nova secgroup-delete ${group_id}'.
The msg looks like
'ERROR: Unable to delete system group 'default' (HTTP 400) (Request-ID:
req-2aa9a7d2-2c7d-4abc-a961-e98e06dc2fd5)'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1319619/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1317321] [NEW] Add extra unit test case for more than 1 ephemeral disk in BDM
Public bug reported: There was a comment on https://review.openstack.org/#/c/90583/ (after it was approved for merge) to add an extra test case to handle more than 1 ephemeral disk, as well as correct a comment in the code to be more accurate. The purpose of this bug is to add the extra test case for _get_instance_block_device_info to test more than 1 ephemeral disk and correct one of the comments in _get_instance_block_device_info. ** Affects: nova Importance: Low Assignee: Thang Pham (thang-pham) Status: New ** Changed in: nova Assignee: (unassigned) = Thang Pham (thang-pham) ** Changed in: nova Importance: Undecided = Low ** Description changed: - There was a comment on https://review.openstack.org/#/c/90583/ to add an - extra test case to handle more than 1 ephemeral disk as well as correct - a comment in the code to be more accurate. The purpose of this bug is - to add the extra test case for _get_instance_block_device_info to test - more than 1 ephemeral disk and correct one of the comments in - _get_instance_block_device_info. + There was a comment on https://review.openstack.org/#/c/90583/ (after it + was approved for merge) to add an extra test case to handle more than 1 + ephemeral disk, as well as correct a comment in the code to be more + accurate. The purpose of this bug is to add the extra test case for + _get_instance_block_device_info to test more than 1 ephemeral disk and + correct one of the comments in _get_instance_block_device_info. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317321 Title: Add extra unit test case for more than 1 ephemeral disk in BDM Status in OpenStack Compute (Nova): New Bug description: There was a comment on https://review.openstack.org/#/c/90583/ (after it was approved for merge) to add an extra test case to handle more than 1 ephemeral disk, as well as correct a comment in the code to be more accurate. The purpose of this bug is to add the extra test case for _get_instance_block_device_info to test more than 1 ephemeral disk and correct one of the comments in _get_instance_block_device_info. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1317321/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1313935] Re: tenant is required for quota-update but not for quota-show
** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Assignee: (unassigned) = Thang Pham (thang-pham) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1313935 Title: tenant is required for quota-update but not for quota-show Status in Cinder: New Status in OpenStack Compute (Nova): In Progress Status in “nova” package in Ubuntu: New Bug description: Tenant is a required positional parameter on quota-update but is optional on quota-show. And when --tenant is not specified on quota- show it doesn't return valid limits for the user. $ nova quota-show --user demo +-+---+ | Quota | Limit | +-+---+ | instances | 10| ... +-+---+ $ nova quota-update --user demo --instances 9# tenant is required usage: nova quota-update [--user user-id] [--instances instances] [--cores cores] [--ram ram] [--floating-ips floating-ips] [--fixed-ips fixed-ips] [--metadata-items metadata-items] [--injected-files injected-files] [--injected-file-content-bytes injected-file-content-bytes] [--injected-file-path-bytes injected-file-path-bytes] [--key-pairs key-pairs] [--security-groups security-groups] [--security-group-rules security-group-rules] [--force] tenant-id error: too few arguments Try 'nova help quota-update' for more information. $ nova quota-update --user demo --instances 9 demo $ nova quota-show --user demo # should return instances=9 or should fail because tenant is required +-+---+ | Quota | Limit | +-+---+ | instances | 10| ... +-+---+ $ nova quota-show --user demo --tenant demo # returns the correct value +-+---+ | Quota | Limit | +-+---+ | instances | 9 | ... +-+---+ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1313935/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1313107] [NEW] disk.local is not created when additional ephemeral disks are attached on boot
Public bug reported:
If you try to boot an instance with a flavor containing an ephemeral
disk and also attach an additional ephemeral disk to it at boot time,
the ephemeral disk specified in the flavor is not created.
I have the following flavor (4G root, 4G ephemeral, 1G memory, and 1 VCPU):
$ nova flavor-show m3.tiny
++--+
| Property | Value|
++--+
| OS-FLV-DISABLED:disabled | False|
| OS-FLV-EXT-DATA:ephemeral | 4|
| disk | 4|
| extra_specs| {} |
| id | d63abfa8-64dc-4833-99bc-e29c2e1aa6e6 |
| name | m3.tiny |
| os-flavor-access:is_public | True |
| ram| 1024 |
| rxtx_factor| 1.0 |
| swap | |
| vcpus | 1|
++--+
I used the nova boot --ephemeral parameter to attach an additional ephemeral
disk on boot:
$ nova boot --flavor m3.tiny --key_name stack --image
precise-server-cloudimg-amd64 --ephemeral size=2 test3
If I examine the libvirt XML of the instance after it is created, I
noticed it does not have disk.local, as it usually does when an
ephemeral disk is specified by a flavor. Instead, it only contains the
ephemeral disk specified by the --ephemeral parameter.
...
disk type='file' device='disk'
driver name='qemu' type='qcow2' cache='none'/
source
file='/opt/stack/data/nova/instances/4f3bd658-1719-4074-a044-d51f24d92b76/disk'/
target dev='vda' bus='virtio'/
alias name='virtio-disk0'/
address type='pci' domain='0x' bus='0x00' slot='0x04'
function='0x0'/
/disk
disk type='file' device='disk'
driver name='qemu' type='qcow2' cache='none'/
source
file='/opt/stack/data/nova/instances/4f3bd658-1719-4074-a044-d51f24d92b76/disk.eph0'/
target dev='vdb' bus='virtio'/
alias name='virtio-disk1'/
address type='pci' domain='0x' bus='0x00' slot='0x05'
function='0x0'/
/disk
...
When I attempt to reboot the instance, it fails with the following
message in n-cpu log:
Apr 26 10:08:46 localhost 2014-04-26 10:08:46.850 ERROR
oslo.messaging._drivers.common [req-e1a531c9-3fbf-44a7-8f6a-1c6616b906e8
admin demo] Returning exception [Errno 2] No such file or directory:
'/opt/stack/data/nova/instances/4f3bd658-1719-4074-a044-d51f24d92b76/disk.local'
to caller
** Affects: nova
Importance: Medium
Assignee: Thang Pham (thang-pham)
Status: New
** Changed in: nova
Assignee: (unassigned) = Thang Pham (thang-pham)
** Changed in: nova
Importance: Undecided = Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1313107
Title:
disk.local is not created when additional ephemeral disks are attached
on boot
Status in OpenStack Compute (Nova):
New
Bug description:
If you try to boot an instance with a flavor containing an ephemeral
disk and also attach an additional ephemeral disk to it at boot time,
the ephemeral disk specified in the flavor is not created.
I have the following flavor (4G root, 4G ephemeral, 1G memory, and 1 VCPU):
$ nova flavor-show m3.tiny
++--+
| Property | Value|
++--+
| OS-FLV-DISABLED:disabled | False|
| OS-FLV-EXT-DATA:ephemeral | 4|
| disk | 4|
| extra_specs| {} |
| id | d63abfa8-64dc-4833-99bc-e29c2e1aa6e6 |
| name | m3.tiny |
| os-flavor-access:is_public | True |
| ram| 1024 |
| rxtx_factor| 1.0 |
| swap | |
| vcpus | 1|
++--+
I used the nova boot --ephemeral parameter to attach an additional ephemeral
disk on boot:
$ nova boot --flavor m3.tiny
[Yahoo-eng-team] [Bug 1296164] [NEW] Missing implementation to get, delete, and update volume metadata
Public bug reported: There are four methods in nova/nova/volume/cinder.py which are NotImplemented. They are as follows: 1. get_volume_metadata 2. delete_volume_metadata 3. update_volume_metadata 4. get_volume_metadata_value These methods are required in cases where nova needs to modify a cinder volume's metadata, e.g. attach and detach time. The latest code in nova's master branch shows these methods as NotImplemented. ** Affects: nova Importance: Undecided Assignee: Thang Pham (thang-pham) Status: In Progress ** Tags: volumes ** Changed in: nova Assignee: (unassigned) = Thang Pham (thang-pham) ** Tags added: volumes ** Changed in: nova Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1296164 Title: Missing implementation to get, delete, and update volume metadata Status in OpenStack Compute (Nova): In Progress Bug description: There are four methods in nova/nova/volume/cinder.py which are NotImplemented. They are as follows: 1. get_volume_metadata 2. delete_volume_metadata 3. update_volume_metadata 4. get_volume_metadata_value These methods are required in cases where nova needs to modify a cinder volume's metadata, e.g. attach and detach time. The latest code in nova's master branch shows these methods as NotImplemented. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1296164/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1105445] Re: Instance 'start' will fail after hypervisor reboot
** Changed in: nova Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1105445 Title: Instance 'start' will fail after hypervisor reboot Status in OpenStack Compute (Nova): Fix Released Bug description: Simple to reproduce this with libvirt. Let's assume there' s a single VM running on the hypervisor in question. Gracefully shutdown the instance in question via the guest OS and wait for the power stat to reflect that it is shutdown. Then reboot the hypervisor, then attempt to call 'nova start uuid'. This operation will fail, because the VIFs, block devices, etc are all missing. This comes down to us calling _create_domain() rather than _create_domain_and_network() within the libvirt driver. The compute manager needs to pass more information into driver.power_on, so that we can rebuild the VIFs and block connections. Basically, similar treatment to what we've already done for driver.resume(), driver.reboot(), etc. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1105445/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
