Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-22
15:40:09 sean-k-mooney but we can still have a late failure on the compute node if the ip address cant be allocated
15:40:21 gibi sean-k-mooney: yes
15:40:27 sean-k-mooney so i guess for now we can document that as a known issue untille the neutron bug is resolved
15:40:48 sean-k-mooney which ultimatly shoudl be done via a port resouce request so we can scedule on it
15:43:55 gibi sean-k-mooney: the neutron bug either resolved in the segments plugin by really updating the IP inventory for deferred ports (not just for imediate ports) or it can be resolved by adding IP resource to the the resource request
15:44:55 sean-k-mooney yep both would owrk but updateing the inventory wont help with schduling
15:45:20 sean-k-mooney since nova is not asking plamcnent for an ip allocatoin haveign reserved=total wont prevent it from returning a host in that aggreate
15:45:40 gibi true
15:45:49 sean-k-mooney so really the apprcoh that neutorn is currenly taking wont really do anything useful
15:46:10 sean-k-mooney its not in the allcoation so it might as well not exist
15:46:25 bauzas yup, what sean-k-mooney said
15:46:30 bauzas it's not related to my series
15:46:44 bauzas the scheduler doesn't verify this resource class
15:47:21 gibi sean-k-mooney: I don't know if the segments plugin do anyithing special when the reserved == total, in theory it can remove computes from the aggregate to prevent scheduling
15:47:47 gibi but I agree, the ultimate solution is to use resource_request
15:48:04 sean-k-mooney it could but i dont think it does
15:50:05 openstackgerrit Lucas Alvares Gomes proposed openstack/nova master: [OVN] Explicitly set nova-next job to ML2/OVS https://review.opendev.org/c/openstack/nova/+/776944
15:50:05 openstackgerrit Lucas Alvares Gomes proposed openstack/nova master: DO NOT REVIEW: Test OVN devstack module https://review.opendev.org/c/openstack/nova/+/776945
15:51:48 openstackgerrit Ghanshyam proposed openstack/nova stable/stein: DNM: testing stein cap https://review.opendev.org/c/openstack/nova/+/776816
15:52:03 gibi sean-k-mooney: it might does: https://github.com/openstack/neutron/blob/787444ac9ecbc6db123294c33549b97cafe72fd5/neutron/services/segments/plugin.py#L323-L325 but I did not verified it
15:53:40 bauzas stephenfin: you had some changes that I should be reviewing, right?
15:53:49 bauzas gibi: heh
15:54:15 stephenfin Yes please. Either the secure boot series or the API DB compaction series
15:54:30 stephenfin I'll get to the routed networks patches before EOD, promise :)
15:54:42 bauzas gibi: fwiw, we should just support routed networks in Nova now, and in case people see problems with Neutron, they would test it at least
15:54:54 bauzas stephenfin: no worries
15:55:13 gibi bauzas, stephenfin: I'm on the routed net series as we speek
15:55:25 bauzas (also doing some downstream stuff but meh ;) )
15:55:40 bauzas stephenfin: patches ?
15:55:44 gibi bauzas: agree about releasing the nova support for routed net and deal with the fallout later
15:56:15 bauzas I guess at least https://review.opendev.org/c/openstack/nova/+/774904/6 and the above
15:58:06 bauzas and https://review.opendev.org/c/openstack/nova/+/771419/ then
16:03:02 stephenfin bauzas: https://review.opendev.org/c/openstack/nova/+/776679 above and below
16:27:33 gibi bauzas: I'm +2 on both route net patches now. I have two small nits in https://review.opendev.org/c/openstack/nova/+/773976 for a follow up
16:27:52 bauzas on a meeting but thanks, will look
16:31:11 openstackgerrit Merged openstack/nova master: Support interface attach with QoS ports https://review.opendev.org/c/openstack/nova/+/756530
16:31:22 gibi \o/ ^^
16:33:33 gibi who has good grasp on lower constarints bumps? We have this trivial hyperv feature but the lower-constraint change become pretty hairy https://review.opendev.org/c/openstack/nova/+/763550
16:38:44 bauzas gibi: I worked on it a bit, what's your concern ?N
16:39:24 gibi bauzas: the amount of lower-constraint change that is proposed there to satisfy the pip solver
16:39:30 bauzas hah
16:40:15 bauzas gibi: wow
16:40:23 sean-k-mooney gibi: that a lot of change to lc
16:40:31 gibi yes, hence I raising my flag
16:40:53 sean-k-mooney bumping os-brick and os-win
16:41:03 sean-k-mooney then that transitivly is bumping the rest
16:41:25 sean-k-mooney oh they are coming form os-brick
16:41:51 gibi I'm not even sure all these bumps are needed or it was just _a_ solution but not a solution with _minimal_ amount of bumps
16:42:27 sean-k-mooney right
16:42:45 sean-k-mooney the commit message say syncing os-brick and nova miniums
16:43:15 bauzas could we ask the report to split the change and bump l-c for each release ?
16:43:30 lyarwood so I looked at that review and then ran away
16:43:33 sean-k-mooney we cant bump lc in stable
16:43:50 lyarwood but something to keep in mind is that the release of os-brick that is pulling in has a regression
16:43:55 bauzas like, if 80% of the lib bumps come from the same os-brick upgrade, then it should be a separate patch to ease reviews (and potential revert)
16:43:59 lyarwood not that it changes the bump but still
16:44:30 bauzas given the amount of bumps, I'd certainly like to have a conservative approach
16:44:32 sean-k-mooney well nova really should have it direct deps not all the transitive ones
16:44:44 bauzas right
16:45:04 sean-k-mooney but also im not sure that os-brick is nessally using its real min deps
16:45:05 bauzas but i'm not an expert of transitivity for l-c
16:47:17 gibi yeah, me neither
16:47:23 sean-k-mooney os-brick is an optional dep of nova too its only need if you have cinder and os-win is only needed if you have hyperv
16:47:35 sean-k-mooney its seams incorrect to sync the os-brick deps into nova
16:48:57 sean-k-mooney im going to just bump the two libs os-brick and os-win and run the lc tox env locally
16:49:33 gibi sean-k-mooney: I expect that you will recreate the error https://review.opendev.org/c/openstack/nova/+/763550/12#message-2f6b7331b58c77ee91a0a69d0ee187ded003d623
16:50:30 gibi from that it seems that the minimum oslo.context needed by nova is different from the minimum oslo.context needed by os-brick. and the pep solver detects this
16:51:05 sean-k-mooney ya this is because of the new resolver
16:51:31 sean-k-mooney the old resolver used the first requirement for a dep
16:51:41 sean-k-mooney the new one looks at all of them
16:51:44 bauzas sean-k-mooney: if you feel brave enough, I'd prefer to have os-brick being bumped in a separate change
16:51:56 bauzas again, we need to think of reverts
16:52:05 bauzas and pulling a whole set of changes doesn't help this
16:52:33 sean-k-mooney well currently its one patch but so wew would be pulling the bump and the feature
16:52:46 sean-k-mooney that need the bump if we revert
16:54:39 gibi I give up for today. See you all tomorrow o/
16:54:47 bauzas gibi: thanks
18:48:16 sean-k-mooney bauzas: gibi https://review.opendev.org/c/openstack/nova/+/763550/12//COMMIT_MSG#22
18:48:38 sean-k-mooney bauzas: gibi we need to bump coverage but all oter lower contrats dont need to be bumped
18:48:59 sean-k-mooney so just coverage, os-brick and os-win
20:47:51 openstackgerrit Merged openstack/nova stable/ussuri: Disallow CONF.compute.max_disk_devices_to_attach = 0 https://review.opendev.org/c/openstack/nova/+/772985
#openstack-nova - 2021-02-23
07:03:48 openstackgerrit Lucian Petrut proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550
07:48:21 openstackgerrit Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362
07:48:22 openstackgerrit Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363
07:48:24 openstackgerrit Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944
09:02:19 openstackgerrit Brin Zhang proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336
09:02:23 openstackgerrit Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs https://review.opendev.org/c/openstack/nova/+/764292
09:02:25 openstackgerrit Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311
09:02:27 openstackgerrit Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380
09:02:31 openstackgerrit Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API https://review.opendev.org/c/openstack/nova/+/766726
09:09:37 openstackgerrit Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704
09:12:58 openstackgerrit Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Show usage APIs https://review.opendev.org/c/openstack/nova/+/768509
09:13:56 openstackgerrit Brin Zhang proposed openstack/nova master: Replace tenants* with projects* of policies https://review.opendev.org/c/openstack/nova/+/765315
09:51:40 slaweq gibi: hi, did You saw errors like https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4f9/777015/1/check/neutron-tempest-multinode-full-py3/4f9f062/testr_results.html already?
09:51:51 slaweq I saw it at least twice in last few days
09:51:53 slaweq in same test
09:52:04 slaweq do You want me to report new bug for that?
10:25:27 openstackgerrit Lucas Alvares Gomes proposed openstack/nova master: [OVN] Explicitly set nova-next job to ML2/OVS https://review.opendev.org/c/openstack/nova/+/776944
10:25:30 openstackgerrit Lucas Alvares Gomes proposed openstack/nova master: DO NOT REVIEW: Test OVN devstack module https://review.opendev.org/c/openstack/nova/+/776945
10:32:46 gibi slaweq: hi, let me check it

Earlier   Later