| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-12 | |||
| 17:16:17 | dansmith | yeah | |
| 17:16:24 | mriedem | like powervm | |
| 17:16:30 | dansmith | linux for sure, but might even be on x86 | |
| 17:16:35 | mriedem | yeah totes | |
| 17:16:43 | mriedem | doesn't need to be linux on s390x | |
| 17:16:48 | mriedem | that would be dumb | |
| 17:16:59 | dansmith | yeah, the arch thing isn't the concern as much as it's a lib for a hypervisor I don't need | |
| 17:17:12 | mriedem | sure, but the point is, we are all over the board | |
| 17:17:16 | dansmith | brick is kinda the same-ish, although it's not as weird I think | |
| 17:17:19 | dansmith | yes, definitely | |
| 17:17:31 | mriedem | os-xenapi is also in requirements.txt | |
| 17:17:43 | mriedem | taskflow is also only used by powervm but in requiments.txt | |
| 17:17:52 | dansmith | I think that for people who get government audits for every line of installed code, it'd be a harder sell than os-brick being there but not used | |
| 17:17:55 | dansmith | but just a guess | |
| 17:18:10 | mriedem | you know what i miss? COOs | |
| 17:18:18 | dansmith | I'd be happy using this as an opportunity to get right with the loahd on here | |
| 17:18:25 | dansmith | mriedem: really? that's funny, I don't miss them at all | |
| 17:18:33 | mriedem | i was being sarcastic | |
| 17:18:38 | dansmith | WAT | |
| 17:18:40 | dansmith | I had no idea | |
| 17:18:41 | mriedem | but your audit comment got me reminiscing | |
| 17:18:45 | dansmith | I know :) | |
| 17:18:52 | mriedem | and now this https://www.youtube.com/watch?v=CZ_3G4xqSDQ | |
| 17:19:17 | mriedem | looking at those guys reminds me i need to schedule a haircut | |
| 17:21:12 | mriedem | alright wtf was i doing now | |
| 17:24:02 | mriedem | efried: i have replied for great posterity | |
| 17:24:13 | efried | mriedem: thanks | |
| 17:25:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Wait for network-vif-plugged before starting live migration https://review.openstack.org/558001 | |
| 17:25:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548 | |
| 17:25:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method https://review.openstack.org/523604 | |
| 17:25:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |
| 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 | arvindn05_: if you mean, "For the above issue, the scheduler can request traits of current host and try | |
| 18:24:16 | mriedem | to match those traits with the traits specifid in the image." | |
| 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 | |