Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-09
15:13:26 sean-k-mooney lyarwood: i dont think cinder is choosing the WWN for the volume
15:16:41 lyarwood right yeah that would make sense
15:22:29 stephenfin bauzas: nw. I've replied to the rest of your comments also
15:42:15 bauzas yeah I'll review again
15:42:36 gibi lyarwood: do I understand correclty from the scrollback that making some cinder test serial would help merging patches?
15:42:55 lyarwood gibi: removing c-vol from the computes would
15:43:33 lyarwood gibi: if we really need to run another c-vol service then it needs to be on the controller alongside the original
15:43:41 lyarwood gibi: just building an env now to prove things
15:43:43 stephenfin lyarwood, gibi, sean-k-mooney: any aversion to adding mypy to pre-commit?
15:43:59 sean-k-mooney not speciriclly no
15:44:00 stephenfin assuming I can do it while respecting mypy-files
15:44:04 lyarwood stephenfin: against the files that are changing?
15:44:10 gibi lyarwood: thanks for looking into that, sign me up for review where there is something I can push
15:44:12 sean-k-mooney i have been bitten by flake8 passed by pep8 didnt
15:44:14 stephenfin yeah
15:44:30 gibi lyarwood: does having c-vol along with n-cpu is an invalid config?
15:44:33 lyarwood stephenfin: no issues assuming it isn't adding a huge amount of delay
15:44:34 sean-k-mooney i have gotten used to relying on pre-commit to do that form me
15:44:35 stephenfin sean-k-mooney: me too :( I ran it on HEAD but it turns out I broke something then fixed it in the next change
15:44:46 stephenfin me too * 2 :)
15:44:53 stephenfin pre-commit FTW
15:44:59 gibi stephenfin: no problem for me I dont use pre-commit :)
15:45:18 stephenfin gibi: You're missing out. It's pretty great :)
15:45:45 lyarwood gibi: no, the issue here is with the default c-vol backend, LVM/iSCSI, that you can't have >1 running version of in an env AFAICT
15:46:06 gibi stephenfin: I do run fast8 py39 and functional-py39 on every commit I push (except on old stable branches where there is no py39 or py38 support)
15:46:10 lyarwood gibi: we end up mapping different volumes from different backends to the computes with the same WWN (world wide name) that should be unqiue
15:46:10 bauzas wife is sick and I need to taxi her to the doctor
15:46:37 gibi lyarwood: so we cannot have multiple backend per compute?
15:46:50 stephenfin gibi: That's better than me. I run what I think are relevant tests and then let the CI do the rest. Our tests take too long to run locally
15:46:58 lyarwood gibi: we can't have multiple LVM/iSCSI backed c-vol's in the same env
15:47:22 gibi stephenfin: I have a beefy blade in a lab to run unit and func test (and devstack on baremetal to test sriov)
15:47:48 lyarwood it's not great but better than nothing
15:47:51 stephenfin I've a four year old laptop 0:)
15:48:01 lyarwood refresh is 3 soooooooooooo ;)
15:48:16 gibi still a laptop is slow, you should ask for a lab :)
15:49:40 gibi lyarwood: so in a real deployment there can only one c-vol service using the LVM/iSCSI backend?
15:49:59 gibi lyarwood: sorry that I'm slow to understant this :)
15:50:21 lyarwood gibi: I don't think that has ever been enforced but the LVM/iSCSI backend is only ever used for testing
15:50:48 gibi OK, then I stop worrying :)
15:50:53 gibi it is just test :)
15:52:19 lyarwood I'll just caveat all of the above with the fact that no one from Cinder has agreed with any of that in the bug as yet
15:52:26 lyarwood so I might be missing the point entirely
15:52:49 lyarwood but two volumes with the same WWN connected to the same host smells like something that will bork devicemapper
15:53:21 gibi if it fixes the CI and let us merge the api db compaction before FF then I'm happy to take the hit if we need to revert the change later
15:53:24 gibi :)
15:53:54 lyarwood gibi: is that stuck in a recheck loop?
15:54:01 gibi pretty much yes
15:54:04 lyarwood gah okay
15:54:11 lyarwood let me confirm and then I can push some changes
15:54:22 gibi the Queens one is recheckd through the whole weekend and still bouncing back
15:54:36 gibi mostly with the detach issue
15:54:46 gibi but also kernel panic, and recenlty with POST_FAILURe
16:07:32 stephenfin sean-k-mooney: because I didn't write it down, can you remind me again how you were suggesting me map a project to a hypervisor in '/os-hypervisors'? Was it metadata?
16:07:59 stephenfin sean-k-mooney: to clarify, if I say "get all hypervisors relevant to this user", what should I be filtering on?
16:10:58 sean-k-mooney use the existing metadtaa keys for tenant isolation
16:11:15 sean-k-mooney one sec ill get it
16:12:05 sean-k-mooney https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement
16:12:26 sean-k-mooney you would be looking for filter_tenant_id*
16:12:30 lyarwood sigh, why is devstack writing out /etc/cinder/cinder-api-uwsgi.ini when we only deploy c-vol
16:12:58 stephenfin sean-k-mooney: great
16:14:30 sean-k-mooney basically if the host is not a member of an aggreate with filter_tenant_id* then anyone coudl view it
16:14:48 sean-k-mooney if it is then only does listed in that can view it
16:16:11 sean-k-mooney the way i was suggsing doing it was look for all host wiht filter_tenant_id=<my-project> and if that is none then allow all hosts
16:16:33 sean-k-mooney you coudl do it other ways fo course but i think that is what i suggested in the past
16:16:34 stephenfin gmann, gibi: replied on https://review.opendev.org/c/openstack/nova/+/765798
16:16:52 stephenfin the policy checks are correct, but we're not filtering the compute nodes retrieved
16:22:51 gibi stephenfin: good potin
16:22:54 gibi point
16:37:16 sean-k-mooney stephenfin: by the way are you ok with https://review.opendev.org/c/openstack/nova/+/773792 now? i did not remove the extension check since bauzas suggested i should add it when i discussed it previously
16:37:59 sean-k-mooney it hit the cinder issue i was disucssing with lyarwood eairler so i have not rechecked it yet
16:38:30 stephenfin Holy s***, OSC has a REPL??
16:39:06 stephenfin sean-k-mooney: I'd like to remove it if we can. I'm literally trying to test if it will work as we speak :)
16:39:15 sean-k-mooney yes....
16:39:19 sean-k-mooney you didnt know that
16:39:25 stephenfin but tbf I didn't read your replies yet. Looking
16:39:34 sean-k-mooney stephenfin: we can remove it
16:39:37 sean-k-mooney i tested it locally
16:39:52 sean-k-mooney if you request a feild that does not exist it does not break anything
16:40:05 sean-k-mooney also it passed tempest for the run where i did not have the extension test
16:40:29 stephenfin hmm, so we can avoid a second API check with no consequences?
16:40:34 sean-k-mooney so if bauzas is ok with me removing it and gibi is oke to review it again i can remove it
16:40:46 sean-k-mooney stephenfin: its cached
16:40:55 sean-k-mooney we will only ever check once right
16:41:00 sean-k-mooney oh way not we refresh the cache
16:41:12 stephenfin yup :)
16:41:13 sean-k-mooney ya ok we can kill the check
16:41:26 stephenfin though tbf, that refresh is behind a timer
16:41:27 sean-k-mooney i just didnt want to revert it and get -2 again
16:41:47 stephenfin so it's not as harmful as a I thought
16:41:51 stephenfin *as I
16:42:23 sean-k-mooney cool weell i need to recheck due to the cinder issue so i can respin instead but dont want to keep reving it for no reason
16:42:43 sean-k-mooney well not no reason but going back an forth
16:43:24 stephenfin Thanks fair
16:43:30 sean-k-mooney stephenfin: did i do https://review.opendev.org/c/openstack/nova/+/773792/8/nova/network/neutron.py#2043 correctly by the way
16:43:34 stephenfin bauzas is AFK at the moment
16:43:43 stephenfin so maybe gibi can weigh in?
16:43:54 stephenfin nah, what gibi suggested is what I was expecting
16:44:01 stephenfin :param: foo foo foo
16:44:05 stephenfin foo foo foo
16:44:16 stephenfin well, :return:

Earlier   Later