Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-29
14:00:54 openstackgerrit Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597
14:03:31 Kevin_Zheng It will be impossible to cover all the special strings because there could be so many for different file formats?
14:04:07 mriedem Kevin_Zheng: for starters, "we need a change upstream to fix a problem in our downstream fork of the API" isn't justification for anything going upstream
14:04:41 fishbone__ hello all, I receive an error in the instance log when loading windows instances: pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Session', 'Access is denied. ', None, 0, -2147024891), None) any probable causes?
14:05:02 efried Kevin_Zheng: You could use a restrictive instance name template...
14:05:02 mriedem also, i thought openstackclient already handled converting output to csv format
14:05:35 Kevin_Zheng really? I don’t know that, I will check that
14:05:43 mriedem efried: that's not the display_name https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.instance_name_template
14:06:46 mriedem Kevin_Zheng: how was this implemented? the client gives a csv accept header in the request and gets csv rather than json in the response?
14:07:33 Kevin_Zheng mriedem: No, I think it is a function that can output the results to a file
14:07:47 Kevin_Zheng Like a button
14:08:40 mriedem umm
14:09:26 Kevin_Zheng They just ask if it is possible to add some rules for instance names
14:09:27 mriedem that doesn't make sense to me
14:11:14 Kevin_Zheng Yeah, thinking again, even if we check on the name, something else could also trigger the function, like description
14:11:26 Kevin_Zheng We will never check on those
14:11:34 mriedem openstackclient has a --format csv option, not sure why your users wouldn't just use that, rather than change the api
14:11:57 mriedem and if you did change the api to return a different response format, it should have been via an accept header
14:12:07 mriedem as far as i understand rest api / http rules
14:13:03 Kevin_Zheng I have to check the details tomorrow about how it is actually implemented
14:17:07 Kevin_Zheng mriedem_away: another thing I need your help, I want to discuss with you before updating the abort migration in queue patch, how should I deal with migrations with status in “preparing”? My idea was to wait it change to “running” or “error” as we can already deal with “running” migrations and could could probably ignore “error” migrations. So I added that loop. What do you suggest?
14:43:41 bhagyashris efried: Hi, Want to discuss regarding functional test case part for the patch https://review.openstack.org/#/c/560459/ . What I did was created new FakeLibvirtDriver in nova/virt/fake.py implement the updat_provider_tree() method same as in nova/virt/libvirt/driver.py and given that compute_driver = 'fake.FakeLibvirtDriver' in functional test case
14:44:40 efried bhagyashris: Okay, instead of duplicating the code, FakeLibvirtDriver should be a subclass of the real libvirt driver.
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

Earlier   Later