| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-25 | |||
| 15:02:42 | melwitt | mriedem: yeah, I hope to have something WIP uploaded by late today | |
| 15:30:34 | openstackgerrit | sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842 | |
| 15:30:35 | openstackgerrit | sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 15:30:35 | openstackgerrit | sean mooney proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120 | |
| 15:30:36 | openstackgerrit | sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 15:30:36 | openstackgerrit | sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 15:30:37 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589 | |
| 15:35:37 | openstackgerrit | Jan Gutter proposed openstack/nova master: Add support for vrouter HW datapath offloads https://review.openstack.org/572082 | |
| 15:35:37 | openstackgerrit | Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325 | |
| 15:58:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Raise InstanceFaultRollback for UnableToMigrateToSelf from _prep_resize https://review.openstack.org/633227 | |
| 16:00:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change InstanceFaultRollback handling in _error_out_instance_on_exception https://review.openstack.org/633212 | |
| 16:00:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Raise InstanceFaultRollback for UnableToMigrateToSelf from _prep_resize https://review.openstack.org/633227 | |
| 16:04:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change InstanceFaultRollback handling in _error_out_instance_on_exception https://review.openstack.org/633212 | |
| 16:04:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Raise InstanceFaultRollback for UnableToMigrateToSelf from _prep_resize https://review.openstack.org/633227 | |
| 16:11:15 | melwitt | mriedem: I got confused by your comments on https://bugs.launchpad.net/nova/+bug/1811235 is it that cold migrate to same host is only valid for the vmware driver? and compute manager should be kicking it out unilaterally? | |
| 16:11:16 | openstack | Launchpad bug 1811235 in OpenStack Compute (nova) "instance's vm-state becomes error when cold-migrate instance to same host failed" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 16:11:30 | mriedem | stephenfin: i'll likely need you to run it up the flagpole with danpb about why libvirt.sysinfo_serial was never guest-specific | |
| 16:11:39 | mriedem | i don't have the history on that and it wasn't found in the original changes | |
| 16:11:57 | stephenfin | mriedem: Can do | |
| 16:12:02 | melwitt | s/should/shouldn't/ | |
| 16:12:30 | mriedem | the compute manager doesn't kick cold migrate to the same host out unilateraly, the api is | |
| 16:12:38 | mriedem | with that 2.56 change to specify host on cold migrate | |
| 16:12:47 | mriedem | that's a different issue from the bug though, which was reported against ocata | |
| 16:12:52 | mriedem | before 2.56 existed | |
| 16:13:41 | mriedem | i believe migrate_to_same_host exists for the vmware driver b/c you can have a single nova-compute service in your openstack deployment which is actually managing a vcenter cluster with 1000 ESXi hosts in it | |
| 16:13:47 | mriedem | so your only choice to cold migrate is to the same host | |
| 16:13:50 | melwitt | he says he thinks it exists in ocata too from reading the code. right? I'm having trouble parsing this entire bug :( | |
| 16:14:07 | mriedem | my patches above are working on fixing the bug he's hitting which exists in ocata | |
| 16:14:09 | mriedem | 2.56 does not | |
| 16:14:09 | melwitt | comment #2 | |
| 16:14:34 | mriedem | 2.56 was queens | |
| 16:14:55 | mriedem | comment 2 is saying 2 things | |
| 16:14:58 | mriedem | first is the bug i'm fixing above | |
| 16:15:03 | mriedem | second is the 2.56 issue i think | |
| 16:15:06 | mriedem | which is a different bug imo | |
| 16:15:14 | melwitt | yeah, I think he's not saying he's reporting it for ocata. "First, why the latest version of nova not supports migrating instance to same host event through some drivers support that function..Second, if there is any problem when user migrates instance without migration destination host but there is just one compute node." | |
| 16:15:57 | melwitt | eh, I dunno, I think I'm just confused by the wording of these comments | |
| 16:18:33 | mriedem | i left a comment to try and answer the questions from comment 2 | |
| 16:20:11 | melwitt | thanks. I think I see now, he's saying why go to error status when it "fails" because migrating to self doesn't really do anything | |
| 16:21:07 | melwitt | ok that comment makes it clear. good | |
| 16:21:13 | mriedem | correct, but the rejection in the API is not the same as the bug in the compute that sets the instance to error status | |
| 16:21:31 | mriedem | i've got fixes posted above for the latter, not the former | |
| 16:21:54 | melwitt | gotcha. I've got it starred for review | |
| 16:29:30 | mriedem | melwitt: if https://blueprints.launchpad.net/openstack/?searchtext=conf-max-attach-volumes is ready for review again you want to queue it up in runways? | |
| 16:29:46 | mriedem | jangutter's can probably go in the open slot as well | |
| 16:30:10 | melwitt | mriedem: sure. I don't know why I didn't think of doing that | |
| 16:34:51 | jangutter | melwitt, mriedem: thanks! | |
| 16:35:41 | mriedem | pretty easy fix here for someone https://review.openstack.org/#/c/624959/ | |
| 16:35:46 | mriedem | needs to be backported to queens as well | |
| 16:39:49 | melwitt | jangutter: the bp dependencies show that vrouter-hw-offloads also depends on the generic-os-vif-offloads too. should I add that patch link in there too for the runway review? | |
| 16:40:37 | sean-k-mooney | melwitt: i think the os-vif stuff was all in the 1.14 release we did this week | |
| 16:40:41 | jangutter | melwitt: the dependency's unblocked on that one (generic-os-vif-offloads has follow-on work) | |
| 16:41:09 | sean-k-mooney | jangutter: more stuff in os-vif "e.g. that i should review" or in nova | |
| 16:41:15 | melwitt | oh, I see, the dependency piece is unblocked but bp still needs more work to be complete | |
| 16:41:16 | sean-k-mooney | which i should proably also review | |
| 16:41:17 | melwitt | ok thank you | |
| 16:41:48 | jangutter | melwitt: the dominoes are all ready to fall... for the vrouter bits though. | |
| 16:42:05 | melwitt | coolness | |
| 16:45:51 | jangutter | sean-k-mooney: for the generic-os-vif-offloads I think there's just one more bit in nova (for Stein) to populate the data. The next os-vif change should really only be appropriate for Train. | |
| 16:48:48 | sean-k-mooney | ok | |
| 16:49:40 | sean-k-mooney | if there is stuff i need to review for stien let me know. the non client lib frezze is in 3-4 weeks so if another os-vif release is need we need to merge the code before then | |
| 16:50:14 | sean-k-mooney | form the non-client-lib freeze untill rc1 os-vif will basically be frozen | |
| 16:50:41 | sean-k-mooney | form rc1/rc2 on it will be reopen for train | |
| 16:51:09 | melwitt | feb 28 is non-client lib freeze | |
| 16:51:38 | jangutter | sean-k-mooney: thanks, the only open one I have for Stein is the serialization cleanup patch, and that kinda-sorta depends on a style choice. | |
| 16:52:13 | sean-k-mooney | ok thats what i had understood | |
| 16:52:38 | jangutter | sean-k-mooney: I _think_ the only affected party to that would be kuryr and not Nova. | |
| 17:06:58 | melwitt | leakypipes, mriedem: am I correct in my understanding that because this spec about "how to use initial allocation ratios" got stuck https://review.openstack.org/544683, we don't and will not have support for being able to set allocation ratios per aggregate? | |
| 17:08:41 | mriedem | you can do it via placement externally if you want, and could have since forever - and is what we said people could do in dublin | |
| 17:08:44 | mriedem | but no one worked on that, | |
| 17:08:48 | mriedem | or added anything to osc-placement for it | |
| 17:09:06 | mriedem | the nova spec is about mirroring aggregate allocation ratios to placement | |
| 17:09:34 | mriedem | which is a nice to have but less necessary since you can do that directly with placement and we have rbac support in placement now too (which was a previous reason this should go through nova - for rbac) | |
| 17:10:06 | mriedem | so the only sticking point on the nova spec is deciding if nova should do that mirroring / proxy orchestration work | |
| 17:10:25 | mriedem | clearly that isn't going to happen in stein though | |
| 17:10:28 | mriedem | bbiab | |
| 17:12:41 | efried_mtg | sean-k-mooney: not sure if you knew about this, but when resubmitting a series, git-review normally re-topics the whole series to match the top patch. You can make it not do that - i.e. leave the topic unchanged (or empty if it's the first time you're uploading it) by using the -T flag. | |
| 17:12:50 | melwitt | mriedem_afk: thanks, I'll make some notes about it on the blueprint tracking etherpad | |
| 17:13:31 | sean-k-mooney | efried_mtg: ya it has bitten me in the past | |
| 17:13:56 | melwitt | I've had a hard time following what was going on there. didn't realize the only thing left was mirroring, and I agree I'm not sure whether we should | |
| 17:14:32 | sean-k-mooney | efried_mtg: generally its does what i want as if i am working on a patch serise its all for the same bug/blueprint but it can be annoying | |
| 17:15:31 | sean-k-mooney | efried_mtg: i just like the fact i can "git checkout -b whatever" and then "git revew -f" and have the topic set correctly to "whatever" | |
| 17:16:42 | leakypipes | melwitt: I'll abandon that spec. | |
| 17:18:14 | sean-k-mooney | leakypipes: you spec for mirroring nova aggrages as placement aggrates was complete in rocky rigt? seperate form the allcoation ratio stuff | |
| 17:18:16 | melwitt | leakypipes: k. I was only asking because I'm trying to round up things we identified as priority items and that one I had trouble parsing what the second spec was about | |
| 17:18:32 | melwitt | *priority items at the ptg | |
| 17:19:41 | melwitt | sean-k-mooney: mirroring aggregates was a different thing yeah, and is already in nova | |
| 17:19:47 | leakypipes | sean-k-mooney: yes. | |
| 17:20:27 | leakypipes | melwitt: np | |
| 17:20:56 | sean-k-mooney | cool so in thery you coudl write a scipt/tool to find all the RPs with a specific resouce in an aggrate and set the allocation ratio in the inventory relitivly simply if you wanted too | |
| 17:26:51 | melwitt | yeah, we talked about adding a command to osc-placement CLI to help with that. we should do that. maybe I'll try to do it if I can get my other stuff done | |
| 17:39:59 | openstackgerrit | Kevin Rasmussen proposed openstack/nova master: created AggregateSubnetAvailabilityFilter https://review.openstack.org/633178 | |
| 17:40:30 | openstackgerrit | Kevin Rasmussen proposed openstack/nova master: created AggregateSubnetAvailabilityFilter https://review.openstack.org/633178 | |
| 18:17:05 | artom | We can just disable the Keystone middleware and run without authentication, right? | |
| 18:17:26 | sean-k-mooney | artom: you can disable auth yes | |
| 18:17:30 | artom | (Asking for a performance thing downstream, suspecting Keystone is the culprit, want to propose testing without it) | |
| 18:21:09 | sean-k-mooney | i guessed. let me see if i can find the config | |
| 18:21:33 | artom | sean-k-mooney, too late, email went out. I'll blame you if people pick me up on it :D | |
| 18:22:37 | cdent | artom, sean-k-mooney: I'm not positive but I think you have to choose a different auth strategy (noauth2) and still set x-auth-token headers so that policy checks still have something to chew on. If that can be avoided too, I'd love to hear about it. | |
| 18:23:01 | sean-k-mooney | artom: i think you set this https://docs.openstack.org/nova/latest/configuration/config.html#keystone_authtoken.auth_type | |