| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-04 | |||
| 11:32:30 | openstackgerrit | Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325 | |
| 11:32:31 | openstackgerrit | Jan Gutter proposed openstack/nova master: [WIP] Add support for vrouter HW offloads https://review.openstack.org/572082 | |
| 11:49:39 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Add policy to InstanceGroup object and api models. https://review.openstack.org/563375 | |
| 11:49:40 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Add policy field to ServerGroup notification object https://review.openstack.org/563401 | |
| 11:49:41 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Change the anti-affinity Filter to adapt to new policy https://review.openstack.org/571166 | |
| 11:49:42 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Adapt _validate_instance_group_policy to new policy model https://review.openstack.org/571465 | |
| 11:49:43 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Microversion 2.63 - Use new format policy in server group https://review.openstack.org/567534 | |
| 12:07:48 | openstackgerrit | Damon Li proposed openstack/nova master: Remove minimum version check when save service https://review.openstack.org/572089 | |
| 12:13:37 | openstackgerrit | Damon Li proposed openstack/nova master: Remove minimum version check when save service https://review.openstack.org/572089 | |
| 12:26:55 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Add support for generic offload representors https://review.openstack.org/572081 | |
| 12:32:24 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148 | |
| 13:28:53 | mike99201 | does nova-conductor call transport_url from anywhere other than nova.conf or is it possibly cached somewhere? | |
| 13:31:48 | naichuans | jaypipes: Hi, jay. I have a disscuss with Eric on a vgpu n-rp patch:https://review.openstack.org/#/c/520313/40/nova/virt/xenapi/driver.py. Could you review it and give some suggestion when you have the time? | |
| 13:32:15 | jaypipes | naichuans: yep! | |
| 13:32:36 | naichuans | jaypipes: Thanks! | |
| 13:33:03 | jaypipes | mike99201: it's cached in the API database, unfortunately: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_models.py#L118 | |
| 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? | |