| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-20 | |||
| 10:50:22 | lyarwood | stephenfin: ^ simple doc wrinkle if you have time today | |
| 10:51:45 | stephenfin | looks sane. +2 | |
| 10:59:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: FakeDriver: adding and removing instances on live migration. https://review.opendev.org/243613 | |
| 11:41:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Print help if nova-manage subcommand is not specified https://review.opendev.org/694806 | |
| 11:41:57 | openstackgerrit | Merged openstack/nova master: FUP for in-place numa rebuild https://review.opendev.org/698260 | |
| 11:47:48 | openstackgerrit | Shilpa Devharakar proposed openstack/nova master: Instance object changes for the new 'is_volume_backed' expected_attr https://review.opendev.org/694463 | |
| 11:47:48 | openstackgerrit | Shilpa Devharakar proposed openstack/nova master: Handle new is_volume_backend join column query https://review.opendev.org/694462 | |
| 11:47:49 | openstackgerrit | Shilpa Devharakar proposed openstack/nova master: Ignore root_gb if instance is booted from volume https://review.opendev.org/612626 | |
| 12:09:07 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/train: FUP for in-place numa rebuild https://review.opendev.org/700127 | |
| 12:10:54 | stephenfin | lyarwood: fixed https://review.opendev.org/#/c/700127/ | |
| 12:15:35 | lyarwood | stephenfin: ack, grabbing lunch and then I'll queue that series up | |
| 12:28:17 | stephenfin | bauzas: You bored? I have a load of patches with single +2 that could do with a little push | |
| 12:28:40 | stephenfin | And I think you're the only other core still around. Lucky you ;) | |
| 13:59:56 | bauzas | stephenfin: heh, sure | |
| 14:00:04 | bauzas | stephenfin: sorry, I was on gym :) | |
| 14:09:13 | mriedem | lyarwood: i'm +2 on these train numa rebuild backports now if you want to send them on https://review.opendev.org/#/q/topic:bug/1763766+status:open | |
| 14:10:01 | lyarwood | mriedem: ack, have them open now, looking. | |
| 14:11:36 | TheJulia | Can anyone provide background on the "forbidden trait COMPUTE_STATUS_DISABLED" ? | |
| 14:12:21 | mriedem | TheJulia: https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-disabled-status-support | |
| 14:14:50 | TheJulia | hmm... then the question becomes why does nova think the nova-compute for ironic is no longer working when it just deleted an instance :\ | |
| 14:15:04 | TheJulia | well, minutes before in the same running process :\ | |
| 14:15:10 | TheJulia | logs | |
| 14:18:28 | TheJulia | mriedem: is it the conductor that is making that declaration ? | |
| 14:20:58 | mriedem | no, | |
| 14:21:22 | mriedem | if the compute service is enabled/disabled in the rest api then the trait added to or removed from the associated nodes that service is managing | |
| 14:21:37 | mriedem | some virt drivers (i think only libvirt) will auto-enable/disable if the hypervisor is down/up | |
| 14:21:48 | mriedem | so it could also be the compute via the driver that sets it | |
| 14:22:14 | mriedem | you can disable a compute service and still delete instances from it | |
| 14:22:17 | TheJulia | I was thought that there was some automagical thing close to the compute driver... sifting through the n-cpu logs very carefully at the moment | |
| 14:22:20 | mriedem | disable != down | |
| 14:22:29 | TheJulia | disable from scheduling, that makes sense | |
| 14:22:38 | mriedem | correct | |
| 14:27:39 | mriedem | are you seeing the logging from here? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L546-L553 | |
| 14:28:44 | TheJulia | mriedem: nope :\ | |
| 14:29:41 | mriedem | does the ironic grenade multinode job disable one compute before upgrading it which triggers a rebalance of nodes from one compute to another? | |
| 14:31:29 | TheJulia | this is a single stack job so everything get stopped and restarted | |
| 14:32:30 | TheJulia | I see a get to os-service early on, but no puts | |
| 14:32:32 | TheJulia | err, posts | |
| 14:32:33 | mriedem | and the ironic virt driver doesn't auto enable/disable the compute service does it? | |
| 14:32:41 | mriedem | the disable/enable is a PUT | |
| 14:33:02 | TheJulia | oh, good, then none at all in the nova api log :) | |
| 14:33:07 | mriedem | https://docs.openstack.org/api-ref/compute/#compute-services-os-services | |
| 14:33:29 | TheJulia | I'm honestly don't remember if we auto-disable or not. I guess that is the next thing to look at | |
| 14:34:59 | mriedem | i don't see anything in the driver | |
| 15:06:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle cell failures in get_compute_nodes_by_host_or_node https://review.opendev.org/700186 | |
| 15:54:51 | bauzas | stephenfin: don't hesitate to ping me the changes you'd like me to review | |
| 15:55:09 | TheJulia | mriedem: by chance is that last patch related to our discussion? :) | |
| 15:55:56 | mriedem | TheJulia: nope | |
| 15:56:15 | mriedem | bauzas: bottom 4 nova-net removal changes are +2ed and ready to go https://review.opendev.org/#/c/696510/ | |
| 15:56:18 | mriedem | starting at ^ | |
| 15:56:31 | bauzas | mriedem: thanks ! | |
| 15:56:42 | bauzas | I'm finally back upstream this week FWIW | |
| 16:00:08 | TheJulia | mriedem: rats, I was hopeful :) | |
| 16:01:14 | openstackgerrit | Lee Yarwood proposed openstack/nova master: guestfs: Log a useful error when the required vmlinuz isn't found https://review.opendev.org/700193 | |
| 16:10:37 | openstackgerrit | Merged openstack/nova stable/train: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/700021 | |
| 16:12:54 | mriedem | gibi_pto: nits in https://review.opendev.org/#/c/699015/ for when you want to start a FUP patch for that series | |
| 16:16:45 | mriedem | bauzas: also, the bottom few changes in the live migration + qos ports series ^ are +2ed and need another core | |
| 16:17:08 | mriedem | per usual gibi has done a lot of good functional testing | |
| 16:33:02 | bauzas | mriedem: ack, will review it too on monday | |
| 16:36:54 | mriedem | johnthetubaguy: are you ok with me fixing https://review.opendev.org/#/c/697162/7/nova/tests/unit/compute/test_shelve.py@168 in a follow up? | |
| 16:37:05 | johnthetubaguy | mriedem: yeah | |
| 16:37:53 | johnthetubaguy | I assumed I miss-read it, no worries | |
| 16:40:25 | mriedem | thanks | |
| 16:43:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Implement reschedule logic for cross-cell resize/migrate https://review.opendev.org/696213 | |
| 16:43:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add negative test to delete server during cross-cell resize claim https://review.opendev.org/688832 | |
| 16:44:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: FUP to Iff8194c868580facb1cc81b5567d66d4093c5274 https://review.opendev.org/700202 | |
| 17:04:35 | gmann | johnthetubaguy: i can change the default target logic in policy.py. cannot remember what case i thought it can break if moving to common place - https://review.opendev.org/#/c/676688/5 | |
| 17:05:18 | gmann | johnthetubaguy: also, do you have time to discuss the admin policy case - https://review.opendev.org/#/c/676682/5 | |
| 17:10:19 | johnthetubaguy | gmann: sure | |
| 17:12:14 | gmann | johnthetubaguy: in this case, new default (base.SYSTEM_ADMIN) has special string 'system=all' which will not match with existing project admin even enforce_scope is flase | |
| 17:12:45 | gmann | that is why i think we need to deprecate it to support the existing user's token keep working | |
| 17:13:57 | johnthetubaguy | but I am not sure we need to add it yet | |
| 17:14:14 | johnthetubaguy | in the admin_only case, that is | |
| 17:15:03 | johnthetubaguy | but... I get your point for admin_or_owner, hmm | |
| 17:15:10 | gmann | you mean 'system=all' ? | |
| 17:15:55 | johnthetubaguy | yeah | |
| 17:16:18 | johnthetubaguy | because in the admin_only case, we already check via the scope check | |
| 17:16:19 | gmann | that is needed for the window when we remove the deprecated rule and make enforce_scope=True by default. in that window project admin should not be able to do system admin operation. | |
| 17:16:47 | gmann | if enforce_scope if false then scope check is not checked right. | |
| 17:17:04 | johnthetubaguy | yeah, I just assumed those two things happened at the same time | |
| 17:18:18 | johnthetubaguy | gmann: maybe we should do the admin_password API, its admin_or_owner | |
| 17:18:40 | johnthetubaguy | I think what works there we probably want to apply to the admin api too | |
| 17:19:22 | johnthetubaguy | I think the points you made above, I totally agree with you for the admin_or_owner case | |
| 17:19:36 | gmann | if both things happen at same time then yes i agree with your point for admin case. | |
| 17:20:21 | gmann | yeah admin_or_owner and any lower role like member or reader we need that string. | |
| 17:20:54 | gmann | so that we do not expose any project level reader to system level reader | |
| 17:21:13 | johnthetubaguy | what about doing the deprecation at this level: https://review.opendev.org/#/c/645452/17/nova/policies/base.py | |
| 17:21:22 | gmann | s/system level reader to project level reader | |
| 17:21:59 | johnthetubaguy | we spoke about someone wanting to use this sooner they can override the base policy rule to always to the system check, if they want to opt into the new world early | |
| 17:22:51 | gmann | yeah | |
| 17:23:14 | gmann | did not get your last point on deprecation at base level ? | |
| 17:23:33 | johnthetubaguy | so thinking about this: https://github.com/openstack/nova/blob/b953db09e8b9195c6a922c03a57f44cd790adcb6/nova/policies/base.py#L79 | |
| 17:23:50 | johnthetubaguy | what if we move the APIs over to the new rule | |
| 17:24:18 | johnthetubaguy | but we add a deprecated bit to the new rule, so it falls back to allowing the old check in there? | |
| 17:24:33 | johnthetubaguy | ... i am not explaining this well | |
| 17:25:30 | gmann | i think i got your point and deprecate to RULE_ADMIN_API | |
| 17:25:37 | johnthetubaguy | yeah | |
| 17:25:58 | johnthetubaguy | so when an operator wants the new world, its only a few rules they change | |
| 17:26:18 | gmann | but what if any API rule changing from RULE_ADMIN_OR_OWNER - > SYSTEM_ADMIN ? i think no.. | |
| 17:27:08 | gmann | it will be -> either PROJECT_MEMBER_OR_SYSTEM_ADMIN or PROJECT_READER_OR_SYSTEM_READER that what we have in table | |