Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-12
17:25:19 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method https://review.openstack.org/555947
17:25:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True https://review.openstack.org/556333
17:25:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334
17:25:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
17:25:23 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370
17:25:24 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration https://review.openstack.org/551371
17:25:25 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration https://review.openstack.org/434870
17:25:26 openstackgerrit Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537
17:27:26 mriedem arvindn05: if you're just asking questions in a patch ( https://review.openstack.org/#/c/546357/ ) you don't need to -1
17:47:24 arvindn05_ mriedem: thanks...will keep in mind.
17:48:38 mriedem arvindn05_: i put some comments in your spec amendment, thanks for starting that https://review.openstack.org/#/c/560718/1
17:49:02 mriedem jaypipes: dansmith: efried: ^ that's going to require some placement love
17:49:47 dansmith ugh
17:49:52 mriedem f yeah, rebuild
17:52:04 mriedem if we can request resources=VCPU:0 and in_tree=<compute node uuid> then i think we'd be ok
17:53:10 efried mriedem: I think jaypipes wanted to deal with that by using the GET /resource_providers API instead of GET /a_c. (I disagreed; I think ?in_tree in GET /a_c is a fine idea)
17:53:32 dansmith but asking for zero resources seems weird
17:53:36 mriedem actually if we added in_tree to GET /allocation_candidates, just make resources optional in the same microversion
17:54:03 mriedem so GET /allocation_candidates?in_tree=1234&required=CUSTOM_NEW_IMAGE_TRAIT
17:55:37 dansmith that also seems a little weird to me
17:55:59 mriedem because we aren't going to actually allocate anything?
17:56:19 dansmith well, not that we aren't going to allocate anything really
17:56:27 dansmith just that we're asking a weird question there
17:56:37 mriedem ok, well, some options
17:57:03 mriedem this doesn't seem like an impossibly hard issue though
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?

Earlier   Later