| opendevreview | benlei proposed openstack/nova master: Abort live migration task when stop nova compute service https://review.opendev.org/c/openstack/nova/+/938223 | 00:57 |
|---|---|---|
| opendevreview | benlei proposed openstack/nova master: optimize process of get connector for swap volume https://review.opendev.org/c/openstack/nova/+/945177 | 00:57 |
| ishanwar[m] | Hi Folks... (full message at <https://matrix.org/oftc/media/v1/media/download/AfIljfPE94kqyEbidICMKCnOaBBquL9y8M186dozy6czq9FKuNXkU37cf0hQWWGf7ByL_Gxne4_JEcywIr82jMNCeV_3bP0QAG1hdHJpeC5vcmcvc2NSRlZCQUlsclpPc2lZWUZuZE9Ramdt>) | 06:22 |
| ishanwar[m] | Can anyone explain how I can find the correct constant | 06:22 |
| ishanwar[m] | * correct constant ? | 06:22 |
| *** sambork_ is now known as sambork | 07:41 | |
| opendevreview | benlei proposed openstack/nova master: FIX: optimize process of get connector for swap volume https://review.opendev.org/c/openstack/nova/+/945177 | 08:38 |
| zigo | It's been now 5 years that I opened a merge request for the Nova project to add a /healthcheck from oslo.middleware in the default api-paste.ini. Is this enough time so that the team delcares a "game over" from the team that wanted to improve the oslo.middleware healthcheck before merging ? | 09:38 |
| frickler | zigo: it might help if you include a link to your review (we don't talk about merge requests with gerrit). and yes, without interacting with the community regularly, getting things done is sometimes difficult | 09:48 |
| zigo | https://review.opendev.org/c/openstack/nova/+/724684 | 09:48 |
| gibi | zigo: I think the nova team wants to do https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/per-process-healthchecks.html | 09:49 |
| zigo | That's a good thing, though I still need to patch Nova to be able to hook an haproxy to its API, that's kind of annoying. | 09:50 |
| zigo | Especially considering the oslo.middleware healthcheck was implemented in all other projects. | 09:52 |
| sean-k-mooney | zigo: we dont plan to ever use oslo.middleware for healthchefcs as we have stated in the past given its a security risk | 11:02 |
| sean-k-mooney | and doe snot actully do anything useful for nova | 11:02 |
| sean-k-mooney | specificlly the detailed mode is unsafe https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/healthcheck/__init__.py#L159-L160 | 11:04 |
| sean-k-mooney | zigo: for any of the apis you can and should hit the microverion endpoint instead | 11:05 |
| sean-k-mooney | which si the root of the api | 11:06 |
| zigo | sean-k-mooney: That's a very silly answer. How do you explain that all other projects do have the /healthcheck and that it works for me? | 11:58 |
| opendevreview | Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks https://review.opendev.org/c/openstack/nova/+/945204 | 12:00 |
| opendevreview | Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks https://review.opendev.org/c/openstack/nova/+/945204 | 12:05 |
| ishanwar[m] | sean-k-mooney dansmith I have raised a PR based on our discussion in the previous meeting | 12:07 |
| ishanwar[m] | let me know your thoughts | 12:08 |
| sean-k-mooney | zigo: if it works for you your free to ignore out advice and change ti in your downstream packageing, i dont think any project should ever enable it by default | 12:27 |
| zigo | sean-k-mooney: *ALL* projects enabled it by default... | 13:02 |
| zigo | Only Nova refuses to do so. | 13:02 |
| dansmith | sean-k-mooney: I updated this for some verbiage after your last +2, would you mind re-applying? should be easy: https://review.opendev.org/c/openstack/nova-specs/+/943486 | 13:44 |
| opendevreview | Dan Smith proposed openstack/nova master: Support glance's new location API https://review.opendev.org/c/openstack/nova/+/891036 | 13:49 |
| sean-k-mooney | sorrry was doing somethign else but sure i can look now | 14:02 |
| sean-k-mooney | i did skim v7 the comment gibi had on how you were usign burned we actully my intall reacitno too but then i deciced that since you did not defien the teim i would jsut follow your uasage instead of my internal definition but i generally agreed with that change | 14:03 |
| sean-k-mooney | dansmith: by the way related to the latch term, i starged using bruned because i think of the single use devices like eFueses | 14:04 |
| dansmith | burned is mine! | 14:05 |
| dansmith | but yeah, new rev defines that clearly-er | 14:05 |
| sean-k-mooney | +2w, v8 looks good to me. as an aside are you plannig to move on to the placement swap issue next or complte the integration with the glance api for multiple locations or your change for making glance the enforcer? if the next priortiy is tbd thats fine im just wonderign what you planned ot do next | 14:08 |
| sean-k-mooney | dansmith: im kind of aware thaty you expressed interest in a a few differnet semi high priority issues and it felt like you had a lot on your plate | 14:09 |
| dansmith | sean-k-mooney: so I missed that the locations stuff ever finally landed, and that's partially because I expected the glance people to iterate on my nova patch until it was passing | 14:09 |
| dansmith | but apparently they just merged without it working | 14:09 |
| dansmith | so I just refreshed that and will look at the test results | 14:09 |
| gibi | it is Friday, I'm burned already, needs an external tool applied on me during the weekend to unburn me before I can be used again next week | 14:09 |
| dansmith | gibi: ++ :) | 14:10 |
| sean-k-mooney | lol | 14:10 |
| dansmith | gibi: I'll allow you to use my trademarked term under license :) | 14:10 |
| gibi | understood, send me the necessary invoice | 14:10 |
| sean-k-mooney | gibi: can i recommend good food and a audio or phsyical book | 14:10 |
| dansmith | sean-k-mooney: tbh, I'm pretty steamed about the gpt stuff. I've had that up with cinder, nova, glance changes since last year and I have run out of energy to push people to do simple reviews on it | 14:10 |
| gibi | sean-k-mooney: physical book for sure along with the book :) | 14:10 |
| gibi | sorry along with the food | 14:10 |
| dansmith | sean-k-mooney: so at the moment we're in a reasonable state with image inspection, so I'm not really motivated to push on it at the moment | 14:11 |
| gibi | and sunshine, we are getting proper sunshine here now finally | 14:11 |
| dansmith | sean-k-mooney: the nova side OTU stuff is, I think, ready for some critical review so I'm planning to put up a strawman fix for the placement swap issue in the next week or so so we can argue about all kinds of WWJD lore | 14:12 |
| sean-k-mooney | dansmith: i mean we can chat about it in the ptg or internally but ya it might be better to focus on the things we have control over like placement and see if other can get invovled in teh efforts we dont | 14:12 |
| dansmith | yup | 14:12 |
| opendevreview | Merged openstack/nova-specs master: Add one-time-use-devices spec https://review.opendev.org/c/openstack/nova-specs/+/943486 | 14:12 |
| dansmith | I'm exhausted from pushing people to review, so my hissy fit is to just let it sit.. nobody else will notice, but I'll feel better | 14:13 |
| sean-k-mooney | gibi: same we have had blue skys every morning for the last 2 weeks, cold but clear although they go gray every afternoon | 14:13 |
| sean-k-mooney | dansmith: speaking of thanks for the constructive review of the mod_wsgi thing. ill try and get the final version ready before i finsh today but no rush to review | 14:14 |
| gibi | for OTU I'm still planning to a session of local testing with the WIP patch | 14:14 |
| gibi | *for | 14:14 |
| dansmith | sean-k-mooney: no problem I'm happy with how that has gone for sure and nice to get some quick iterative review | 14:15 |
| sean-k-mooney | if needed i can proably do the same with virual or real hardware | 14:15 |
| dansmith | gibi: cool, thanks | 14:15 |
| sean-k-mooney | dansmith: by the way tehre is one other thing we could consider for the one time ues devices | 14:16 |
| sean-k-mooney | i dont think we should do this | 14:16 |
| sean-k-mooney | bu tlivbirt has an optional deamon that can do device leasing | 14:17 |
| sean-k-mooney | https://libvirt.org/formatdomain.html#device-leases | 14:17 |
| sean-k-mooney | i dont think that helps use because we still need all the placement stuff for schduling | 14:18 |
| dansmith | hmm, but that would encourage people to go direct to libvirt, right? and also, we'd have to sync our state with that in order to .. yeah, scheduling :) | 14:18 |
| sean-k-mooney | right i was going to say the only usecase i see for that is we could take a least and potially never drop it | 14:19 |
| sean-k-mooney | but if we dont refence a lease in our xml i think it ignore it | 14:19 |
| sean-k-mooney | puluse we do not deploy teh relevent deamon in our product downstream | 14:19 |
| sean-k-mooney | so i just wanted to make you aware this exists | 14:19 |
| sean-k-mooney | but i think the soluiton we have is better | 14:19 |
| dansmith | yeah interesting thanks for the pointer | 14:20 |
| sean-k-mooney | dansmith: i kind of know the answer but should i file a new bug for the mod_wsgi thing i have related bug to https://bugs.launchpad.net/nova/+bug/1882094 because it was an incomplete bug fix | 14:52 |
| dansmith | oh that's the previous one huh | 14:52 |
| sean-k-mooney | im trying to see if bogdan filed anything new upstream | 14:53 |
| dansmith | so, it seems like we should have a new bug, yeah, especially if we're going to backport this | 14:54 |
| sean-k-mooney | i was shortening the release note and was going to link the bug an dwas like this is proably not useful to them | 14:54 |
| dansmith | and it seems like it's probably something worth backporting to me (or at least being an option) | 14:55 |
| dansmith | yes, dump that in a bug I'd say | 14:55 |
| sean-k-mooney | ok ill go do that now | 14:55 |
| sean-k-mooney | dansmith: while i have you. do you know if this requires a data migration. https://review.opendev.org/c/openstack/watcher/+/945199/1/watcher/db/sqlalchemy/models.py#250 im debatingin if we need to add a new column, use that going forward and drop the current one after a few release or if this is only a change in the model but not the db schema | 15:05 |
| sean-k-mooney | i need to lookup exactly hwat the numeric datatype in sqlachemy is doing | 15:06 |
| sean-k-mooney | i fyou dont know off the top of yoru head dont worry about it | 15:06 |
| dansmith | hmm, yeah, I'm not sure what scale=3 means there.. is that an order of magnitude that auto-chooses an integer size or something? | 15:07 |
| sean-k-mooney | sorry wrong line i mean 241 | 15:07 |
| sean-k-mooney | its for how many decimal places to keep | 15:07 |
| sean-k-mooney | depending on your db configuriton it can be 0 | 15:07 |
| sean-k-mooney | this would keep 3 decimal places i bleive | 15:08 |
| dansmith | oh okay so it probably doesn't change the size of the float but just how its rendered? | 15:09 |
| sean-k-mooney | we are getting back "0.0 for standard_deviation_before_audit" when we calulated "reduces standard deviation to 0.08665386000750841." | 15:10 |
| sean-k-mooney | so i think its truncating/normalisigin the float when its stored | 15:10 |
| sean-k-mooney | i think 3 would give us a granularity of 0.01 | 15:10 |
| sean-k-mooney | and hopfully round to that | 15:11 |
| dansmith | ack, so that kinda seems like it's in the "view" layer and doesn't change the schema, but I'm definitely talking out of the wrong orifice.. I have no real idea | 15:11 |
| sean-k-mooney | ya no worries | 15:11 |
| sean-k-mooney | i also havent really dug into this much ill look at the doc before going back to the review properly | 15:12 |
| sean-k-mooney | i cant see sqlacammy mapping this ot a custom numic type or a string | 15:12 |
| sean-k-mooney | so i think it must be using a standard float of some lenght underneath | 15:12 |
| sean-k-mooney | i just dont want to do an acidental db data migration as a result | 15:13 |
| dansmith | yeah | 15:13 |
| sean-k-mooney | we should be able to verify that by looking at the schema before and after if we populate some data | 15:13 |
| dansmith | yeah that's probably true | 15:14 |
| dansmith | sean-k-mooney: scale – the numeric scale for use in DDL CREATE TABLE. | 15:15 |
| dansmith | that tells me it changes the schema | 15:15 |
| sean-k-mooney | fun... thanks for looking | 15:15 |
| dansmith | https://docs.sqlalchemy.org/en/20/core/type_basics.html#sqlalchemy.types.Numeric | 15:15 |
| sean-k-mooney | " Numeric returns Python decimal.Decimal objects by default" so scale might influcance how we read back the existing data | 15:17 |
| dansmith | https://dev.mysql.com/doc/refman/8.4/en/precision-math-decimal-characteristics.html | 15:17 |
| sean-k-mooney | im not sure if it will actuly change the data storage in the db | 15:17 |
| dansmith | that shows the number of bytes it uses based on the digits | 15:17 |
| sean-k-mooney | "If D is omitted, the default is 0. If M is omitted, the default is 10." | 15:18 |
| dansmith | "decimal_return_scale" is a way to affect just the reading I think | 15:18 |
| sean-k-mooney | my guess is sqlite has diffent defaults | 15:18 |
| sean-k-mooney | D is the number of digits to the right of the decimal point (the scale) | 15:19 |
| MengyangZhang[m]1 | sean-k-mooney: will there be cross team meetings with cinder, nova, and neutron in PTG?... (full message at <https://matrix.org/oftc/media/v1/media/download/AfRhuSqMkzGRPT1IM6jcHy5ZYwYvit_U0k_CNqT84oK7I5BU854Qixl3oF2HCpu4QremZagsKNeqU5VWuo-_Ab9CeWAWMPTwAG1hdHJpeC5vcmcvbVd1bmZRaVFxZFdJRmRrekZFQnZpdXVN>) | 15:19 |
| dansmith | yeah, but total digits affect byte length | 15:20 |
| sean-k-mooney | yep which we are not changing just shifting the scale | 15:20 |
| sean-k-mooney | dansmith: but that shoudl be visable in the schema for sure | 15:20 |
| dansmith | but surely that requires rewriting the data | 15:20 |
| sean-k-mooney | so we can look more closely at this | 15:20 |
| sean-k-mooney | we need test for this too in anycase | 15:20 |
| sean-k-mooney | MengyangZhang[m]1: if you write very long messages in matix by the way we only get part of it | 15:22 |
| sean-k-mooney | well not evn that long really | 15:22 |
| sean-k-mooney | i think it might be because you did a multiline message we only see the first line and then a link to the rest | 15:22 |
| sean-k-mooney | MengyangZhang[m]1: to answer your question i think there is a cross project session but Uggla is cordinating that | 15:23 |
| MengyangZhang[m]1 | sorry about it, let me know if I can resend it now. don't want to interfere the current conversation on other topics | 15:23 |
| dansmith | MengyangZhang[m]1: go ahead, we're done | 15:23 |
| bauzas | I think his question was whether we will have cross-project sessions in the PTG | 15:24 |
| sean-k-mooney | specificaly with cidner | 15:24 |
| bauzas | for sure, Uggla and myself will ask Neutron, Cinder and Watcher communities if they want | 15:24 |
| sean-k-mooney | MengyangZhang[m]1 has a number of cinder adjcent topics that affect nova | 15:24 |
| bauzas | like every PTG, we should have one hour per x-p session, nothing booked yet | 15:25 |
| * bauzas needs to drive afk | 15:25 | |
| MengyangZhang[m]1 | Regarding this blueprint: https://blueprints.launchpad.net/nova/+spec/enhanced-granularity-and-live-application-of-qos, would it be possible to discuss it with cinder, nova, and neutron in PTG? We've created three separate blueprints to proposal the same idea to different projects. | 15:25 |
| MengyangZhang[m]1 | What we want is to have a uniform QoS interface, across nova, cinder and neutron, that supports per-project control and allow live updates to existing resources — whether its Cinder volumes or Neutron ports. | 15:25 |
| sean-k-mooney | the main commonality is you want to live apply qos polices (for diffent resoces) to a vm | 15:26 |
| sean-k-mooney | so volumes, ports ectra | 15:26 |
| MengyangZhang[m]1 | and per-project control | 15:26 |
| MengyangZhang[m]1 | neither cinder nor neutron support that now | 15:27 |
| sean-k-mooney | nor those nova | 15:27 |
| sean-k-mooney | we do not provide api to work on set of vms | 15:27 |
| sean-k-mooney | out side of multi create and list apis all our api only work on a single vm | 15:28 |
| sean-k-mooney | so the concep of applying a change to all resocue in a given project is a very large depatrue to how nova works today | 15:28 |
| sean-k-mooney | s/concep/concept/ | 15:28 |
| MengyangZhang[m]1 | understood, the per project control of qos utlimatly should be implemented on cinder and neutron side. we want to bring in nova is because cinder frontend qos relies on nova libvirt driver to pass the qos parameters to qemu and also per our earlier discussion that how cinder currently supports updating qos policy to volumes in use is a bug to nova. | 15:32 |
| opendevreview | sean mooney proposed openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945028 | 15:33 |
| sean-k-mooney | MengyangZhang[m]: its qustionable if it should be implented at all | 15:34 |
| sean-k-mooney | if we have the live update it might be ok | 15:34 |
| sean-k-mooney | but nova does not supprot the changing of the qos policy on port or volumes today while its attached to a vm | 15:35 |
| sean-k-mooney | so there is a depency first we need live update supprot then if they want orchstration api to apply those updates to a set of resouce they need to be able to notify nova of those changes | 15:35 |
| sean-k-mooney | MengyangZhang[m]1: any change in cinder or neutron that would change the xml that we have to generated should only be allowed in neutorn/cidner if there is an integration with nova to make that take effect | 15:37 |
| sean-k-mooney | otherewise its an api bug on there side | 15:37 |
| sean-k-mooney | so yes i agree the current behavior in cinder is a bug | 15:38 |
| sean-k-mooney | or at least not supprot in nova | 15:39 |
| sean-k-mooney | nova does not supprot all neutron api extintions | 15:39 |
| sean-k-mooney | it may be valid to use them in oter contexts (zun or ironic) but for example nova does not supprot the extion that allow you to change the mtu of a neuton netowrk | 15:39 |
| sean-k-mooney | or the multi provider extention that allows a neturon network to ahve more then one phsynet | 15:40 |
| sean-k-mooney | that can be valid when using ironic but it does not mean its valid when using nova libvirt virt driver | 15:40 |
| sean-k-mooney | the line between bug and driver dependent feature is soemtiem a grey areay | 15:41 |
| sean-k-mooney | backend qos is likely fine to allow change at any time in cinder | 15:41 |
| sean-k-mooney | frontend qos is not implemtned by cinder as you said its impletned by nova vai libvirt. that where the impednce mismatch comes form | 15:42 |
| opendevreview | sean mooney proposed openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945028 | 15:44 |
| MengyangZhang[m]1 | yes, all makes sense, that's not the case for neutron since qos there is implemented by the underlying network driver. Can we just leave this to the PTG meeting coz my team will be there and we can all reach an agreement and close this topic | 15:45 |
| sean-k-mooney | ack | 15:47 |
| opendevreview | ribaudr proposed openstack/nova master: FUP improve and add integration tests for PCI SR-IOV servers https://review.opendev.org/c/openstack/nova/+/944106 | 15:57 |
| opendevreview | ribaudr proposed openstack/nova master: FUP: Improve libvirt fixture for hostdevs https://review.opendev.org/c/openstack/nova/+/945232 | 15:57 |
| dansmith | vmware ci has been broken for quite some time it feels | 18:14 |
| dansmith | the run I just checked seems to be failing with volume backed rebuild, which has been a thing for what two cycles? | 18:15 |
| dansmith | melwitt: this works for me, if I push it up would you +W if I +2 even though it's my own work? https://termbin.com/cpvj | 20:10 |
| sean-k-mooney | dansmith: i dont think they every got that to work | 20:13 |
| dansmith | sean-k-mooney: what? | 20:14 |
| sean-k-mooney | dansmith: i know we have not merged all the patches they submited to fix thing | 20:14 |
| dansmith | who? | 20:14 |
| sean-k-mooney | dansmith: the vmware ci | 20:14 |
| dansmith | ah | 20:14 |
| sean-k-mooney | i belive the rebuild thign is one of the pendign patches but ill admin i have not looked at the vmware patches in like 4 months | 20:15 |
| dansmith | okay | 20:15 |
| melwitt | dansmith: I wasn't saying there's anything wrong or need to be changed fwiw, just pointing it out and have bogdan ack it if he agrees | 20:19 |
| melwitt | (if I understood his comment right anyway) | 20:19 |
| dansmith | melwitt: okay was just trying to keep this moving, but fair enough | 20:21 |
| dansmith | I'm glad you were able to distill something out of that because I was highly confused | 20:22 |
| melwitt | ack | 20:23 |
| sean-k-mooney | dansmith: https://review.opendev.org/c/openstack/nova/+/941095 i think is the fix for https://bugs.launchpad.net/cinder/+bug/2097771 | 20:25 |
| sean-k-mooney | or https://bugs.launchpad.net/nova/+bug/2058225 | 20:26 |
| sean-k-mooney | depending on you perspective | 20:26 |
| sean-k-mooney | but its failing tempest with vmware so http://openstack-ci-logs.global.cloud.sap/openstack-nova-941095-4ptpq/tempest.html | 20:26 |
| dansmith | hrm | 20:35 |
| dansmith | so that's been broken and WIP for like a year | 20:35 |
| sean-k-mooney | i think the current issue is just the key/passwrod | 20:36 |
| sean-k-mooney | i know that they had some neutron networking issues for a while | 20:37 |
| sean-k-mooney | dansmith: im kind of torn, on one hand we didnt spend a lot of time reviewign the vmware fixes | 20:50 |
| sean-k-mooney | dansmith: on the other hand not much progress has been made since we paused the removal but it also has not got worse | 20:50 |
| sean-k-mooney | so its still kind of limping along | 20:51 |
| opendevreview | sean mooney proposed openstack/nova master: wrap wsgi_app.init_application with latch_error_on_raise https://review.opendev.org/c/openstack/nova/+/945028 | 20:52 |
| sean-k-mooney | dansmith: i slightly tweaked the testing and fixed a comment if you can readd +2 | 20:55 |
| sean-k-mooney | im goign to kick of one more run of the operator job and call it a day | 20:55 |
| sean-k-mooney | we can tak a look at the resulst on monday | 20:55 |
| dansmith | it's also wip, so not really a candidate anyway | 21:34 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!