Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
10:24:55 bauzas whatever the object is
10:24:58 johnthetubaguy bauzas: so maybe if you pass the return value of placement into host_manger get, even if thats just the list of uuids, that would be better
10:24:59 alex_xu gmann: np, I drop in that trap also :)
10:25:02 johnthetubaguy bauzas: yeah, that sounds good
10:25:12 johnthetubaguy bauzas: right now its a dict, but thats OK for now I guess
10:25:18 bauzas johnthetubaguy: I can forge a patch soon
10:25:29 mdbooth pkoniszewski: Incidentally, I also wonderered about setting guest.migrate_configure_max_downtime() on every iteration, regardless of steps.
10:25:35 mdbooth Would that be expensive?
10:25:36 bauzas johnthetubaguy: and I'll wait for sean about how to discuss the grenade thing
10:25:58 bauzas because the issue I guess is that we don't default running the placement service in newton
10:26:11 johnthetubaguy bauzas: cool, hopefully that helps, just didn't quite read as I expected
10:26:13 gmann alex_xu: heh
10:26:14 bauzas so, when upgrading, it fails because the config file is not correctly setup
10:26:42 bauzas that would suppose we would modify the config between newton and ocata, but that's pretty high impacty
10:27:01 johnthetubaguy bauzas: honestly, we might just need to support not having placement while the min_service_version is below a threshold, and only start using it after that point?
10:27:20 bauzas johnthetubaguy: that's why I'm waiting the US folks to be up before engaging that convo
10:27:22 bauzas :)
10:27:43 bauzas lots of discussions went already around about the upgrade path
10:27:50 johnthetubaguy mdbooth: we still need something that sets QEMU occasionally on some periodic task, but thats a good point, you can just work out where you should be on the line, and set that value
10:28:07 johnthetubaguy bauzas: yeah
10:28:22 johnthetubaguy bauzas: just curious why we don't do it the usual way, but thats for later
10:28:38 bauzas johnthetubaguy: meaning be gentle with not having the placement service for newton ?
10:28:58 bauzas and gracefully fallback if we don't have the version supported ?
10:29:23 bauzas that's one option but the consensus was that it was okay to have a maintenance window
10:29:51 johnthetubaguy bauzas: well its not really a maintenance window right, its just if you want no outage, you have to do more work
10:33:04 openstackgerrit Radomir Dopieralski proposed openstack/python-novaclient: ListExtResource given in place of ListExtManager https://review.openstack.org/424570
10:38:23 bauzas johnthetubaguy: tried to summarize our convo in https://review.openstack.org/#/c/417961/19/nova/scheduler/client/report.py@212, just drop a note if you think I misunderstood our agreement
10:38:34 gmann alex_xu: johnthetubaguy oomichi additionalProperties=False saved us many times but this we only got under its hammer :)
10:38:34 bauzas meanwhile, writing a new iteration
10:38:49 gmann *this time
10:41:19 johnthetubaguy bauzas: we would pass resource providers uuids into the host manager I guess?
10:41:24 openstackgerrit Huan Xie proposed openstack/nova: Fix live migrate with XenServer https://review.openstack.org/424428
10:42:25 bauzas johnthetubaguy: I'm not opiniated on that
10:42:30 bauzas johnthetubaguy: that's fine to me
10:42:48 bauzas because a RP uuid is the compute uuid
10:42:51 johnthetubaguy bauzas: me neither, that just seems simplest at the moment
10:42:54 bauzas so I'd name it compute_uuids
10:43:16 bauzas just to make it clear that I'd never name something related to resource providers into the host manager
10:43:33 bauzas the hostmanager only knows hosts and returns host states
10:43:42 bauzas hence why I think you made an excellent and valid comment
10:43:52 bauzas because my current proposal sucked
10:44:12 johnthetubaguy bauzas: it wasn't that bad, but yeah, that sounds worth a try
10:44:25 bauzas johnthetubaguy: it was poorly designed, if you prefer
10:44:54 johnthetubaguy a class was operating on multiple levels of abstractions, causing some confusion, or something like that
10:45:10 bauzas the exact reason why I haven't yet written UTs :)
10:45:27 bauzas because I needed kind of an agreement on the interfaces before moving on
10:46:14 openstackgerrit Balazs Gibizer proposed openstack/nova: Fix race condition in instance.update sample test https://review.openstack.org/424574
10:47:43 openstack Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [Undecided,In progress] - Assigned to huan (huan-xie)
10:47:43 BobBall johnthetubaguy: https://bugs.launchpad.net/nova/+bug/1658877 - found a bug which prevents all XAPI live migrations and we'd really appreciate your input on it.
10:48:31 johnthetubaguy BobBall: I think I saw that patch pass by, will take a peak
10:48:45 BobBall Awesome, thanks.
10:49:30 johnthetubaguy BobBall: why did it work before without the vif mappings there?
10:50:07 openstackgerrit Matthew Booth proposed openstack/nova: libvirt: Fix races in glusterfs mount/umount https://review.openstack.org/423402
10:51:05 BobBall johnthetubaguy: The addition of the interim network to fix the neutron vlan tagging on vif/tap bug (and also to support neutron security groups) introduces a per-VIF network. The per-VIF network doesn't exist (by name) on the destination and therefore XAPI can no longer make a good guess for what the vif mapping should be.
10:51:43 johnthetubaguy BobBall: that would totally do it
10:52:09 BobBall johnthetubaguy: Indeed :(
10:53:20 johnthetubaguy BobBall: this isn't backportable, because of the object version stuff
10:53:29 johnthetubaguy as a heads up
10:54:02 BobBall Understood. I am trying to also understand whether we actually need to pass the mapping back; if we create a network with the same name on the target wouldn't XAPI just do the right thing(tm)?
10:54:21 BobBall Anyway - I'll put review comments in the code. Just wanted to highlight it for you as a heads up.
10:57:23 johnthetubaguy BobBall: why is the vif thing only used for VM.migrate_send?
10:57:36 johnthetubaguy BobBall: is it not accepted by the other call?
10:58:19 BobBall johnthetubaguy: Not needed for sure - it would probably be ignored if it was present.
10:58:32 BobBall johnthetubaguy: Good comment though, we can check the API to be sure.
11:01:20 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
11:05:03 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
11:07:39 dims sean-k-mooney : around?
11:07:56 dims sean-k-mooney : https://review.openstack.org/#/c/423718/ is ready. got the linuxbridge thing working
11:20:13 openstackgerrit Sylvain Bauza proposed openstack/nova: WIP: Scheduler calling the Placement API https://review.openstack.org/417961
11:20:57 bauzas johnthetubaguy: new iteration, comments welcome $
11:37:33 mdbooth pkoniszewski: Hey, I'm just looking at https://review.openstack.org/#/c/244489/
11:38:00 mdbooth Inevitably looking at live migration flow
11:39:29 mdbooth So, source does a call to destination.check_can_live_migrate_destination(), which itself does a call back to source.check_can_live_migrate_source(), and then the destination returns the result of the call to the source back to the source over rpc
11:39:57 mdbooth So we're calling check_can_live_migrate_source() on the source, sending the results to the destanation, which then sends them back to the source
11:40:08 mdbooth That seems a little inefficient :)
11:40:19 mdbooth Anyway, that's a problem for another day
11:41:08 mdbooth More immediately, I think there might be a deadlock if there's an exception in _do_check_can_live_migrate_destination, but I'd very much like a second opinion
11:42:12 mdbooth Although... I think I may just have provided my own :)
11:42:21 pkoniszewski mdbooth: its not source that calls check_can_live_migrate_destination
11:42:27 pkoniszewski but conductor
11:42:35 mdbooth Ah, es
11:42:43 mdbooth Ok
11:43:24 mdbooth It just seems like an additional source of potential failure
11:45:05 mdbooth Re the deadlock, I was thinking that the lock held by live_migration_claim would be held for the duration of the claim context, but of course it's only held whilst generating the claim
11:45:10 mdbooth There's no deadlock
12:01:29 johnthetubaguy mdbooth: its only partially implemented, compute <-> compute RPC traffic shouldn't be allowed, from a security point of view, so ideally you have the conductor own the task, and send messages to the two compute nodes as required, and monitor progress. But naturally we don't have any of that, just the bad bits
12:16:18 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot notifications https://review.openstack.org/382959
12:18:35 openstackgerrit OpenStack Proposal Bot proposed openstack/os-vif: Updated from global requirements https://review.openstack.org/395347
12:21:30 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.reboot notifications https://review.openstack.org/382959
12:41:33 openstackgerrit Moshe Levi proposed openstack/nova: Assign mac address to vf netdevice when using macvtap port https://review.openstack.org/424639
12:50:27 openstackgerrit Alex Xu proposed openstack/nova: Add new policy for server list/detail with all_tenants https://review.openstack.org/415330
12:51:07 openstackgerrit Neil Jerram proposed openstack/nova: libvirt: avoid generating script with empty path https://review.openstack.org/411936
12:51:23 openstackgerrit Alex Xu proposed openstack/nova: Add new policy for server list/detail with all_tenants https://review.openstack.org/415330
12:51:37 alex_xu johnthetubaguy: gmann ^ just done the policy one
12:53:10 openstackgerrit Alex Xu proposed openstack/nova: Add sort_key white list for server list/detail https://review.openstack.org/415142
12:57:01 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient: [CLI] Fix token auth type https://review.openstack.org/424256
12:57:40 openstackgerrit Stephen Finucane proposed openstack/nova: WIP: libvirt: Always enable firewall https://review.openstack.org/424647
12:57:40 openstackgerrit Stephen Finucane proposed openstack/nova: conf: Deprecate two more nova-net options https://review.openstack.org/412390
12:59:10 andreykurilin hi folks! there are several blocked projects(horizon, trove, cinder?!, murano-dashboard...) due to bug with token auth method. Here is a fix https://review.openstack.org/#/c/419441 . Functional tests are also attached there.
12:59:18 andreykurilin Please review as soon as possible

Earlier   Later