Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-29
14:45:03 efried bhagyashris: otherwise, yes, that's the right approach. Were you able to get the test working with that setup?
14:48:06 bhagyashris efried: yes. and I have also tried on approach same as you suggested what i have did created the libvirt driver object in my FakeLibvirtDriver class and try to call the update_provider_tree() method using the libvirt object but i am getting error as File "nova/virt/fake.py", line 754, in __init__ super(FakeLibvirtDriver, self).__init__(virtapi, read_only) File "nova/virt/libvirt/driver.py
14:49:46 bhagyashris File "nova/virt/fake.py", line 754, in __init__
14:49:48 efried bhagyashris: It sounds like you're trying to instantiate the driver as a separate instance attribute within your fake driver class. What you should do instead is have your fake driver class be a *subclass* of the real virt driver class.
14:50:41 efried class FakeLibvirtDriver(LibvirtDriver):
14:51:35 efried Then you don't have to override update_provider_tree - which you want to avoid anyway, since then changes to the original method won't automatically be reflected in your test.
14:52:47 efried bhagyashris: Take a look at nova.tests.unit.virt.libvirt.test_driver.HostStateTestCase.FakeConnection
15:06:52 bhagyashris efried: But anyway In that case as well i will need to implement the update_provider_tree() method in my FakeLibvirtDriver right?
15:07:34 efried bhagyashris: No. That's the whole point. You want to use the implementation from the superclass.
15:12:23 bhagyashris efried: ok. just inherit the LibvirtDriver class in my FakeLibvirtDriver and give this FakeLibvirtDriver as copute_driver in test case
15:12:37 efried bhagyashris: Correct.
15:13:07 efried bhagyashris: You may have to override certain other methods with stubs to get the "deploy" to work.
15:15:21 bhagyashris efried: ok thank you :)
15:15:28 efried bhagyashris: Good luck :)
15:16:05 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec.RequestGroup versioned object https://review.openstack.org/568840
15:16:06 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267
15:16:07 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847
15:16:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
15:16:09 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459
15:26:03 gibi efried: ^^ I think I fixed/answered your concerns
15:26:18 efried gibi: ack. Still catching up, will get to it... soon?
15:26:40 gibi efried: most of the patches still lack of unit test
15:26:45 efried ack
15:27:28 gibi efried: you don't have to rush as I hope there will be some neutron code up this week as well and that could allow us to have some integrated test as wel
15:28:10 efried ack
15:57:10 openstackgerrit Jan Gutter proposed openstack/os-vif master: Add multiqueue field to VIFGeneric https://review.openstack.org/570959
16:12:51 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Avoid showing password in log https://review.openstack.org/561850
16:14:28 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Avoid showing password in log https://review.openstack.org/561850
16:14:52 openstackgerrit Lee Yarwood proposed openstack/nova stable/ocata: Avoid showing password in log https://review.openstack.org/561851
16:25:17 mgagne mriedem: what's the best way for me to review and test the allocation healer? I'm still running Mitaka. My understanding is that I would need to run a more recent version?
16:29:18 mriedem mgagne: yeah probably at least pike, although i'm not sure if any of the internal interfaces i'm using in that CLI have changed since then
16:30:09 mriedem mgagne: could be possible to setup a small pike test environment with the caching scheduler, create some servers, resize one or two of them, and then run the heal_allocations CLI
16:30:36 mriedem i can also test that out if/when i get some free time (first day back after the summit)
16:31:24 mriedem gibi: want to skip the notifications meeting today? i'm still getting caught up from last week
16:31:32 mgagne mriedem: I suppose master would be best? I can try to setup a test environment in our infra. It would however be a non-trivial amount of effort as I'm not familiar with devstack and would probably do it "our way".
16:32:22 mriedem mgagne: sure whatever you're most comfortable with is best
16:32:57 mgagne mriedem: alright, I will attempt to squeeze time for that.
16:33:12 mriedem great, thanks
16:34:58 mgagne mriedem: btw, regarding cellsv1 -> cellsv2, a light bulb lighten up at the summit. I was previously under the impression that you *had* to run cellsv2 in ocata and that cellsv1 was removing/non-compatible, making a migration impossible due to me requiring support for multi-cells.
16:36:07 mriedem nope
16:36:14 mriedem so you're 4.5% happier now right? :)
16:36:28 mgagne 99% ? =)
16:36:50 mriedem mgagne: our cells v1 CI job is still cells v1 with a single cell1 for the nova db in the child cell and cell0
16:37:01 mriedem it's not multiple child cells, but still cells v1
16:37:04 mgagne all that time... ^^'
16:37:50 mriedem cool, glad it's more clear now
16:42:05 mriedem jmlowe: did you get my 2nd email about checking the allocation records for the compute nodes that are failing to live migrate?
16:42:51 jmlowe I did, turns out my allocations are a mess
16:42:56 gibi mriedem: besides what I wrote in the summary mail today on the ML I have nothing else for the meeting
16:43:01 mriedem gibi: ok
16:43:06 jmlowe I cleaned up the double allocations
16:43:20 jmlowe then I found allocations on the wrong host
16:43:22 gibi mriedem: so I will open the meeting to see if somebody new shows up but will close it in 5 minutes
16:43:34 mriedem jmlowe: hmm, ok. still weird that the problem didn't show up with normal server create.
16:43:38 jmlowe I really could use that new force create of allocations
16:44:05 mriedem jmlowe: the force option mentioned in my heal_allocations patch?
16:44:23 jmlowe I'm whipping up something to check nova location vs placement allocation location
16:44:43 jmlowe yeah that, my current workaround is to delete then live migrate
16:45:47 mriedem ok. wonder how everything got so messed up in the first place, but like i said in the email, there were bugs in the pike GA regarding properly cleaning up allocations when something failed - those have all been fixed in stable pike point releases, but you could have had cruft from the GA
16:46:27 jmlowe I figure I've got no chance of things working as expected unless all of the placement allocations are correct
16:48:03 jmlowe I did have a thought, we do lots of shelving and unshelving, any chance allocations are getting correctly updated during unshelve?
16:48:24 jaypipes jmlowe: you mean shelve_offloading?
16:48:39 jmlowe yes
16:48:43 jaypipes jmlowe: because I don't believe shelving (without offloading) affects allocations. could be wrong though.
16:49:01 jaypipes shelve is possibly one of the worst designed things in Nova... </grumbling>
16:49:05 mriedem when we shelve offload, the allocations for the node on which the instance is running will be deleted
16:49:42 mriedem https://github.com/openstack/nova/blob/stable/pike/nova/compute/manager.py#L4496
16:50:07 dansmith he said "without offloading"
16:50:11 mriedem when you unshelve, you go through the scheduler which will create allocations against the selected destination host
16:50:44 mriedem where did he say 'without offloading'?
16:51:00 jmlowe Really need it for our workflows, scientist does data analysis and runs for several weeks, shelves and goes off to write up results, submits paper and waits a couple of months to hear back from reviewers, unshelves and reruns based on reviewers comments
16:51:01 dansmith <jaypipes>jmlowe: because I don't believe shelving (without offloading) affects allocations. could be wrong though.
16:51:02 mriedem jay said that
16:51:11 mriedem by default shelve offloads immediately
16:51:15 mriedem and removes allocatoins
16:51:18 dansmith yeah, I thought you were contradicting jaypipes' comment
16:51:33 mriedem no, i thought jay was asking for clarification
16:51:34 dansmith jaypipes: I learned something about the importance of shelve this summit by the way
16:51:41 mriedem to which jmlowe said "yes" to shelve_offload
16:51:46 jmlowe that default behavior is why I tend to drop the offloading when referring to it
16:51:51 dansmith jaypipes: related to my apparent misunderstanding of how AWS works
16:51:58 mriedem jmlowe: same here
16:52:15 mriedem jmlowe: so shelve / unshelve should be ok wrt allocations
16:52:44 mriedem https://review.openstack.org/#/c/494632/
16:52:57 mriedem that was in the pike GA also
16:53:01 jmlowe I'll start spot checking history once I get a list of all the errant allocations
16:53:52 cfriesen dansmith: I'll bite...what did you learn about shelve?
16:54:14 dansmith cfriesen: weren't you in that cyborg session?
16:54:51 cfriesen dansmith: if I was I missed the important bit. :)
16:55:34 dansmith cfriesen: that the AWS equivalent of our stop/start involves a reschedule and is actually a little more equivalent to our shelve(-offload) and unshelve in terms of freeing resources (and the associated billing)
16:56:19 cfriesen dansmith: ah, okay. makes sense. I never could figure out the logic of why we have stop/suspend/pause when they all still consume resources.
16:57:03 dansmith well, just lifecycle of a pet, but I had assumed we imported that from AWS for parity
16:57:58 jmlowe I'd kill for the ability to offline migrate a suspended instance btw
16:58:27 cfriesen jmlowe: should be technically doable.
16:58:55 jmlowe cfriesen: right, just move the definition and the file where the state is written?
16:59:34 cfriesen jmlowe: essentially. the resource tracking and wiring up the networking and storage and whatnot are the tricky bits
16:59:57 dansmith yeah, a little more complicated than that
16:59:58 dansmith I thought that cold migrate could do it though
17:00:31 cfriesen dansmith: if not, I bet it wouldn't be horrendous to add it
17:00:38 jmlowe haven't tried for a while

Earlier   Later