| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-12 | |||
| 18:00:31 | dansmith | not to validate it no, just weird to do it that way is all | |
| 18:13:02 | dansmith | mriedem: why can't we just GET /rp/$uuid and look at the traits? | |
| 18:23:10 | mriedem | we could | |
| 18:23:31 | mriedem | in fact, | |
| 18:23:37 | arvindn05_ | mriedem: that was the suggestion in the bp | |
| 18:23:39 | arvindn05_ | :) | |
| 18:23:49 | mriedem | GET /resource_providers?in_tree=<node uuid>&required=<traits> | |
| 18:24:16 | mriedem | to match those traits with the traits specifid in the image." | |
| 18:24:16 | mriedem | arvindn05_: if you mean, "For the above issue, the scheduler can request traits of current host and try | |
| 18:24:23 | mriedem | that wasn't clear to me as a proposed solution at all | |
| 18:24:56 | mriedem | i might have gotten hung up on the 'current host' thing, thinking about RPs | |
| 18:25:53 | mriedem | arvindn05_: if you can clarify that specifically talking about https://developer.openstack.org/api-ref/placement/#list-resource-provider-traits then it's probably fine | |
| 18:26:50 | arvindn05_ | sorry if it was unclear...i will add that we will call /resource_providers/{uuid}/traits | |
| 18:27:37 | mriedem | ok that makes more sense for the alternative now | |
| 18:27:53 | arvindn05_ | i am looking at the comments now...will add the above to make it clearer | |
| 18:29:49 | arvindn05_ | i thoguht about the /resource_providers/{uuid}/traits solution after we discussed the issue yesterday to minimize changes | |
| 18:30:31 | arvindn05_ | mriedem: my original proposal to modify the API to accept no resources is now the alternate suggestion | |
| 18:31:02 | mriedem | yeah now it makes more sense to me | |
| 18:31:11 | mriedem | just need to clarify | |
| 18:31:40 | mriedem | i don't exactly know where we'd do this validation...in a new filter? | |
| 18:32:03 | mriedem | or maybe in the ImagePropertiesFilter if we know we're doing a rebuild? | |
| 18:35:56 | dansmith | or just in rebuild code in general | |
| 18:36:16 | dansmith | or, I guess we need to know if they had imagepropfilter enabled in that case? | |
| 18:36:17 | dansmith | bleh | |
| 18:37:41 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300 | |
| 18:44:15 | openstackgerrit | Merged openstack/nova master: Make the nova-multiattach job non-voting temporarily https://review.openstack.org/560909 | |
| 18:45:37 | efried | ^ time to queue up the rechecks | |
| 18:47:01 | openstackgerrit | Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949 | |
| 18:47:02 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 18:47:03 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 18:48:28 | arvindn05_ | dansmith: mriedem: my assumption was we'd do the check in select destination before the filters https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L135 | |
| 18:49:13 | arvindn05_ | an else case where in case of rebuild we made an call to /resource_providers/{uuid}/traits to get the traits and match them | |
| 18:51:24 | mriedem | idk, today we only restrict a rebuild with a new image based on the enabled filteres, as dansmith mentions | |
| 18:51:39 | mriedem | so i kind of think we should stick with that behavior | |
| 18:52:17 | mriedem | i think we'd have everything we need within the ImagePropertiesFilter itself to understand if we need to do this check | |
| 18:52:26 | mriedem | it should all be in the reqspec | |
| 18:52:39 | mriedem | and the HostState has the compute node uuid to get the resource provider | |
| 18:53:10 | mriedem | rest api calls from a filter isn't awesome, but if we just do this conditionally when we know we're doing a rebuild, it's the same rest api call, just in a different place | |
| 18:53:11 | dansmith | yeah if you have that filter disabled, no fair rejecting a rebuild based on stuff in there | |
| 18:54:31 | arvindn05_ | not sure i understand...if the image traits have been updated, shouldnt the rebuild take that into account? | |
| 18:54:54 | arvindn05_ | regardless of whether the imagefilter properties filter is enabled | |
| 18:55:29 | arvindn05_ | if the image changed completely with new traits, and image filter was never enabled, then the traits will be ignored | |
| 18:55:55 | mriedem | if you don't care about scheduling based on image properties, then why should we require it? | |
| 18:56:19 | mriedem | if you do care about scheduling based on image properties, then the filter will be enabled | |
| 18:56:58 | mriedem | it's also a default filter, which i don't think anyone disables, so it's probably fine | |
| 18:57:18 | arvindn05_ | the image properties and traits are parallel concepts though | |
| 18:58:00 | mriedem | umm | |
| 18:58:10 | mriedem | we get the traits via the image properties | |
| 18:58:16 | arvindn05_ | i dont need to enable imageproperties filter to use the traits filtering mechanissm | |
| 18:58:50 | mriedem | i guess you could argue that we do traits-based filtering in placement via flavor extra specs regardless of any flavor extra spec specific filters being enabled | |
| 18:58:59 | arvindn05_ | if you completely remove image prop filter...the traits filtering still works since it goes through placement | |
| 18:59:16 | arvindn05_ | yup | |
| 18:59:41 | mriedem | idk, i don't want to have to make this decision | |
| 19:00:13 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183 | |
| 19:00:14 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642 | |
| 19:00:15 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 19:00:16 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 19:00:17 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 19:00:18 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 19:00:19 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 19:00:20 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 19:00:21 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 19:00:22 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 19:00:23 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 19:00:29 | mriedem | arvindn05_: i'm sure bauzas would love to think about this | |
| 19:01:34 | arvindn05_ | will wait for their comments....will update the spec to make it clear based on your comments for now...thanks mriedem | |
| 19:04:31 | arvindn05_ | mriedem: btw are you convinced with the argument that image properties filter and using traits on images are independent of each other? | |
| 19:08:17 | mriedem | arvindn05_: no | |
| 19:08:22 | mriedem | but, | |
| 19:08:27 | mriedem | i also don't feel strongly about it | |
| 19:08:59 | arvindn05_ | that's half the battle won :) | |
| 19:09:14 | mriedem | ha, now you're getting it | |
| 19:09:54 | arvindn05_ | but ignoring the rebuild issue, like i mentioned if tommorow someone removed the image properties filter, based on the original BP, there would be no regression of the feature | |
| 19:09:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip placement on rebuild in same host https://review.openstack.org/546357 | |
| 19:10:27 | mriedem | hongbin: when you get a minute, can you propose backports for https://review.openstack.org/#/c/546357/ to queens and pike? | |
| 19:10:44 | hongbin | mriedem: sure | |
| 19:10:48 | mriedem | thanks | |
| 19:10:59 | mriedem | you'll have to do it from command line | |
| 19:11:38 | hongbin | i see, sure, no problem | |
| 19:12:40 | openstackgerrit | Merged openstack/nova master: uncap eventlet in nova https://review.openstack.org/560420 | |
| 19:12:58 | openstackgerrit | Merged openstack/nova master: xenapi: Support live migration in pooled multi-nodes environment https://review.openstack.org/489451 | |
| 19:15:18 | openstackgerrit | Merged openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (2) https://review.openstack.org/558993 | |
| 19:15:30 | openstackgerrit | Merged openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (3) https://review.openstack.org/559258 | |
| 19:16:42 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/queens: Skip placement on rebuild in same host https://review.openstack.org/561014 | |
| 19:22:35 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Skip placement on rebuild in same host https://review.openstack.org/561015 | |
| 19:26:04 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| 19:35:20 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| 19:43:05 | cfriesen | melwitt: for the detach_volume() change, are you suggesting a try/except block around the call to encryptor.detach_volume()? | |
| 19:43:49 | melwitt | cfriesen: yes. because if you get there on a second attempt and you already ran it in the past, os-brick will raise "unknown device" because it can't find the attached device | |
| 19:44:08 | cfriesen | makes sense, will do | |
| 19:44:25 | melwitt | we backported the os-brick change back to pike but we can't bump requirements.txt on stable | |
| 19:45:30 | melwitt | so it's not guaranteed that someone running stable/pike will have the os-brick version that will ignore exit code 4 (unknown) for you | |
| 19:48:06 | melwitt | s/you/them/ | |
| 20:00:55 | mriedem | i found another cells upcall | |
| 20:01:00 | mriedem | https://github.com/openstack/nova/blob/c531b7905f5a9f8a5bfa355a2047d04032cbf847/nova/virt/xenapi/host.py#L86 | |
| 20:01:18 | mriedem | however, it's for that completely broken and deprecated anyway host maintenance / power action stuff | |
| 20:08:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use Queens UCA for nova-multiattach job https://review.openstack.org/554317 | |
| 20:09:12 | cfriesen | melwitt: I don't have the actual "target" to report in the error message. do you know how to get it, or can I just use "disk_dev" or something? | |
| 20:10:33 | melwitt | cfriesen: yeah, disk_dev is the equivalent | |
| 20:11:11 | melwitt | this version of the patch was almost right, it just also needed to reraise if not exit code 4 https://review.openstack.org/#/c/515008/3/nova/virt/libvirt/driver.py | |