Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-17
13:56:43 mriedem belmoreira: so if you have suggestions about what definitely not to do there it would be appreciated
13:56:54 sean-k-mooney it wouldnt be nova-mange but a nova-metadefs tool or something could be used to do an export i guess
13:57:16 mriedem belmoreira: specifically https://review.opendev.org/#/c/666857/9/nova/compute/manager.py@1329
14:01:32 belmoreira mriedem thanks for ping me
14:02:38 openstackgerrit Eric Fried proposed openstack/nova master: Only allow one scheduler service in tests https://review.opendev.org/682486
14:04:22 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Re-propose the flavor extra spec validation spec https://review.opendev.org/682655
14:07:32 efried mriedem: Re test_walk_versions, when I tried turning those debug conf switches on I wound up with enough data to blow up subunit. So I reinstrumented the logging fixture to write to a file in /var/log/mysql (to save me having to capture yet another directory). In local experimentation, that's about 35MB...
14:08:30 efried (that's with the sqlite impl tho)
14:09:16 efried I also knocked the timeout factor back down to 1 to improve chances of hitting the bug... although I'm not actually convinced that's going to make the difference.
14:12:06 bhagyashris mriedem: Hi,
14:17:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: Error out interrupted builds https://review.opendev.org/666857
14:17:55 gibi bauzas, mriedem: ^^
14:18:22 bauzas gibi: I need to go to the school to get my children but I'll look at ^ after
14:18:36 gibi bauzas: thanks
14:20:31 sean-k-mooney stephenfin: i have a scoping question for you and i guess to nova in general. should the scope of os-vif be expaned to include the neutron related pices of nova/networks/*
14:20:52 stephenfin give me an example
14:21:29 sean-k-mooney well im wondering if we shoudl move https://github.com/openstack/nova/tree/master/nova/network/neutronv2
14:21:53 sean-k-mooney os-vif is often incorrectly refered to as the nova neutron interface lib
14:22:09 sean-k-mooney implying its used to handel the comunicaiton between nova and neutron
14:22:13 sean-k-mooney but its actully not
14:22:39 sean-k-mooney i was wondering if we finally remove nova-networks shoudl we move the neutron interaction code to os-vif
14:22:59 stephenfin hmm, not a bad idea
14:23:03 sean-k-mooney give the nova core team are os-vif cores it would not realy change that aspect
14:23:25 stephenfin I'd probably need to see some patches before I can make any verdict though, tbh
14:23:25 sean-k-mooney but it would make os-vif more like os-bricks
14:23:35 stephenfin and get nova-network removed, heh
14:23:40 openstackgerrit Eric Fried proposed openstack/nova master: DNM: Get rid of 'Aborted connection' mysql errors https://review.opendev.org/682661
14:23:45 sean-k-mooney ya its just something i was thinking about over the weekend
14:23:50 efried zzzeek: ----^
14:24:23 efried and mriedem
14:24:28 sean-k-mooney stephenfin: we still tecnically support drivers in nova for the networking laywer
14:24:56 sean-k-mooney stephenfin: so i was thinking of porting using that
14:29:16 mriedem lyarwood: melwitt: just fyi i'm planning on doing stable branch reviews throughout this week to prepare for some releases next thursday (next week) to coincide with RC1 on master
14:35:15 bhagyashris efried, mriedem: Hi I would like you insight on https://review.opendev.org/#/c/612626/ . Address all the review commets.
14:36:15 bhagyashris s/you/your
14:47:20 efried bhagyashris: I can take a look, but this isn't my area of expertise.
14:48:25 efried bhagyashris: I also suspect a db change is going to be too high-risk for us to land in Train at this point.
15:00:26 sean-k-mooney mriedem: by the way when i was working on https://review.opendev.org/#/c/682515/ i notice the sqlalchemy-migrate does not use upper constratins and test fail if i add it
15:01:11 sean-k-mooney i need to look at why those py27 test failed too i only ran the sqlite test locally so i guess i missed somthing
15:01:34 sean-k-mooney but shoudl sqlalchemy use upper-constraints or is it intentionally not?
15:06:10 sean-k-mooney *sqlalchemy-migrate
15:31:40 melwitt mriedem: ack
15:54:45 shilpasd efried: on behalf of bhagyashris, it will be great help if we target this in Train
15:55:42 efried mriedem: Is it feasible to merge db changes at this stage? https://review.opendev.org/#/c/612626/
15:56:38 sean-k-mooney efried: technically before rc1 its doable
15:56:44 sean-k-mooney just clicking the link
15:56:50 sean-k-mooney but what db changes are needed
15:57:37 sean-k-mooney shilpasd: usein "is" for boolean comparison is deprecated by the way
15:57:49 sean-k-mooney so we shoudl not do "if instance.is_volume_backed is False:"
15:58:03 efried I guess it doesn't have db changes
15:58:25 sean-k-mooney this is technically an api change however right
15:58:36 sean-k-mooney so it would have a micro version bump?
15:59:14 sean-k-mooney we would be changng the semantics of the api
16:00:50 efried yeah, I guess that's technically true.
16:01:15 mriedem that's not an api change really
16:01:23 mriedem it's saying, don't count disk usage for servers tha tare volume-backed
16:01:25 shilpasd sean-k-mooney: thanks for points, request you to add same on patch, so that will be addressed and tracked
16:01:34 mriedem efried: i would not rush that into train
16:01:35 sean-k-mooney mriedem: yes
16:01:58 mriedem i would also split it into at least 2 patches, one that introduces the db api changes for the is_volume_backed stuff so that can be reviewed and tested separately
16:02:02 mriedem because it involves sqla magic
16:02:02 sean-k-mooney and before it did so is that not an api change because the value now has a different meaning
16:02:06 mriedem and therefore will need scrutiny
16:02:16 efried bhagyashris, shilpasd: ^
16:02:33 shilpasd mriedem: efried: understood
16:02:56 mriedem sean-k-mooney: consider that in rocky (i think it was) we fixed scheduling and the resource tracker to not request disk for volume-backed servers,
16:03:02 sean-k-mooney people keep telling me there is a reason we allow bfv instance to have a root_gb!=0
16:03:10 mriedem which would indirectly cause the os-hypervisors API to no longer report disk usage for those volume-backed servers,
16:03:19 mriedem so yes it changes the api behavior, but it's fixing latent busted behavior
16:03:29 sean-k-mooney sure
16:03:54 sean-k-mooney but im wonder ing why we allow bfv guests to have a root_gb set to non 0 in general
16:04:12 mriedem we don't by default policy anymore
16:04:15 sean-k-mooney we dont allow non bfv flavor with root_gb=0
16:04:31 mriedem see os_compute_api:servers:create:zero_disk_flavor
16:04:32 sean-k-mooney i think that is only in the ohter direction
16:04:40 mriedem https://docs.openstack.org/nova/latest/configuration/policy.html
16:05:18 mriedem and sqla-migrate doesn't use upper-constraints because...it's never needed to
16:05:20 sean-k-mooney ya that is not what im asking
16:05:27 mriedem it hardly changes, is released like once per year
16:05:28 sean-k-mooney mriedem: ok
16:05:43 sean-k-mooney ill remove the todo
16:05:52 sean-k-mooney the one i was adding
16:06:01 mriedem sean-k-mooney: also https://review.opendev.org/#/c/669738/
16:06:19 sean-k-mooney so that policy flag prevent instace with root disk = 0 if they are not bfv
16:06:29 mriedem correct
16:06:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pull up compute node queries to init_host https://review.opendev.org/682680
16:06:41 shilpasd mriedem: what is sqla-migrate?
16:06:54 sean-k-mooney but we dont have a simplar policy for the oppisite
16:07:07 mriedem sqlalchemy-migrate
16:07:15 sean-k-mooney e.g. prevent bfv instance using a flavor with root_gb!=0
16:07:19 shilpasd ohh, tnx, got it
16:07:32 sean-k-mooney that is the policy i think we should consider adding
16:07:55 mriedem so you want to force all deployers to duplicate all of their flavors?
16:08:05 sean-k-mooney the main objection i have heard to that is requireing two sets of flavor. 1 for bfv and 1 for non bfv
16:08:18 mriedem i would not do that without some additional feature to make bfv simpler with volume-defined flavors or something
16:08:44 mriedem https://review.opendev.org/#/c/511965/
16:09:01 mriedem let's just do that in V
16:09:09 mriedem V for Volumessssss
16:09:24 sean-k-mooney well it woudl be a policy flag taht coudl default to false so not force them but im not sure how common it is to mix bfv and non bfv on the same host
16:09:57 sean-k-mooney i got the impression people tend to segration the bfv hosts form the rest but i could be wrong

Earlier   Later