| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-18 | |||
| 15:07:01 | gibi | mriedem: simply for the bandwidth allocation no special handling is needed | |
| 15:07:19 | gibi | mriedem: to fulling the neutron port profile with a single RP, we need special mapping for re-schedule https://review.openstack.org/#/c/619529 | |
| 15:07:49 | gibi | mriedem: yeah, that mapping is the responsible of placement, but placement is freezed, so the spec is on hold | |
| 15:08:01 | gibi | mriedem: therefore, temporarly, nova does the mapping | |
| 15:09:58 | mriedem | ok i guess this just means i need to peel the onion to figure this out | |
| 15:12:25 | gibi | mriedem: at least the handling of that mapping is in small patches already | |
| 15:14:21 | mriedem | i also dumped some comments in the reschedule patch https://review.openstack.org/#/c/619529/ since it doesn't deal with resize, and we have a blocker there | |
| 15:14:35 | mriedem | which is https://review.openstack.org/#/c/582417/ | |
| 15:15:31 | mriedem | i can't figure out why our unit/functional tests with the fake oslo messaging driver and serializer fail to serialize a request spec during resize rpc cast from conductor to compute but only for that prep_resize call, not for any of the other rpc calls we make like build_and_run_instance or select_destinations, it doesn't make any sense to me | |
| 15:16:05 | mriedem | but until we have that change, the RequestSpec is gone when compute reschedules during a resize | |
| 15:18:32 | gibi | mriedem: regarding https://review.openstack.org/#/c/619529/ it only supposed to handle re-schedule during boot, since non of the server moving operations are supported at that point of the series. More specifically non of the server move operations are supproted in the current series at all | |
| 15:19:07 | gibi | mriedem: I've added https://review.openstack.org/#/c/582417/ to my list to look at | |
| 15:22:38 | mriedem | ok. if we get to the point that we can't support move operations for these types of servers/ports, we likely need to put some blocker code in place so we don't move a server and drop/break the port qos policy | |
| 15:25:41 | gibi | mriedem: I agree. We can check if there is any port attached that has resource request and reject the move. But I haven't reached the point to write the code for supporting the move so I still believe it can be done. | |
| 15:30:50 | gibi | mriedem: Do you think, would it help if I summarize the overal plan about the bandwidth impl on the ML. Describing the order of the changes, reiterating why we need the mapping calculated in nova, describing the proposal to use neutron api extension as a feature flag? | |
| 15:31:56 | mriedem | gibi: yeah maybe for anyone that hasn't started reviewing this, which seems like no one but me so far | |
| 15:32:16 | mriedem | the reverse order definitely makes it more confusing for me to get the big picture | |
| 15:32:28 | mriedem | which is why i'm asking about how the port binding request stuff is handled in compute | |
| 15:32:30 | gibi | mriedem: OK, I can write up a review guide for that series tomorrow | |
| 15:32:45 | mriedem | you probably also saw me asking about tempest integration testing in the neutron meeting too | |
| 15:33:21 | mriedem | btw, we have merged some placement specs, the code is just feature frozen for now | |
| 15:33:49 | gibi | mriedem: the order you would like to see would lead to impossible long patch series that cannot be tested on functional or higher level until the last patch that allows booting a server is merged | |
| 15:34:20 | gibi | e.g. I cannot test any move without booting a server first | |
| 15:34:56 | gibi | mriedem: I saw the tempest test question, thanks for it. We have the plan to make integration testing, but you had a good point adding that to tempest-full | |
| 15:35:42 | gibi | mriedem: I did not push for the placement spec too hard because I was time constrained and I knew that the implementation would be blocked this cycle anyhow | |
| 15:35:51 | mriedem | we have alternatives to tempest-full / integrated gate, but that would need to be thought through | |
| 15:36:09 | mriedem | i.e. we could pick up the neutron tempest plugin in our nova-next job? | |
| 15:36:19 | mriedem | but we'd likely be running a bunch of neutron-only tests which we don't want | |
| 15:36:29 | mriedem | we could maybe whitelist what we want to run though... | |
| 15:36:51 | mriedem | with the state of the gate lately, i'm not sure how keen i am on introducing more exotic networking tests to the integrated gate | |
| 15:36:59 | gibi | I think adding the bandwidth related scenarion tests to tempest proper is the way forward as that covers a bunch of nova, neutron and placemetn code as well | |
| 15:37:08 | mriedem | yeah agree | |
| 15:37:25 | gibi | and the integrated gate needs to be fixed anyhow :/ | |
| 15:37:26 | mriedem | keep the edge case stuff in the tempest plugin | |
| 15:37:33 | mriedem | and the happy path stuff in tempest | |
| 15:37:37 | gibi | I agree | |
| 15:38:25 | mriedem | and yeah i know about the bottom up approach for a long series of changes, we had that with volume multiattach | |
| 15:39:38 | gibi | mriedem: I think we are in a bit better situation with bandiwdth as I believ we can use the neutron api extension as a feature flag. We can make the api extension experimental why we progress in nova | |
| 15:39:55 | gibi | s/why/while | |
| 15:42:06 | gibi | mriedem: I'm ready to push the last batch of fixes for the first patch you reviewd yesterday. It includes splitting that patch into three. Do you have any comments in flight for the series that you would like to publish before I push? | |
| 15:42:26 | mriedem | no my comments are posted | |
| 15:42:43 | gibi | mriedem: OK | |
| 15:49:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 15:49:52 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527 | |
| 15:49:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 15:49:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528 | |
| 15:49:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 15:49:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 15:49:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 15:49:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 15:49:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078 | |
| 15:49:56 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079 | |
| 15:49:57 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 15:49:57 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080 | |
| 15:49:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 15:49:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311 | |
| 15:49:59 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 15:49:59 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Create RequestGroup from neutron port https://review.openstack.org/625941 | |
| 15:50:00 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Include requested_resources to allocation candidate query https://review.openstack.org/625942 | |
| 15:52:34 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959 | |
| 15:54:22 | jackding | hi mriedem: could you revisit https://review.openstack.org/#/c/616692/ and https://review.openstack.org/#/c/603844/ when you got a chance? | |
| 16:00:35 | mriedem | i'll put them in my browser tab queue but i can't promise anything, lots to get done this week before i'm out next week | |
| 16:05:02 | openstackgerrit | Merged openstack/nova master: Migrate "reboot an instance" user guide docs https://review.openstack.org/612730 | |
| 16:12:51 | jackding | mriedem: ok, thanks | |
| 16:14:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove legacy request spec compat code from API https://review.openstack.org/614309 | |
| 16:14:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat code from live migrate task https://review.openstack.org/625705 | |
| 16:14:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor unshelve_instance https://review.openstack.org/625706 | |
| 16:14:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor rebuild_instance https://review.openstack.org/625707 | |
| 16:14:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Pass request_spec from compute to cell conductor on reschedule https://review.openstack.org/582417 | |
| 16:15:17 | openstackgerrit | Merged openstack/nova master: allow tcp-based consoles in get_console_output https://review.openstack.org/624974 | |
| 16:24:13 | openstackgerrit | Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 16:34:46 | openstackgerrit | Krzysztof Opasiak proposed openstack/nova master: Fix server IPs with non-unique network names https://review.openstack.org/625371 | |
| 17:03:56 | openstackgerrit | Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 17:36:52 | melwitt | ||
| 17:47:29 | mriedem | i'd like to beg for some specs reviews on https://review.openstack.org/#/c/393930/ (+2 from dan) and https://review.openstack.org/#/c/612531/ (bunch of +1s but no specs cores yet) | |
| 17:47:52 | mriedem | former is pretty straight-forward: expose device tags in GET requests | |
| 17:47:59 | mriedem | latter has a question about a config option | |
| 17:50:12 | sean-k-mooney | well i cant +2 them but ill try and review them later today. | |
| 17:51:34 | sean-k-mooney | reading the problem statement of both the seam reasonably useful so ill proably like them :) | |
| 17:51:48 | mriedem | you can harass your local specs core for me | |
| 17:54:45 | sean-k-mooney | the serial number one is behavior i was completely un aware of until now | |
| 19:03:47 | canori01 | Hello, is there currently a way to prevent a resize operation to go accross availability zones? I have the availabilityzone filter enabled, but it occasionally tries to go to other AZ's | |
| 19:19:50 | mriedem | canori01: if the server is created without specifying an AZ and https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone is not set then nova doesn't restrict the server to a single AZ | |
| 19:19:57 | mriedem | which is probably why you're seeing them move sometimes | |
| 19:21:08 | mriedem | which reminds me https://review.openstack.org/#/c/567701/ | |
| 19:30:48 | sean-k-mooney | hehe ill add that to my review list after https://review.openstack.org/#/c/594527/ | |
| 19:33:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP block_device: Optionally recreate attachments when refreshing connection_info https://review.openstack.org/579004 | |
| 19:35:08 | sean-k-mooney | melwitt: johnthetubaguy jaypipes if ye have time could you take a look at https://review.openstack.org/#/c/591607/11 | |
| 19:43:01 | lyarwood | melwitt / mriedem_afk ; https://review.openstack.org/#/c/618478/ - Would you mind hitting this dead horse again, preferably enough times to kill it if it's a non-starter so I can move on and try fixing this another way, cheers! | |
| 19:44:15 | melwitt | sean-k-mooney: will do | |
| 19:44:32 | melwitt | lyarwood: yes, sorry I didn't get to it yesterday. will do it today | |
| 19:44:48 | lyarwood | hmm killing a dead horse, I think it's time to log off for the day. | |
| 19:44:56 | lyarwood | melwitt: ack np thanks again | |
| 19:51:26 | openstackgerrit | Merged openstack/nova master: Drop request spec migration code https://review.openstack.org/614265 | |
| 20:06:59 | canori01 | If I set an invalid default_schedule_zone, will that prevent the instances from crossing AZ's? | |
| 20:50:07 | mriedem_afk | canori01: it would likely prevent the instance from even booting | |
| 20:51:40 | canori01 | mriedem: The problem I have is I have different storage backends for the boot volume on my different az's. I want the instances to boot in any az, but not move cross-AZ after booting. Is that possible? | |
| 20:54:06 | mriedem | do you want the server to be in the same AZ as the root volume? and if so, do the root volumes have non-default AZs? | |
| 20:54:14 | mriedem | i.e. specific cinder AZs per storage type/backend? | |
| 20:54:51 | mriedem | if so, you might be interested in https://review.openstack.org/#/c/469675/ | |