| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-02 | |||
| 12:20:22 | gibi | if the external service try to preempt any kind of allocation not just servers then I would vote for extending the placement api | |
| 12:21:53 | sean-k-mooney | ya i remember talking to jay an cdent about possible evoltuion of placment to supprot timed allcoation for blazar reservations at one point | |
| 12:22:18 | sean-k-mooney | the concensous at the time was blazar shoudl manage the timing itself at least for now | |
| 12:22:52 | sean-k-mooney | but i have wondered if we ever woudl want to have differnt type fo allcoation in the futrue that had semantic meanign to placemnt | |
| 12:23:19 | sean-k-mooney | consumer types while not an alocation type would provide a way to do that without placment knowing about it | |
| 12:23:24 | gibi | sean-k-mooney: is timed allocation ~= reservation? | |
| 12:23:33 | sean-k-mooney | gibi: yes | |
| 12:23:49 | gibi | yeah that would be an interesting thought experiment | |
| 12:24:13 | gibi | I don't know how alive blazar is these days | |
| 12:24:44 | sean-k-mooney | for now i think im going to leave it there and instead look at your reparenting spec then i need to get back to the smartnic one | |
| 12:26:35 | gibi | there are soo many interesting things to work on :) | |
| 12:26:44 | gibi | thanks for looking at re-parenting | |
| 12:27:07 | sean-k-mooney | gibi: for timed allocation to work i think you would need some kind of web hook callback in placment that could call our external events api to tell us it expired but ye i should focus on thing that people are actully working on for a bit | |
| 12:28:24 | gibi | sean-k-mooney: that would be a bit similar to the external event that neutron sends us when a bound port is deleted. nova then unplugs the vif | |
| 12:28:44 | sean-k-mooney | yep that was exactly what i was thinking of | |
| 12:28:45 | gibi | sean-k-mooney: so basically placement would tell us that the allocation is expired and nova would ~delete~ the instaance | |
| 12:28:57 | sean-k-mooney | yep | |
| 12:29:09 | sean-k-mooney | or tell balzar if that is the endpoint you regestred | |
| 12:29:13 | gibi | the delete would be a bit harsh but maybe shelve offload or snapshot would be ok | |
| 12:29:26 | gibi | snapshot + delete | |
| 12:30:03 | sean-k-mooney | basically i was thinging you would pass a url to call back an a payload to send whne cratign the payload | |
| 12:30:08 | sean-k-mooney | *alloction | |
| 12:31:45 | sean-k-mooney | gibi: not sure if that is a good idea or not but for nova we would make the payload be an extrenal event payload allocation-exired-event possible with an acction or encode the action in a flavor extra spec or image property | |
| 12:32:16 | sean-k-mooney | i had not fully tought though the full semantics but ya that was the general thing i had in mind | |
| 12:33:15 | gibi | sean-k-mooney: yeah these sounds like a workable set of ideas | |
| 12:35:21 | sean-k-mooney | gibi: by the way i hope you dont mind i fast appoved the cyborg admin client spec i notice that you went and fixed the blueprint | |
| 12:36:50 | sean-k-mooney | given the time zone differece i did not think the nits justifed asking them to respin or submit a followup | |
| 12:38:07 | gibi | sean-k-mooney: no problema | |
| 12:38:28 | gibi | sean-k-mooney: I did not notice the missing bp until I tried to approve the bp after I saw the spec merged | |
| 12:40:29 | opendevreview | Stephen Finucane proposed openstack/os-vif stable/ussuri: [Stable Only] Drop lower constraints testing https://review.opendev.org/c/openstack/os-vif/+/794210 | |
| 12:41:23 | opendevreview | Stephen Finucane proposed openstack/os-vif stable/train: [Stable Only] Drop lower constraints testing https://review.opendev.org/c/openstack/os-vif/+/794211 | |
| 12:41:44 | stephenfin | gibi: lyarwood: Would appreciate eyes on those to unblock the other patches in os-vif ^ | |
| 12:41:51 | stephenfin | that's what we agreed last week, iirc | |
| 12:41:55 | stephenfin | also, sean-k-mooney: ^ | |
| 12:42:10 | gibi | on it | |
| 12:42:36 | sean-k-mooney | more or less although i didnt end put trying to fix it beyond victoria | |
| 12:44:22 | gibi | stephenfin: note that I have no +2 rights :) | |
| 12:44:34 | stephenfin | oh, lovely | |
| 12:45:01 | stephenfin | so I guess I need to poke elodilles ? | |
| 12:46:27 | sean-k-mooney | well actully i forgot to bring this up | |
| 12:46:40 | sean-k-mooney | anyone agaisnt me creating an os-vif-release team for stable | |
| 12:47:13 | sean-k-mooney | i would like to be able to do stable review there too | |
| 12:47:29 | sean-k-mooney | i can bring it up on the next nova meeting | |
| 12:47:52 | sean-k-mooney | i ment to do it last week and forgot this week | |
| 12:47:53 | stephenfin | I'd just add core to stable-core, personally. Probably something for the next meeting | |
| 12:48:40 | gibi | I'm not against it, we need agreemet from stable cores though :) | |
| 12:48:42 | sean-k-mooney | i could i wanted to add a new group to not need to add people to nova-stable-maint for os-vif stable | |
| 12:48:50 | lyarwood | yup I'm not against that | |
| 12:50:08 | sean-k-mooney | gibi: im +2 on the reparenting spec too but i did not give +w to allow melwitt and other to review | |
| 12:50:45 | gibi | sean-k-mooney: ack, thanks | |
| 12:56:57 | sean-k-mooney | stephenfin: should you have not cherry picked the stable train patch form stable ussuri | |
| 12:57:48 | stephenfin | no point. It was just merge conflict hell and they're stable only | |
| 12:58:40 | sean-k-mooney | well normally stable only patches would be cherry picked | |
| 12:58:47 | sean-k-mooney | but ok | |
| 12:59:08 | sean-k-mooney | if its generally effectivly a rewrite then ill change the -1 to +1 | |
| 13:29:23 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 13:45:15 | sean-k-mooney | oh ok | |
| 13:46:20 | sean-k-mooney | i guess its ok to not destroy the secreat for had reboot | |
| 13:46:24 | sean-k-mooney | *hard | |
| 13:46:41 | sean-k-mooney | soft reboot calls hard reboot also by the way if it does not soft reboot after a time out | |
| 14:47:27 | mdbooth | sean-k-mooney: Incidentally, I've always felt that was a misfeature. Soft and hard reboots are quite different things. If the user asks for a soft reboot and it doesn't work, they should get an error (asynchronously, obvs). | |
| 14:49:24 | sean-k-mooney | mdbooth: i think its configurable in the nova config | |
| 14:49:47 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reboot_timeout | |
| 14:50:00 | sean-k-mooney | so by default we dont | |
| 14:50:38 | sean-k-mooney | but it can be enabled | |
| 14:51:09 | sean-k-mooney | which is config driveen api behavior which is awesome... | |
| 14:51:41 | sean-k-mooney | mdbooth: i would much prefer a reboot --gradual or somehting like that to contol that | |
| 15:19:45 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 15:19:45 | opendevreview | Lee Yarwood proposed openstack/nova master: virt: Add destroy_secrets kwarg to destroy and cleanup https://review.opendev.org/c/openstack/nova/+/794252 | |
| 15:21:04 | melwitt | lyarwood: added a comment on the launchpad bug wrt wsgi config | |
| 15:21:14 | lyarwood | melwitt: thanks | |
| 15:32:11 | melwitt | sean-k-mooney: the current proposal is to reflect the allocations indirectly via /usages https://review.opendev.org/c/openstack/placement/+/679441/18/api-ref/source/usages.inc and you can filter by project and user | |
| 15:33:00 | melwitt | gibi: ack, will look | |
| 15:33:12 | gibi | melwitt: thanks | |
| 15:33:19 | sean-k-mooney | melwitt: i see ok | |
| 15:33:22 | opendevreview | Merged openstack/nova master: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/793512 | |
| 15:36:02 | bauzas | sean-k-mooney: gibi: oh, just saw your discussion about reservations | |
| 15:36:13 | bauzas | fwiw, blazar already supports timed reservations | |
| 15:36:42 | bauzas | so, the concern here is that we duplicate allocations into blazar-like reservations | |
| 15:36:56 | bauzas | while an idea could be to add timed allocations in placement | |
| 15:37:07 | bauzas | but that's a massive change | |
| 15:37:14 | sean-k-mooney | yes im aware | |
| 15:37:37 | bauzas | the other issue is with quotas | |
| 15:37:45 | sean-k-mooney | yep | |
| 15:38:14 | sean-k-mooney | unified limits would have to understand consumer types and allow qutos per consumer type not just projects | |
| 15:38:37 | bauzas | that's the problem | |
| 15:39:05 | bauzas | blazar would need to support quotas for resources that are different from current quotas | |
| 15:39:16 | melwitt | I'm working on consumer types this cycle fwiw | |
| 15:39:31 | melwitt | just behind on updating the PS from last feedback | |
| 15:39:54 | bauzas | just explaining one of the usecases | |
| 15:40:03 | bauzas | if I have quota for 10 vCPUs | |
| 15:40:29 | bauzas | could I reserve 20 vCPUs over time provided I only start 10 concurrently? | |
| 15:40:43 | bauzas | I could honesly overload resource usage by this | |
| 15:41:15 | bauzas | I could ask for 1000000 vCPUs provided I only have reservations for 10 by once | |
| 15:42:56 | sean-k-mooney | yep i know there are many issue | |
| 15:43:32 | sean-k-mooney | that is why i was suggesting to belmoreira that we proably dont have the design bandwith this cycle for premtibel instances | |
| 15:43:53 | sean-k-mooney | but i think we should consider it for a future cycle and maybe have a sub team to figure this out | |
| 15:44:11 | bauzas | preemptible instances are way simplier to design | |
| 15:44:19 | bauzas | since we don't have reservations | |
| 15:44:45 | bauzas | there are just prioritized instances and non-priortized ones | |