| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-23 | |||
| 02:30:10 | openstackgerrit | Jie Li proposed openstack/nova master: replace the "hide_hypervisor_id" to "hw:hide_hypervisor_id" https://review.opendev.org/722187 | |
| 02:58:37 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Update bp/destroy-instance-with-datavolume SPEC https://review.opendev.org/722194 | |
| 03:00:40 | brinzhang | gibi, dansmith, gmann: I was update the bp/destroy-instance-with-datavolume SPEC https://review.opendev.org/#/c/722194, please review if you have free time | |
| 03:01:17 | gmann | melwitt: need your +2 again. fixed one link in reno - https://review.opendev.org/#/c/720129/16 | |
| 03:02:09 | gmann | brinzhang: thanks. i will check tomorrow. this is delete-on-termination spec update right ? | |
| 03:02:27 | brinzhang | gmann: thanks | |
| 03:02:30 | gmann | i mean as per latest code we merged as PUT not PATCH | |
| 03:02:49 | brinzhang | gmann: yes, it's the delete-on-termination spec update | |
| 03:03:43 | brinzhang | maybe I should rename this patch | |
| 03:08:13 | gmann | ok. got it. thanks | |
| 03:16:19 | brinzhang | gmann: thanks too | |
| 04:08:01 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Update SPEC: Using PUT instead of PATCH API to update delete_on_termination https://review.opendev.org/722194 | |
| 06:58:10 | gibi | brinzhang_: ack, I will look at it probably next week | |
| 06:59:24 | brinzhang_ | gibi: ack, it's not in a hurry | |
| 06:59:33 | brinzhang_ | gibi: thanks | |
| 07:30:03 | openstackgerrit | Merged openstack/nova master: Add docs and releasenotes for BP policy-defaults-refresh https://review.opendev.org/720129 | |
| 07:34:40 | bauzas | gibi: gmann: I'll provide a FUP for ^ for the reno prelude https://review.opendev.org/#/c/721548/ | |
| 07:40:19 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: FUP: Amend ussuri prelude to add docs for policy concepts https://review.opendev.org/722220 | |
| 07:40:27 | bauzas | gmann: gibi: p | |
| 07:40:30 | gibi | bauzas: cool | |
| 07:41:31 | gibi | thanks. I'm +A on the prelude and +2 on the FUP | |
| 07:41:41 | bauzas | nice | |
| 07:41:43 | bauzas | thanks | |
| 07:41:58 | bauzas | gibi: any urgent change review we should do before RC1 ? | |
| 07:42:47 | bauzas | gibi: given the owner haven't provided a new revision for https://review.opendev.org/#/c/719163/, I'll remove the bug tag | |
| 07:43:36 | bauzas | oh you already did :) | |
| 07:43:57 | gibi | yepp, I pinged you during the week about it but figured you were busy so went ahead and removed it | |
| 07:44:10 | gibi | I can pick that fixup later if the author did not show up | |
| 07:44:39 | gibi | bauzas: there is a simple revert we need to merge before RC1 https://review.opendev.org/#/c/718630 | |
| 07:45:04 | gibi | and the ussuri RPC alias https://review.opendev.org/#/c/719315/ | |
| 07:45:32 | gibi | I'm not tracking anyithing else for RC1 at the moment | |
| 07:58:31 | bauzas | cool | |
| 08:10:29 | bauzas | gibi: fwiw, all the RPC APIs should have aliases... | |
| 08:11:19 | bauzas | gibi: but for example, see the last alias for the scheduler... https://github.com/openstack/nova/blob/master/nova/scheduler/rpcapi.py#L120 | |
| 08:18:20 | gibi | bauzas: I do the aliasing based on https://docs.openstack.org/nova/latest/contributor/ptl-guide.html | |
| 08:18:32 | gibi | "In the past, we used to update all service version aliases (example: https://review.opendev.org/230132) but since we really only support compute being backlevel/old during a rolling upgrade, we only need to update the compute service alias, see related IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-08-08.log.html#t2018-08-08T17:13:45" | |
| 08:55:23 | bauzas | gibi: oh ok thanks | |
| 09:01:49 | openstackgerrit | Merged openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548 | |
| 09:59:11 | openstackgerrit | Merged openstack/nova master: Update compute rpc version alias for ussuri https://review.opendev.org/719315 | |
| 11:09:44 | kashyap | artom: I've responded to your feedback; thanks for the commentary. Hope that makes sense. | |
| 11:09:49 | kashyap | artom: Also see the important Plan-B | |
| 11:27:07 | zigo | bauzas: Hi there! I suppose FUP doesn't mean what's in this urban dictionnary: https://www.urbandictionary.com/define.php?term=FUP :) | |
| 11:27:33 | zigo | Fair Usage Policy ? | |
| 11:27:41 | kashyap | zigo: Yeah, that's a ridiculous acronym that I keep saying people not to use. | |
| 11:27:50 | kashyap | Just say 'fix-up'. | |
| 11:28:08 | kashyap | Clear writing is a sign of clear thinking. Don't use mindless acronyms. | |
| 11:28:19 | kashyap | But that requires hardwork, and it's easy to be lazy | |
| 11:28:36 | kashyap | [Not saying it anyone in particular, BTW :D, just saying it out loud.] | |
| 11:28:57 | zigo | DMT TLA ... :P | |
| 11:30:02 | zigo | TMD TLA I mean. | |
| 11:41:42 | bauzas | zigo: Follow-Up Patch ;) | |
| 11:46:35 | zigo | :) | |
| 12:29:01 | lyarwood | stephenfin: random question, any idea where _get_vcpu_total was removed in the libvirt driver? I'm trying to rebase a series from mdbooth and I can't find where it was removed and what it was replaced with. | |
| 12:29:23 | stephenfin | it would have been in Train | |
| 12:29:24 | lyarwood | stephenfin: looks like you refactored things around here for the pcpu stuff | |
| 12:29:31 | stephenfin | git log -S _get_vcpu_total | |
| 12:29:43 | lyarwood | TIL | |
| 12:31:00 | lyarwood | odd that tig couldn't find it | |
| 12:31:17 | lyarwood | I thought the searching in tig did the same tbh | |
| 12:31:46 | lyarwood | I guess it's just looking at the subject, meh. | |
| 12:43:47 | zigo | Are you guys planning the RC1 for today or tomorrow? | |
| 12:58:32 | gibi | zigo: today | |
| 12:59:57 | gibi | zigo: do you have a critical thing? | |
| 13:03:26 | zigo | gibi: No, just wonder when I'll be able to package it for Debian ! :P | |
| 13:03:55 | gibi | zigo: cool. I will ping you when the release patch merges | |
| 13:04:09 | gibi | zigo: and please let us know if somehing breaks for you | |
| 13:04:41 | zigo | It's gona take some time until I can spawn a first VM with Ussuri. It's going to be maybe next week... | |
| 13:04:49 | zigo | I guess some of my puppet stuff will break, etc. | |
| 13:11:35 | gibi | zigo: we have 2 weeks for additional RC if needed | |
| 13:12:19 | zigo | Usually, I can install the release between the first rc and the final releases. | |
| 13:12:28 | gibi | cool | |
| 13:12:36 | gmann | bauzas: thanks | |
| 13:30:25 | artom | sean-k-mooney, re - your point about changing the default machine type downstream/in ooo only | |
| 13:30:37 | artom | I'll be honest, I only trust upstream's CI with this :P | |
| 13:36:46 | sean-k-mooney | artom: we are chaning nova-next to use q35 | |
| 13:37:04 | sean-k-mooney | and we could change the default in devstack too if we want too | |
| 13:37:12 | sean-k-mooney | but i just am not sure we should change it in nova | |
| 13:38:06 | sean-k-mooney | if we change it in nova and you cold migrate or you live migrate and then hard reboot the machine type would change | |
| 13:38:10 | sean-k-mooney | and that can break things | |
| 13:39:34 | lyarwood | sean-k-mooney: if we don't stash and use the original somehow | |
| 13:39:42 | sean-k-mooney | so without recording the machine type in the instance which we dont do today when its not set in the image its not really safe from an upgrades perspective to change the default. | |
| 13:39:47 | sean-k-mooney | lyarwood: yes we dont | |
| 13:39:57 | lyarwood | yup | |
| 13:40:00 | sean-k-mooney | we also dont schdule on this today | |
| 13:40:10 | sean-k-mooney | which is less then ideal | |
| 13:40:36 | lyarwood | so this is less about setting defaults and more about proving support? | |
| 13:40:48 | lyarwood | and allowing it to be used in new deployments | |
| 13:40:59 | sean-k-mooney | no not really | |
| 13:41:11 | sean-k-mooney | i think in our product we should make the switch for new deployments | |
| 13:41:18 | sean-k-mooney | upstream im not sure if we can in nova | |
| 13:41:25 | lyarwood | right but we can in devstack | |
| 13:41:33 | lyarwood | I didn't mean that Nova would change behaviour | |
| 13:41:40 | sean-k-mooney | yep we can in any install tool | |
| 13:41:40 | lyarwood | it would just support deployment tooling that did | |
| 13:41:54 | sean-k-mooney | because on upgrade they can just set the old default or not set it at all | |
| 13:42:30 | sean-k-mooney | lyarwood: kashyap's spec is chaning the nova defaults | |
| 13:42:42 | sean-k-mooney | lyarwood: which is what i was talking to artom about | |
| 13:42:48 | sean-k-mooney | its why i -1'd it | |
| 13:43:10 | sean-k-mooney | i would like to supprot have default be configureable via a new hw:profile extra spec | |
| 13:43:28 | sean-k-mooney | so you can opt in to different defaults but not actully change them | |