| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-17 | |||
| 13:50:36 | sean-k-mooney | so we can take the same data driven approch or we can define a custom_ prefix or seveler other thigns | |
| 13:50:48 | stephenfin | stevedore | |
| 13:50:52 | sean-k-mooney | in the spec we figured out how to use stevedore | |
| 13:50:54 | sean-k-mooney | ya | |
| 13:51:03 | stephenfin | yeah, glance can just hook into that like we do | |
| 13:51:05 | stephenfin | easy as | |
| 13:51:17 | sean-k-mooney | not really | |
| 13:51:42 | sean-k-mooney | this is an api that has existed for 6+ years | |
| 13:51:54 | sean-k-mooney | and other pojects depend on it | |
| 13:52:01 | stephenfin | they can keep the API | |
| 13:52:18 | sean-k-mooney | yes but unless we can expose our flavor form it | |
| 13:53:03 | sean-k-mooney | *flavor extra specs via the new mechanisum at the metadefs endpoin im not sure going our own way is good | |
| 13:53:25 | stephenfin | It should be easy do | |
| 13:53:43 | sean-k-mooney | stevador only works if everythign is installed in teh same place | |
| 13:53:51 | sean-k-mooney | in contienr it wont work | |
| 13:54:11 | stephenfin | If they can pull our definitions in, they just need to transform them so they match whatever we had before | |
| 13:54:28 | stephenfin | then we provide a tool to dump in their JSON metadef style | |
| 13:54:35 | stephenfin | and push a patch to Glance | |
| 13:54:41 | sean-k-mooney | ya bout you would have have to install nova in the glance contienr | |
| 13:54:49 | sean-k-mooney | thats not good | |
| 13:55:01 | stephenfin | better than what we have at the momenty | |
| 13:55:06 | sean-k-mooney | havign a nova tool to generate teh metadefs and copy it could work | |
| 13:55:16 | stephenfin | oh, I thought you meant the tool | |
| 13:55:45 | sean-k-mooney | no i ment stevadore | |
| 13:56:05 | sean-k-mooney | stevador was a suggestion for other project to add validtors | |
| 13:56:11 | sean-k-mooney | to nova | |
| 13:56:20 | stephenfin | Yup, gotcha. My bad | |
| 13:56:20 | sean-k-mooney | not to share data to other projects | |
| 13:56:25 | mriedem | belmoreira: this might have an impact to compute start times when using the ironic driver https://review.opendev.org/#/c/666857/ | |
| 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 | sean-k-mooney | but it would make os-vif more like os-bricks | |
| 14:23:25 | stephenfin | I'd probably need to see some patches before I can make any verdict though, tbh | |
| 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 | sean-k-mooney | and before it did so is that not an api change because the value now has a different meaning | |
| 16:02:02 | mriedem | because it involves sqla magic | |
| 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 | |