| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-25 | |||
| 10:20:34 | johnthetubaguy | yeah, no soft delete in any of the api_db, I think | |
| 10:21:05 | gibi | johnthetubaguy: does the archiving process moves the instance mapping from the production table to the shadow table? | |
| 10:21:12 | gibi | johnthetubaguy: that could be a way to clean up | |
| 10:22:34 | johnthetubaguy | but that util doesn't have access to the api_db, generally | |
| 10:23:50 | johnthetubaguy | oh, wait, I was thinking about the instance moving to a shadow table, I didn't think we did shadow tables in the API db | |
| 10:24:13 | johnthetubaguy | I saw we had a non-shadow table archive, but I must have got mixed up | |
| 10:24:28 | johnthetubaguy | s/saw/swore/ | |
| 10:26:42 | gibi | johnthetubaguy: OK then I conclude that nova doesn't delete the instance mapping at all | |
| 10:27:08 | johnthetubaguy | gibi: thanks, I thought I was going a bit mad not being able to track that down | |
| 10:37:27 | masber | good afternoon, I am having an issue with nova where my instances are failing during building process | |
| 10:39:40 | masber | this is the error I can see running openstack server show command http://paste.openstack.org/raw/624579/ | |
| 10:46:43 | johnthetubaguy | masber: if you look at the original log, it has a request-id in there, you will want to search for other logs with that id in it, that will show you why you hit that error | |
| 10:54:04 | masber | johnthetubaguy, is this what you mean? http://paste.openstack.org/show/624582/ | |
| 11:05:10 | johnthetubaguy | masber: maybe, but I suspect you need logs from nova-conductor and other services, using that request-id (although I don't see the no valid host error log in there) | |
| 11:05:35 | masber | oh ok | |
| 11:05:40 | masber | I just checked the scheduler | |
| 11:05:53 | johnthetubaguy | masber: should really move to the #openstack channel I guess, its more operator focused than dev | |
| 11:05:53 | masber | let me see other log files | |
| 11:09:08 | masber | johnthetubaguy, ok I got a permission denied http://paste.openstack.org/raw/624585/ | |
| 11:09:53 | johnthetubaguy | masber: ah, cool, that sounds like the root cause | |
| 11:10:48 | masber | how weird | |
| 11:11:52 | ttsiouts | hey guys! I started investigating this bug report: https://bugs.launchpad.net/nova/+bug/1644457. was there a decision that a user's keypairs in_use should not be counted by the cli: nova quota-show --user |
|
| 11:11:53 | openstack | Launchpad bug 1644457 in OpenStack Compute (nova) "keypair quota error" [Medium,Confirmed] - Assigned to Theodoros Tsioutsias (ttsiouts) | |
| 11:29:54 | efried | masber You'll probably want to check your compute logs. Is the compute service started? | |
| 11:40:26 | efried | bauzas naichuans https://review.openstack.org/#/c/514942/ ++! I was poring over this code last night and it made me realize how important this is going to be. | |
| 12:01:13 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: nova-manage cell_v2 verify_instance returns a valid instance mapping even after the instance is deleted/archived https://review.openstack.org/515034 | |
| 12:13:14 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138 | |
| 12:13:15 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 12:13:15 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 12:13:16 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 12:13:58 | efried | cdent dansmith Took the liberty of fixing that nit since Jay's still out and the patch is now the first one in the series ^ | |
| 12:14:19 | cdent | ✔ | |
| 12:20:14 | cdent | efried: on the vgpu stuff, I get that you want to be able to change stuff you can’t express elsewhere, and that we want that | |
| 12:20:38 | cdent | but doesn’t it also make it so the flavor can express VCPU: 2 and then the extra spec can say VCPU: 4 | |
| 12:21:00 | efried | cdent That was already the case, intentionally. The extra spec overrides. | |
| 12:21:23 | cdent | I thought the previous behavior was only that the extra spec could set to 0? | |
| 12:21:27 | efried | cdent This was done so that we could move toward the extra spec resources being the single source of truth for all resource requests. | |
| 12:21:36 | efried | uh, stand by... | |
| 12:21:50 | cdent | (for _standard_ classes) | |
| 12:22:18 | efried | cdent No, you could override too. | |
| 12:22:41 | cdent | Basically what I’m trying to understand is if we are making it so there are now two places to do things, and if so, is the plan to end up on only one. If there is, cool. | |
| 12:22:42 | efried | Setting to 0 would remove it. Presumably this is so you could e.g. provide disk resource from somewhere else, but you can't create a flavor with disk 0. | |
| 12:23:52 | cdent | I hope some day we will just destroy flavors as an internal concept and they will only be a UI thing. | |
| 12:23:53 | efried | cdent The plan is to be able to express all resources from one place. We didn't want to (couldn't) do that by adding every standard and custom resource class to the main flavor object. So we want to do it via specific namespacing in the extra_specs because it's a freeform grab-bag. | |
| 12:24:44 | efried | cdent I don't know what the ultimate fate of the flavor object will be. But I don't disagree that it's kind of a mess atm. | |
| 12:24:57 | efried | not least because we're transitioning to this generic resource management ideal. | |
| 12:27:18 | cdent | you got the golden ticket | |
| 12:27:25 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526 | |
| 12:32:31 | efried | alex_xu yt? | |
| 12:32:48 | jmccarthy | Is there some config or option needed for console.log to work in horizon ? At the moment I'm finding with cirros it works, but with OL7 it doesn't ? The xml of the two instances looks very similar | |
| 12:33:08 | jmccarthy | But in the OL7 case, the console.log is 0 size file | |
| 12:33:16 | jmccarthy | (similar permissions etc) | |
| 12:41:05 | cdent | efried: I hate resorting to mocks in functional tests. (Or really in any tests) | |
| 12:41:26 | efried | cdent Oh, was that a functional test, yeah, don't mock stuff there. | |
| 12:41:30 | cdent | but if you like I’m happy to add that in if we want to be sure, but *shrug* | |
| 12:41:39 | efried | Nah, I +1ed. | |
| 12:41:54 | cdent | k3wl | |
| 12:45:18 | alex_xu | efried: yea, i'm here | |
| 12:45:40 | alex_xu | nova api meeting is in 15 mins at #openstack-meeting-4 | |
| 12:47:20 | efried | alex_xu I wanted to talk through that SQL boggle. I'm writing up a comment... | |
| 12:49:06 | alex_xu | efried: yea | |
| 12:59:49 | sean-k-mooney | stephenfin: qq just set up one of my lab vms with an irc client. does my nick ectra look normal. i might set up a znc bouncer at the weekend instead but it windows reboots are getting to be a pain. | |
| 13:00:14 | stephenfin | sean-k-mooney: All good here, yup | |
| 13:00:26 | sean-k-mooney | cool | |
| 13:06:16 | mriedem | dansmith: tonyb gave his blessing https://review.openstack.org/#/c/514685/ | |
| 13:12:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Import the config drive docs from openstack-manuals https://review.openstack.org/515053 | |
| 13:12:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Import user-data page from openstack-manuals https://review.openstack.org/515054 | |
| 13:32:37 | efried | dansmith mriedem This migration UUID business - is that going to get rid of the "doubling up" that makes remove_provider_from_instance_allocation necessary? | |
| 13:33:19 | mriedem | efried: sort of | |
| 13:33:41 | mriedem | efried: the scheduler will pick a dest host and double the instance allocations between the source and dest host, | |
| 13:33:48 | mriedem | then conductor will swap the source node allocation with the migration record | |
| 13:34:02 | mriedem | so the instance will have an allocation on the dest host, and the migration will have an allocation on the source ohst | |
| 13:34:04 | mriedem | *host | |
| 13:34:46 | mriedem | as i pointed out in https://review.openstack.org/#/c/506420/ this morning, until we have cdent's POST allocations stuff, we'll actually be quadrupling the allocations temporarily when resizing to the same host | |
| 13:34:54 | dtantsur | hi mriedem! do I get it right that we're past spec freeze? people ping me re https://review.openstack.org/#/c/449155/, do they have to move it to Rocky at this point? I also wonder if that even needs a spec, but dunno | |
| 13:35:52 | mriedem | dtantsur: i think any move operation involving the ironic driver is going to require a spec yes, simply because of the resource tracking considerations that have to be made with the 1:M host:node mapping with ironic | |
| 13:36:03 | efried | mriedem Okay, so there will still need to be some affordance for adjusting doubled (or quadrupled) allocations for the forseeable future. | |
| 13:36:15 | mriedem | dtantsur: because we have assumptions all over nova when getting compute nodes from the db with only the host that there is only 1 node because we're not supporting moves with ironic yet | |
| 13:36:28 | mriedem | efried: yes, per the FIXME note from dan in that change | |
| 13:36:38 | mriedem | the FIXME means replace that with cdent's POST allocations stuff | |
| 13:36:54 | cdent | just in the midst of writing the docs for that stuff | |
| 13:36:58 | efried | mriedem The problem is in the way we're discovering how much adjustment to make, and to which RP. At the moment the code assumes in several ways that there's only one RP - the compute node. | |
| 13:36:59 | dtantsur | mriedem: mm, this is something I've never considered | |
| 13:37:34 | mriedem | dtantsur: also, | |
| 13:38:05 | mriedem | we have a spec from takashin to pass a dest host for cold migration, and that won't really work for ironic because you're only passed the host in the api, not the host+node | |
| 13:38:30 | mriedem | today when the admin specifies a host, we just take the ComputeNodeList[0] entry b/c we assume it's not an ironic instance | |
| 13:38:39 | dtantsur | yep, I think the plan was to let nova find a host | |
| 13:39:01 | mriedem | find a node? | |
| 13:39:10 | mriedem | the admin specifies a host, nova just randomly picks a node | |
| 13:39:28 | mriedem | well, i guess i'm thinking of the force case with live migration and evacuate | |
| 13:39:46 | mriedem | for cold migration we said we wouldn't add a force option, so you can specify a host and we'll still go through the scheduler to find a node | |
| 13:40:05 | mriedem | evacuate + forced host + ironic is probably totally busted though :) | |
| 13:40:58 | dtantsur | yep :) | |
| 13:41:26 | dtantsur | we were discussing cold migration + resize in context of nova. I was under impression this may work | |
| 13:41:36 | dtantsur | well, assuming people boot from volume and do not rely on local disks too much :) | |
| 13:41:55 | dansmith | mriedem: his question was if it'll remove the need for that special allocation-slicing thing and it will | |
| 13:42:25 | dansmith | mriedem: once we're past queens we won't have any of that | |
| 13:43:04 | mriedem | dansmith: the scheduler still picks the dest host and makes the doubled allocation yeah? | |
| 13:43:06 | dtantsur | mriedem: anyway, could you please leave a short comment on that spec with the freeze status and the question you'd see covered? | |
| 13:43:06 | mriedem | for the instance | |