Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-17
15:06:00 johnthetubaguy mriedem: there is no conflict there, AFAIK, I thought it was just on the operations os-brick does on the hypervisor (and the operations cinder does on delete_attachment and update_attachment)
15:06:51 efried sean-k-mooney Can do; though I'm not sure I'm qualified to +1 it.
15:07:12 johnthetubaguy mriedem: although I think I see what you mean now
15:07:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Reproduce bug 1724172 in the functional test env https://review.openstack.org/512553
15:07:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.openstack.org/512552
15:07:32 openstackgerrit Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623
15:07:32 openstack bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer)
15:08:04 johnthetubaguy mriedem: I guess we must have assumed a separate connection from each hypervisor, which doesn't seem quite correct
15:08:34 sean-k-mooney efried: well if you have concers about the proposal or the wording others probably do too so adressing those in the spec makes it better in general
15:08:49 efried sean-k-mooney Agree. I'll give it a full pass later today.
15:08:57 ericyoung the scaleio imagebackend patch has been updated and gotten through CI if anyone wants to take a look
15:08:59 ericyoung https://review.openstack.org/#/c/407440/
15:11:32 cdent edleafe-: I don’t understand you caffeine comment. So I tried to clarify.
15:15:09 edleafe cdent: "Is this a candidate for on the Selection object?"
15:15:18 edleafe "for on" was the confusing bit
15:16:02 cdent “Is this method a candidate for on the selection object?”
15:16:38 cdent but yes, the caffeine is broken today
15:16:42 cdent bad vintage or something
15:16:51 edleafe To answer your clarification, there was pushback on adding too much stuff to the Selection object. It could easily be there instead of the scheduler manager. The only preference is that it would never be used outside of the scheduler manager.
15:21:53 openstackgerrit Eric Fried proposed openstack/nova-specs master: Granular Resource Request Syntax https://review.openstack.org/510244
15:22:21 cdent edleafe: if it’s only ever used the scheduler manager then yeah, there seems fine.
15:22:24 efried dansmith -10% ^
15:23:30 dansmith efried: standard negotiation tactic is expect being able to knock 10% off, so that seems substantial
15:23:48 dansmith efried: on a call now but I'll look in a bit
15:23:54 efried nod, thx
15:28:55 mriedem ildikov: johnthetubaguy: ok my comments inline https://review.openstack.org/#/c/499777/
15:29:04 bauzas mriedem: gibi: I have some concerns by seeing duplicate code in https://review.openstack.org/#/c/510938/5/nova/compute/manager.py
15:29:31 mriedem bauzas: duplicate with what?
15:29:33 mriedem the RT?
15:29:38 bauzas mriedem: yup
15:29:47 bauzas delete_alloc_for_moved()
15:29:47 mriedem that's intentional
15:29:49 bauzas I know
15:29:57 bauzas but that's still duplicate
15:30:04 bauzas even if intentional :p
15:30:05 mriedem bauzas: see PS2
15:30:44 bauzas mriedem: I agree with your point to not call the RT method
15:30:55 bauzas mriedem: but we have a compute.utils helper module AFAIK
15:31:26 bauzas my main concern is that a modification would require two places
15:32:25 mriedem the only duplication is L698-L706 https://review.openstack.org/#/c/510938/5/nova/compute/manager.py
15:32:35 bauzas I agree
15:32:51 mriedem :)
15:32:51 mriedem whch is also in _delete_allocation_after_move now
15:33:03 mriedem and _rollback_live_migration
15:33:17 bauzas mriedem: but what if someone wants to add another call ?
15:33:33 mriedem so how about we do the consolidation into a util in a follow up?
15:33:47 bauzas I'm fine with that
15:33:50 mriedem hell, we could just do a private method inthe compute manager itself
15:33:52 bauzas I haven't reviewed the change
15:33:53 mriedem if you don't want to touch the RT
15:34:03 bauzas I just wanted to open a discussion
15:34:26 mriedem i'm cool with refactoring out the duplication, but not in this change since it has to be backported
15:34:27 bauzas but yeah, if we were doing the consolidation, would be worth doing all of it in a single patch
15:34:35 bauzas that's a good point
15:34:47 bauzas ok, I'll leave a comment and +W
15:45:02 mriedem bauzas: if you've got the time, we also need these stable/pike backports https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike+topic:bug/1715182
15:45:15 mriedem lyarwood: ^
15:45:27 bauzas mriedem: lyarwood is off sick
15:45:38 mriedem too much volume encryption will do that
15:47:15 bauzas I have an internal meeting until 4pm UTC, so I guess I have 13 mins of free time now :)
16:00:04 melwitt mriedem: I'm okay with this libvirt driver change now, to detach and reattach volumes during reboot. apparently there have been summit and PTG discussions about doing that in hard reboot for some time, so if that's the plan anyway, it seems fine to me https://review.openstack.org/#/c/400384
16:00:36 mriedem i don't remember those discussions
16:02:36 dansmith I do, it was around the need to re-fresh the connection info for monitor ip changes, IIRC
16:02:54 mriedem that's not this though
16:04:16 dansmith I haven't looked at the patch, but okay
16:04:31 dansmith we did talk about re-building the storage connections on reboot for that reason though
16:05:21 mriedem yeah i remember that, and have the todo for it still
16:08:09 mriedem ok so we have an encrypted volume test in tempest, i could just modify that to hard reboot the instance after an ecrypted volume is attached and it should blow up the instance right?
16:08:10 dansmith efried: did alex_xu get everything resolved that he was concerned about on that spec? I saw a bunch of discussion here
16:08:40 melwitt mriedem: I think so, yes
16:09:02 mriedem melwitt: ok in that case i'm going to tweak tempest to recreate the failure and then make it depend on the nova fix
16:09:30 mriedem melwitt: jbernard: https://review.openstack.org/#/c/512622/ is passing
16:09:38 mriedem we need to get that in asap to unblock nova stable
16:09:43 mriedem jdurgin: ^
16:09:59 melwitt mriedem: sounds like a good idea
16:10:25 melwitt mriedem: you did a Depends-On to see it pass on stable?
16:10:59 mriedem melwitt: i can quick
16:11:25 melwitt okay, just wanted to make sure that's going to work for you
16:11:47 efried dansmith Not really. We need another writeup. OTP, give me a few mins.
16:11:53 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: libvirt: add check for VIR_DOMAIN_BLOCK_REBASE_COPY_DEV https://review.openstack.org/512406
16:11:55 mriedem melwitt: ^
16:12:10 dansmith efried: more in this spec? i thought he was suggesting another spec.. but sure, np
16:13:56 efried dansmith Which spec are we talking about?
16:14:19 dansmith efried: your granular request word-a-palooza
16:16:24 efried dansmith Oh, no, that should be solid as is. Whatever else needs to come out of that will have to go... somewhere else.
16:16:45 dansmith efried: okay that's what I thought, but wanted to clarify
16:17:00 dansmith so I was going to drop my +2 on there, but didn't want to if alex_xu had more things implied from his +0 earlier
16:33:20 jbernard mriedem, melwitt: +A'd, thanks ya'll
16:33:50 melwitt jbernard: awesome, thanks
16:33:55 mriedem sean-k-mooney: comments inline https://review.openstack.org/#/c/502306/
16:34:15 mriedem sean-k-mooney: honestly i think that's going to be a very tough mountain to climb at this point given all of the dependencies
16:34:32 mriedem sean-k-mooney: there seems to be a fundamental mistaken assertion in there that nova creates ports before a host is chosen
16:34:34 mriedem which is not the case
16:34:45 mriedem jbernard: thanks
16:35:12 sean-k-mooney mriedem: i taught nova called the create_or_get port api before calling placement?
16:35:40 mriedem sean-k-mooney: no, ports are created during allocate_for_instance in the compute service
16:35:40 sean-k-mooney mriedem: but thank for reviewing. yes this does have a lot of dependncies
16:35:44 mriedem after a host is chosen by the scheduler
16:36:13 mriedem johnthetubaguy has an older spec to move port creation to conductor, which might be another dependency for this
16:36:33 mriedem sean-k-mooney: isn't the qos policy applied to the port?

Earlier   Later