[Yahoo-eng-team] [Bug 1554491] [NEW] xenapi: tools/populate_other_config is broken
Public bug reported: https://github.com/openstack/nova/blob/master/tools/xenserver/populate_other_config.py Needs to be updated ... looks like the code has not been updated since this is probably not used often, so now its completely broken since its trying to use xenapi driver function that dont exist anymore. ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Sulochan Acharya (sulochan-acharya) ** 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/1554491 Title: xenapi: tools/populate_other_config is broken Status in OpenStack Compute (nova): In Progress Bug description: https://github.com/openstack/nova/blob/master/tools/xenserver/populate_other_config.py Needs to be updated ... looks like the code has not been updated since this is probably not used often, so now its completely broken since its trying to use xenapi driver function that dont exist anymore. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1554491/+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 1524837] [NEW] xenapi: compute service restart during live migration can cause nova to lose track of instance
Public bug reported: For XAPI driver: During live migration if the compute service *on both source and destination hosts* are for any reason restarted, nova loses track of the instance that is being live migrated. This happens because live migration continues underneath nova (through xapi), which continues and xapi thinks the migration is done... where as nova things because of the service disruption migration failed. When this happens the instance is on the destination with db records pointing to source, this can cause nova to even delete the vm during compute service init. ** Affects: nova Importance: Undecided Status: New ** Tags: live-migration xenserver ** Tags added: live-migration -- 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/1524837 Title: xenapi: compute service restart during live migration can cause nova to lose track of instance Status in OpenStack Compute (nova): New Bug description: For XAPI driver: During live migration if the compute service *on both source and destination hosts* are for any reason restarted, nova loses track of the instance that is being live migrated. This happens because live migration continues underneath nova (through xapi), which continues and xapi thinks the migration is done... where as nova things because of the service disruption migration failed. When this happens the instance is on the destination with db records pointing to source, this can cause nova to even delete the vm during compute service init. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1524837/+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 1490547] [NEW] Xen Tools: scripts failing due to implicit import of CONF object
Public bug reported:
Some xen tools are failing because some CONF objects seem to be imported
implicitly though import paths rather than though import_opt. For
instance calling destroy_cached_images.py (SOME FIX PENDING, see :
https://review.openstack.org/#/c/209526 )
will result in:
xenapi = xenapi_driver.XenAPIDriver(virtapi.VirtAPI())
File "nova/virt/xenapi/driver.py", line 130, in __init__
self._vmops = vmops.VMOps(self._session, self.virtapi)
File "/nova/virt/xenapi/vmops.py", line 226, in __init__
self.compute_api = compute.API()
File "/nova/compute/__init__.py", line 39, in API
return importutils.import_object(class_name, *args, **kwargs)
File "/oslo_utils/importutils.py", line 38, in import_object
return import_class(import_str)(*args, **kwargs)
File "/nova/compute/api.py", line 304, in __init__
self.servicegroup_api = servicegroup.API()
File "/nova/servicegroup/api.py", line 55, in __init__
report_interval = CONF.report_interval
File "/oslo_config/cfg.py", line 1896, in __getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option: report_interval
However, adding CONF.import_opt('report_interval', 'nova.service')
will result in a trace and:
ImportError: cannot import name conductor
** Affects: nova
Importance: Undecided
Assignee: Sulochan Acharya (sulochan-acharya)
Status: New
** Changed in: nova
Assignee: (unassigned) => Sulochan Acharya (sulochan-acharya)
--
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/1490547
Title:
Xen Tools: scripts failing due to implicit import of CONF object
Status in OpenStack Compute (nova):
New
Bug description:
Some xen tools are failing because some CONF objects seem to be
imported implicitly though import paths rather than though import_opt.
For instance calling destroy_cached_images.py (SOME FIX PENDING, see :
https://review.openstack.org/#/c/209526 )
will result in:
xenapi = xenapi_driver.XenAPIDriver(virtapi.VirtAPI())
File "nova/virt/xenapi/driver.py", line 130, in __init__
self._vmops = vmops.VMOps(self._session, self.virtapi)
File "/nova/virt/xenapi/vmops.py", line 226, in __init__
self.compute_api = compute.API()
File "/nova/compute/__init__.py", line 39, in API
return importutils.import_object(class_name, *args, **kwargs)
File "/oslo_utils/importutils.py", line 38, in import_object
return import_class(import_str)(*args, **kwargs)
File "/nova/compute/api.py", line 304, in __init__
self.servicegroup_api = servicegroup.API()
File "/nova/servicegroup/api.py", line 55, in __init__
report_interval = CONF.report_interval
File "/oslo_config/cfg.py", line 1896, in __getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option: report_interval
However, adding CONF.import_opt('report_interval', 'nova.service')
will result in a trace and:
ImportError: cannot import name conductor
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1490547/+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 1488884] [NEW] xapi live migration rollback should clean up any volume attached during migration
Public bug reported: When live migrating an instance with volume attached the volume gets attached to the destination during the process. If after that there is a failure, the volume is left attachd to the destination, and then gets attached to the source. Source cleanup is explicit, however, we do not do any cleanup during rollback for xapi on live migration failure. We need to simply forget the sr as a part of migration rollback. ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) ** 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/144 Title: xapi live migration rollback should clean up any volume attached during migration Status in OpenStack Compute (nova): In Progress Bug description: When live migrating an instance with volume attached the volume gets attached to the destination during the process. If after that there is a failure, the volume is left attachd to the destination, and then gets attached to the source. Source cleanup is explicit, however, we do not do any cleanup during rollback for xapi on live migration failure. We need to simply forget the sr as a part of migration rollback. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/144/+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 1481689] [NEW] xenapi: cached images should be cleaned up by time
Public bug reported: For xenapi driver, there needs to be some way to delete cached images based on when they were created. Here is a use case: Operators often change images frequently for updates etc, if an image has cache_in_nova flag set, xapi will cache it in the SR. However, the cleanup method, can only handle cleanup of cache that are not used (which is fair enough) but a lot of the times we don't want to clean new images even when they are not used, so there needs to be a way to delete image based on when they were cached. One approach, for example, could be that we set created timestamp on the image, and be able to delete images depending on when they were cached etc. ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: New ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) -- 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/1481689 Title: xenapi: cached images should be cleaned up by time Status in OpenStack Compute (nova): New Bug description: For xenapi driver, there needs to be some way to delete cached images based on when they were created. Here is a use case: Operators often change images frequently for updates etc, if an image has cache_in_nova flag set, xapi will cache it in the SR. However, the cleanup method, can only handle cleanup of cache that are not used (which is fair enough) but a lot of the times we don't want to clean new images even when they are not used, so there needs to be a way to delete image based on when they were cached. One approach, for example, could be that we set created timestamp on the image, and be able to delete images depending on when they were cached etc. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1481689/+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 1481693] [NEW] xenapi: xentool - cache destroy script is broken
Public bug reported: https://github.com/openstack/nova/blob/master/tools/xenserver/destroy_cached_images.py is broken, as it has not been updated for a really long time. XenAPIDriver initialization has changed since, along with oslo_config so this script needs to be updated to include those. ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: New ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) -- 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/1481693 Title: xenapi: xentool - cache destroy script is broken Status in OpenStack Compute (nova): New Bug description: https://github.com/openstack/nova/blob/master/tools/xenserver/destroy_cached_images.py is broken, as it has not been updated for a really long time. XenAPIDriver initialization has changed since, along with oslo_config so this script needs to be updated to include those. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1481693/+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 1462295] [NEW] xenapi needs pre live-migration plugin to check/fake pv driver version in xenstore
Public bug reported: Xenserver relies on guest (domU) to provide information about the presence of PV drivers in the guest image back to dom0 though xenstore for various actions like live-migration etc. It is possible for users to disable the xen agent that reports this info and therefore causing failures in live-migration. In cases where PV drivers are running it is safe to fake the presence of this information in xenstore. XAPI simply reads this information to ascertain the presence of pv drives. Since it is common for users to disable this, we need a way to ensure that if pv tools are present (we can check this though the presence of pv devices like vif) we can carry out a live-migration. We can easily do this by faking driver version in xenstore for the instance for which we are attempting live-migration prior to starting live-migration. In cases where this info is not present in xenstore, xapi will simply fail the migration attempt with VM_MISSING_PV_DRIVERS error. 2014-04-24 20:47:36.938 24870 TRACE nova.virt.xenapi.vmops Failure: ['VM_MISSING_PV_DRIVERS', 'OpaqueRef:ef49f129-691d- 4e18-7a09-8dae8928aa7a'] ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: New ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) ** Summary changed: - xenapi needs pre live-migration plugin to handle pvtools + xenapi needs pre live-migration plugin to check/fake pv driver version in xenstore -- 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/1462295 Title: xenapi needs pre live-migration plugin to check/fake pv driver version in xenstore Status in OpenStack Compute (Nova): New Bug description: Xenserver relies on guest (domU) to provide information about the presence of PV drivers in the guest image back to dom0 though xenstore for various actions like live-migration etc. It is possible for users to disable the xen agent that reports this info and therefore causing failures in live-migration. In cases where PV drivers are running it is safe to fake the presence of this information in xenstore. XAPI simply reads this information to ascertain the presence of pv drives. Since it is common for users to disable this, we need a way to ensure that if pv tools are present (we can check this though the presence of pv devices like vif) we can carry out a live-migration. We can easily do this by faking driver version in xenstore for the instance for which we are attempting live-migration prior to starting live-migration. In cases where this info is not present in xenstore, xapi will simply fail the migration attempt with VM_MISSING_PV_DRIVERS error. 2014-04-24 20:47:36.938 24870 TRACE nova.virt.xenapi.vmops Failure: ['VM_MISSING_PV_DRIVERS', 'OpaqueRef:ef49f129-691d- 4e18-7a09-8dae8928aa7a'] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1462295/+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 1335901] [NEW] Allow fine grained control on cells actions
Public bug reported: Operators will often have a need to fine grain control over what actions are allowed on an extension. For cells, potentially destructive (as in when done mistakenly) actions should have better access/policy control. The following actions therefore should get better policy control on cells extensions. -Create -Delete -Update ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: New ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) -- 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/1335901 Title: Allow fine grained control on cells actions Status in OpenStack Compute (Nova): New Bug description: Operators will often have a need to fine grain control over what actions are allowed on an extension. For cells, potentially destructive (as in when done mistakenly) actions should have better access/policy control. The following actions therefore should get better policy control on cells extensions. -Create -Delete -Update To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1335901/+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
