Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-21
15:06:14 sean-k-mooney i need to lookup exactly hwat the numeric datatype in sqlachemy is doing
15:06:25 sean-k-mooney i fyou dont know off the top of yoru head dont worry about it
15:07:18 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:20 sean-k-mooney sorry wrong line i mean 241
15:07:32 sean-k-mooney its for how many decimal places to keep
15:07:44 sean-k-mooney depending on your db configuriton it can be 0
15:08:14 sean-k-mooney this would keep 3 decimal places i bleive
15:09:10 dansmith oh okay so it probably doesn't change the size of the float but just how its rendered?
15:10:12 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:40 sean-k-mooney so i think its truncating/normalisigin the float when its stored
15:10:58 sean-k-mooney i think 3 would give us a granularity of 0.01
15:11:10 sean-k-mooney and hopfully round to that
15:11:16 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:34 sean-k-mooney ya no worries
15:12:07 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:30 sean-k-mooney i cant see sqlacammy mapping this ot a custom numic type or a string
15:12:47 sean-k-mooney so i think it must be using a standard float of some lenght underneath
15:13:13 sean-k-mooney i just dont want to do an acidental db data migration as a result
15:13:27 dansmith yeah
15:13:36 sean-k-mooney we should be able to verify that by looking at the schema before and after if we populate some data
15:14:13 dansmith yeah that's probably true
15:15:06 dansmith sean-k-mooney: scale – the numeric scale for use in DDL CREATE TABLE.
15:15:10 dansmith that tells me it changes the schema
15:15:24 sean-k-mooney fun... thanks for looking
15:15:27 dansmith https://docs.sqlalchemy.org/en/20/core/type_basics.html#sqlalchemy.types.Numeric
15:17:08 sean-k-mooney " Numeric returns Python decimal.Decimal objects by default" so scale might influcance how we read back the existing data
15:17:28 dansmith https://dev.mysql.com/doc/refman/8.4/en/precision-math-decimal-characteristics.html
15:17:29 sean-k-mooney im not sure if it will actuly change the data storage in the db
15:17:42 dansmith that shows the number of bytes it uses based on the digits
15:18:28 sean-k-mooney "If D is omitted, the default is 0. If M is omitted, the default is 10."
15:18:36 dansmith "decimal_return_scale" is a way to affect just the reading I think
15:18:44 sean-k-mooney my guess is sqlite has diffent defaults
15:19:16 sean-k-mooney D is the number of digits to the right of the decimal point (the scale)
15:19:52 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:20:14 dansmith yeah, but total digits affect byte length
15:20:29 sean-k-mooney yep which we are not changing just shifting the scale
15:20:40 sean-k-mooney dansmith: but that shoudl be visable in the schema for sure
15:20:49 dansmith but surely that requires rewriting the data
15:20:50 sean-k-mooney so we can look more closely at this
15:20:56 sean-k-mooney we need test for this too in anycase
15:22:16 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:21 sean-k-mooney well not evn that long really
15:22:37 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:23:12 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:13 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:46 dansmith MengyangZhang[m]1: go ahead, we're done
15:24:22 bauzas I think his question was whether we will have cross-project sessions in the PTG
15:24:32 sean-k-mooney specificaly with cidner
15:24:53 bauzas for sure, Uggla and myself will ask Neutron, Cinder and Watcher communities if they want
15:24:54 sean-k-mooney MengyangZhang[m]1 has a number of cinder adjcent topics that affect nova
15:25:19 bauzas like every PTG, we should have one hour per x-p session, nothing booked yet
15:25:56 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:56 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:26:36 sean-k-mooney the main commonality is you want to live apply qos polices (for diffent resoces) to a vm
15:26:45 sean-k-mooney so volumes, ports ectra
15:26:50 MengyangZhang[m]1 and per-project control
15:27:06 MengyangZhang[m]1 neither cinder nor neutron support that now
15:27:13 sean-k-mooney nor those nova
15:27:26 sean-k-mooney we do not provide api to work on set of vms
15:28:02 sean-k-mooney out side of multi create and list apis all our api only work on a single vm
15:28:27 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:41 sean-k-mooney s/concep/concept/
15:32:02 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:33:27 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:34:15 sean-k-mooney MengyangZhang[m]: its qustionable if it should be implented at all
15:34:32 sean-k-mooney if we have the live update it might be ok
15:35:01 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:41 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:37:02 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:09 sean-k-mooney otherewise its an api bug on there side
15:38:52 sean-k-mooney so yes i agree the current behavior in cinder is a bug
15:39:03 sean-k-mooney or at least not supprot in nova
15:39:13 sean-k-mooney nova does not supprot all neutron api extintions
15:39:43 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:40:02 sean-k-mooney or the multi provider extention that allows a neturon network to ahve more then one phsynet
15:40:43 sean-k-mooney that can be valid when using ironic but it does not mean its valid when using nova libvirt virt driver
15:41:26 sean-k-mooney the line between bug and driver dependent feature is soemtiem a grey areay
15:41:52 sean-k-mooney backend qos is likely fine to allow change at any time in cinder
15:42:36 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:44:23 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:45:25 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:47:02 sean-k-mooney ack
15:57:44 opendevreview ribaudr proposed openstack/nova master: FUP: Improve libvirt fixture for hostdevs https://review.opendev.org/c/openstack/nova/+/945232
15:57:44 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
18:14:46 dansmith vmware ci has been broken for quite some time it feels
18:15:17 dansmith the run I just checked seems to be failing with volume backed rebuild, which has been a thing for what two cycles?
20:10:17 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:13:53 sean-k-mooney dansmith: i dont think they every got that to work
20:14:07 dansmith sean-k-mooney: what?
20:14:10 dansmith who?
20:14:10 sean-k-mooney dansmith: i know we have not merged all the patches they submited to fix thing
20:14:17 sean-k-mooney dansmith: the vmware ci
20:14:20 dansmith ah
20:15:10 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:28 dansmith okay
20:19:11 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:55 melwitt (if I understood his comment right anyway)
20:21:52 dansmith melwitt: okay was just trying to keep this moving, but fair enough
20:22:10 dansmith I'm glad you were able to distill something out of that because I was highly confused
20:23:55 melwitt ack

Earlier   Later