Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-04
13:33:44 mike99201 could that be a reason that conductor service starts find and connects to rabbitmq, but when i launch an instance i'm getting invalid credentials when connecting to rabbitmq?
13:33:57 mike99201 i've changed the password between the time the database was setup and now
13:36:15 jaypipes mike99201: no, I don't think that's an issue. Instances cannot connect to the infrastructure message bus.
13:36:20 jaypipes (by design)
13:36:24 efried naichuans: Hi there. I'm still having trouble seeing the reserved=total case. Since you're online, perhaps you can explain it?
13:36:25 dansmith mike99201: yes
13:36:39 dansmith mike99201: if you changed it in the config and in rabbit after that DB was setup, you need to update the db
13:36:54 mike99201 should I update the database, or can I just delete/recreate it
13:37:19 dansmith update
13:37:30 mike99201 thanks, I'll give it a try
13:44:43 openstackgerrit Chen proposed openstack/nova master: Fix some inconsistencies in doc https://review.openstack.org/570407
13:45:12 efried jaypipes: In case you were in the middle of looking at the xen thing, I just posted some responses.
13:50:18 bauzas jaypipes: dansmith: I tried to follow your convo for the upgrade thread, but could you please give me the consensus ?
13:52:53 efried bauzas: We're trying to figure out a way to do the upgrade smoothly, in-band, without a separate script.
13:53:32 bauzas efried: by having a new API ?
13:53:32 efried bauzas: It starts with the algorithm I suggested, which is having the virt driver, via update_provider_tree, indicate which resource classes have "moved" from one provider to another.
13:54:04 efried bauzas: Then jaypipes pointed out some race conditions in that algorithm that we can resolve via a new placement API, yes.
13:54:15 efried bauzas: The latter is being worked at https://etherpad.openstack.org/p/placement-migrate-operations
13:55:01 efried brb
14:00:26 mriedem alex_xu_: i have a couple of questions regarding server query parameter validation in this trusted certs patch https://review.openstack.org/#/c/486204/101/nova/api/openstack/compute/schemas/servers.py
14:00:48 alex_xu_ mriedem: yea
14:00:55 mriedem tomorrow if you get a chance
14:02:36 mriedem dansmith: we should probably talk about this in the trusted certs series https://review.openstack.org/#/c/561262/17/nova/virt/driver.py@134
14:03:49 dansmith mriedem: you know that is just under my name because I split their patch up right?
14:04:10 mriedem yes, but that's not why i'm bringing it up with you specifically
14:04:26 mriedem it's because you and i talk about this same type of thing quite a bit
14:04:58 dansmith okay just checking
14:05:11 dansmith I'm trying to figure something out but I'll go read that comment in a bit
14:06:41 melwitt sahid: hi, just wanted to double check with you that https://blueprints.launchpad.net/nova/+spec/overhead-pin-set has had all related changes merged and okay to mark as complete?
14:09:47 mriedem the other thing that bothers me with the trusted image certs stuff is that by default the policy allows anyone to specify trusted cert image IDs when creating a server, but the default config says that image validation isn't enabled
14:10:44 mriedem the config option just says,
14:10:45 mriedem certificate used to generate the image signature is still trustworthy."
14:10:45 mriedem occur but the end user will not have any assurance that the signing
14:10:45 mriedem "If left disabled, image signature verification can still
14:10:49 openstackgerrit MultipleCrashes proposed openstack/nova master: Retry decorator fix for autoscale delete https://review.openstack.org/563418
14:11:20 mriedem the end user isn't going to have any idea if the cloud is configured to validate image certs
14:11:51 mriedem i guess if you just aren't going to support trusted certs in your cloud at all, you should disable the feature by policy so the user can't pass those into server create and rebuild?
14:12:38 dansmith yeah I mean I dunno what else to tell them to do.. maybe we log a warning if the config and policy don't match?
14:12:48 dansmith so they know they're advertising a bad setup?
14:13:18 alex_xu_ mriedem: replied
14:13:34 mriedem alex_xu_: thanks
14:14:29 sahid melwitt: yep you can mark it as completed
14:14:37 alex_xu_ np
14:14:49 sahid melwitt: there is also the vf-trusted one
14:15:06 mriedem sahid: i completed that on friday
14:15:19 sahid ah ok i did not notice
14:16:11 melwitt sahid: cool, thanks for confirming
14:22:25 jangutter Is it possible I could add a spec to the review queue for tomorrow?
14:22:56 naichuans efried: Hi, Eric
14:23:09 efried naichuans: hello
14:24:30 mriedem dansmith: ok there is a bug in the libvirt plumbing patch too, and it looks like the barbican plugin test for this certs stuff isn't enabling cert validation either, which is probably how it was passing CI https://review.openstack.org/#/c/515210/
14:24:36 mriedem so :(
14:27:01 naichuans efried: I do the modification when we discuss the case: customers modified nova.conf, changed the vgpu type. If the gpu already has a vgpu with the previous vgpu type, we can't allocate new gpu type instance(becase we only support one vgpu type per gpug), so we set `reserve` = `total` to prevent scheduling.
14:28:08 efried naichuans: So help me understand which part of the code is detecting old vs new vgpu type. That's the part I'm missing.
14:28:52 naichuans efried: Now we check inventory change to determine if there is vgpu configure changes
14:29:08 efried but inventory changes when you allocate a vgpu
14:29:18 naichuans No
14:29:22 efried no???
14:30:17 naichuans inventory only contains the vgpu type, total, such kinds of features, no resource count
14:31:27 naichuans resouce amount related information is include in allocation(about used), and the real time host states from hypervisor
14:31:35 melwitt mriedem: it looks like the -W can be lifted from this patch now https://review.openstack.org/568382 and the rest of the series be reviewed for the ocata release https://review.openstack.org/571522
14:35:44 naichuans efried: check inventory define in the patch, we only have `total` field, no `remain`
14:36:07 naichuans fields.ResourceClass.VGPU: {
14:36:08 naichuans 'step_size': 1,
14:36:08 naichuans 'max_unit': 1,
14:36:08 naichuans 'min_unit': 1,
14:36:08 naichuans 'total': grp_value['total'],
14:36:09 naichuans }
14:36:11 naichuans }
14:36:46 efried naichuans: I understand that 'remaining' comes from the hypervisor.
14:37:32 naichuans vGPU type changes would effect total and display heads, I will add traits detecting code in the following patches
14:38:21 naichuans effect -> affect. sorry
14:38:48 efried (wow, that's one English speakers have trouble with :)
14:39:19 efried naichuans: Okay, so the key here is has_inventory_changed - meaning, is the inventory in the provider tree different from the inventory you expect...
14:39:28 efried let me stare at this for a sec...
14:40:19 naichuans efried: almost
14:40:51 efried naichuans: So you're using has_inventory_changed to detect that the vgpu type is different? That's the part that doesn't make sense to me.
14:41:17 efried Surely there are vgpu types that will have the same total as each other.
14:41:26 efried so that check won't do anything.
14:41:49 efried I would expect if you're trying to detect a changed vgpu type, you would be looking for the grp_id to be different.
14:42:46 efried see, at the moment, your condition says "the resource provider for the expected grp_id already exists, but its inventory total isn't what I expected. Let's see if anything is allocated. Okay, it is - let's disable this GPU."
14:42:54 naichuans The check is for the gpug with same uuid
14:43:14 efried does that correspond to a distinct gpu type?
14:43:21 efried or vgpu type?
14:44:07 naichuans almost means it is the same gpug, but there is configure changes on it. we can't support vgpu type checking, jianghua and jay has reject this field
14:45:05 mriedem melwitt: we don't run the nova-lvm job in ocata, so not sure if we should hold and backport/verify that? if even in a WIP patch. note that we also merged the pike backports w/o having nova-lvm running in pike either.
14:45:28 efried naichuans: Same group, but config has changed. Okay, I think I can buy that. But why does that mean you have to disable the gpu?
14:47:03 efried ...and how did the configuration change if there are existing allocations?
14:47:19 melwitt mriedem: oh, it's -W just waiting for the higher branches to merge
14:47:23 naichuans efried: we can't support multi-type vgpu on one gpug. so if the old type instance still on the gpug, we can't allocate new type on it. So we want to disable it. At first I suggest to set `total` to 0, but Jay suggests use `reserved`
14:47:52 naichuans change nova.conf to modify vgpu type white list
14:48:07 naichuans we only need a service resart after that.
14:48:07 mriedem melwitt: what is?
14:48:18 melwitt mriedem: this https://review.openstack.org/568382
14:48:35 mriedem melwitt: that was waiting for https://review.openstack.org/#/c/571433/
14:48:38 mriedem but i'm saying,
14:48:47 mriedem https://review.openstack.org/#/c/571433/ is to fix a nova-lvm regression,
14:48:52 mriedem and we don't run the nova-lvm job in pike or ocata,
14:49:06 mriedem so should we hold until we verify nova-lvm works with that change, or just...punt
14:49:15 efried naichuans: But I thought "changing vgpu type" and "changing the configuration (which leads to a different 'total')" were two different things.

Earlier   Later