Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-21
21:43:06 mriedem i thought there was a thing where you couldn't resize/migrate ephemeral/swap disks?
21:43:09 mriedem am i making that up?
21:45:41 mriedem similar https://bugs.launchpad.net/nova/+bug/1755266
21:45:41 openstack Launchpad bug 1755266 in OpenStack Compute (nova) "Instance resize with swap on cinder volume fails" [Undecided,New]
22:02:09 openstackgerrit Julia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call https://review.openstack.org/554762
22:02:34 sean-k-mooney[m] mriedem: i believe its undefined behavior if you change the number of ephemeral disk on resize. Migration of swap is fine. Resize is not
22:03:32 sean-k-mooney[m] Actually swap resize should be fine since we basically reboot
22:04:40 openstackgerrit Michael Still proposed openstack/nova master: Remove duplicative implementation of temporary directories. https://review.openstack.org/554791
22:04:40 openstackgerrit Michael Still proposed openstack/nova master: Use a pythonic delete. https://review.openstack.org/554792
22:04:41 openstackgerrit Michael Still proposed openstack/nova master: Use a pythonic delete, with a retry. https://review.openstack.org/554793
22:05:30 melwitt mriedem, dansmith: finally tracked down what's going on in the bug where after upgrading the pike, if there are service records with no uuid (from the N-1 version), they get the "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" error
22:05:45 melwitt explained it here https://bugs.launchpad.net/nova/+bug/1746509/comments/9
22:05:46 openstack Launchpad bug 1746509 in OpenStack Compute (nova) "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" [Medium,Confirmed]
22:06:06 mriedem sean-k-mooney[m]: i seem to remember diana clarke trying to fix something wrt swap disks and resize, found https://github.com/dianaclarke/openstack-notes/wiki/resize-disks but not the thing she was trying to fix
22:06:09 melwitt the good news is it's no longer a bug in queens or rocky, but it is a bug in pike
22:08:01 melwitt is it cool if I propose a fix only for pike? how does that usually work?
22:08:44 dansmith melwitt: ah yeah that sort of nesting is exactly what I was saying would have to happen, but was skeptical of it existing
22:08:54 dansmith melwitt: so.. glad you traced it all the way down :)
22:09:05 cfriesen mriedem: what about this? https://bugs.launchpad.net/nova/+bug/1552777
22:09:07 openstack Launchpad bug 1552777 in OpenStack Compute (nova) "resizing from flavor with swap to one without swap puts instance into Error status" [Medium,In progress] - Assigned to Kam Nasim (knasim-wrs)
22:09:07 dansmith melwitt: mriedem would know better than me, but we've had to do that before, IIRC
22:09:20 mriedem reminds me of https://review.openstack.org/#/c/507854/
22:10:07 cfriesen mriedem: though it looks like that one went away in pike
22:10:43 sean-k-mooney[m] Cfriesen resize with swap is picky. I think it works more or less now
22:10:50 melwitt dansmith: yeah, initially I couldn't repro it (as expected) with only a service query. but yeah, got to the bottom of it :) I think it could be easily fixed by just splitting the _make_instance_list call out from under the _get_by_filters_impl, that is, move it to get_by_filters
22:11:30 dansmith melwitt: okay, I just read your comment but I didn't go look at the (old) code to see, but.. sounds good? :)
22:11:52 melwitt dansmith: yeah, just chattering aloud. I'm excited that this makes sense now
22:12:28 dansmith melwitt: I will put a dan dummy in my chair who will continue to listen to your chattering. he doesn't type though, so just assume he's saying "uh huh, yeah, oh. sounds good. uh huh, yeah..."
22:12:47 melwitt haha
22:13:03 dansmith mriedem: and no snide comments from you mister.
22:13:42 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081
22:15:51 mikal pick me pick me!
22:15:59 mriedem i'd have to see the proposed fix
22:16:01 mikal Basically snide comments is all I do now.
22:17:36 melwitt Snide Comment Czar
22:17:38 mriedem melwitt: so you want to move this call to _make_instance_list from here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1235 to right after _get_by_filters_impl is called here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1243 ?
22:17:51 mikal I would accept that job
22:18:01 mikal Or anything entitled "Old man shakes fist at clouds"
22:18:04 melwitt mriedem: yeah, that's what I'm trying right now. already have the func test written. let's see if it works
22:19:56 melwitt yay
22:23:50 mriedem so why couldn't we just also make this change on master and backport it?
22:24:01 mriedem even if it's not a problem on master,
22:24:06 mriedem would changing the same code cause any problems?
22:24:50 melwitt oh yeah, that's a better idea actually
22:25:08 melwitt when I first asked, I wasn't thinking the code was going to be the same on master but it is
22:26:15 mriedem dansmith: it would be best if your dan dummy looked like https://www.youtube.com/watch?v=_WQfZYacEAw
22:26:20 melwitt I'll have to rewrite this func test a bit to be a regression func test that will still fail on master. not a big deal
22:26:44 mriedem melwitt: writing a test on master to fail for a thing that doesn't fail on master...breaks my brain
22:26:44 dansmith mriedem: what else would it look like?
22:27:10 mriedem unless you're not going to reproduce it through the API
22:27:22 mriedem but just through the object methods directly
22:27:36 melwitt mriedem: sorry, it will fail on master in an artificial scenario that isn't currently being run. yeah, I don't think I can reproduce it through the API, from what I've seen so far
22:27:58 openstackgerrit Matt Riedemann proposed openstack/nova master: List instances performace optimization https://review.openstack.org/507854
22:28:07 melwitt but calling InstanceList.get_by_filters with expected_attrs=['services'] with a service record with no uuid should do it
22:28:20 mriedem that'd be fine then
22:28:31 melwitt k, doing
22:28:49 mriedem i'd like to note that i can't remember the last time i've had so many "is this appropriate for stable" conversations in the same week
22:29:04 melwitt Stable Czar
22:29:19 mriedem i would like to avoid the term "czar" for anything
22:29:25 mriedem or tsar
22:29:27 melwitt yeah, good point
22:29:28 mriedem or caesar
22:30:08 mriedem isn't the point of czar kind of that there is only one anyway...
22:30:30 melwitt I dunno. years ago there was a czar for everything and I was thinking back to that
22:30:44 mriedem i got the reference, i just never liked that
22:30:58 mriedem https://wiki.openstack.org/wiki/Nova#People
22:31:35 melwitt yeah, same. I guess it stuck in my brain though
22:31:43 dansmith mriedem is the sarcasm czar whether he likes it or not
22:31:48 dansmith sorry mikal
22:34:30 mriedem cfriesen: heh https://bugs.launchpad.net/nova/+bug/1754782
22:34:31 openstack Launchpad bug 1754782 in OpenStack Compute (nova) "we skip critical scheduler filters when forcing the host on instance boot" [Undecided,Opinion]
22:34:39 mriedem "nova put the instance on the host where i told it to"
22:35:15 mriedem cfriesen: if you haven't realized it yet, the RUN_ON_BUILD = True thing is not something we enjoy having in the scheduler
22:35:22 mriedem *RUN_ON_REBUILD
22:35:44 mriedem also, remember the -5 to forcing a host during cold migration
22:35:57 cfriesen mriedem: so why don't we just run all the filters and only evaluate the specified hostname?
22:36:30 cfriesen other than "because that's how we've always done it"
22:36:45 mriedem ask bauzas
22:37:04 mriedem he talks at least semi-annually about changing the forst host/node stuff in server create to be a 'requested' destination
22:37:19 mriedem evaluated by the scheduler
22:37:20 cfriesen do it
22:37:21 cfriesen ;)
22:37:34 mriedem that would be a microversion of course
22:37:52 mriedem which i'd be ok with, it would be like passing a host to evacuate or live migrate
22:37:56 mriedem and cold migrate now i guess
22:38:22 cfriesen did we do a microversion when we started prefiltering via placement when forcing the destination?
22:39:09 cfriesen I guess it's the claim in placement that I mean, not the prefiltering
22:41:42 mriedem no, but i don't buy that argument
22:41:50 mriedem i believe you could still fail the claim in the compute even if you force
22:42:27 mriedem but i might be wrong, as i think the filters add the limits to the dict that gets passed down from scheduler to compute
22:43:10 mriedem anyway, we have to claim in placement (Create the allocations) otherwise our tracking gets all screwed up, so i don't feel bad about breaking the 'force host' contract there
22:43:56 cfriesen I think the limits happen after the filters...but in any case I get that we don't want to change behaviour without a microversion even if we never really defined the behaviour.
22:44:23 mriedem the limits dict is passed from the scheduler down through conductor to the compute
22:44:25 mriedem and used for the claim
22:44:34 mriedem the limits dict in the scheduler is i believe populated via the filters
22:45:03 mriedem which is why we can't remove the old school claim stuff in compute until we at least drop something like the caching scheduler, which doesn't use placement and relies on the late ass claim
22:46:49 cfriesen I think you're right...I see the filters updating host_state.limits
22:46:56 mriedem guh, i've triaged at least 2 bugs like this today https://bugs.launchpad.net/nova/+bug/1754543
22:46:57 openstack Launchpad bug 1754543 in OpenStack Compute (nova) "not update request_spec.request_networks after attach or detach interface" [Undecided,Invalid] - Assigned to Deepak Mourya (mourya007)
22:47:06 mriedem "request spec isn't what i expect it to be"

Earlier   Later