Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-18
14:42:07 mriedem so i'd like to take that back to him instead of just saying, 'i have no f'ing clue what you're talking about'
14:42:07 bauzas mriedem: welcome in the club
14:42:08 openstackgerrit Gergely Csatari proposed openstack/nova master: Checking the parameters of servers-actions.inc https://review.openstack.org/327112
14:42:18 cdent jaypipes: I think there's a good song in there somewhere
14:42:28 sfinucan jaypipes: I see https://review.openstack.org/#/c/361140/ didn't get in before the spec freeze. Think it's a fair candidate for the exception process?
14:42:32 mriedem cdent: every country western song ever
14:42:45 mriedem sfinucan: not imo
14:43:01 cdent mriedem: need to add some tears in my ears from crying on my pillow over you
14:43:04 jaypipes sfinucan: not up to me. but I will review today regardless.
14:43:08 sfinucan mriedem: no?
14:43:17 bauzas oh, sfinucan reminded me one
14:43:18 sfinucan any particular reason?
14:43:48 mriedem sfinucan: because at this point we're overcommitted and the only exceptions i'm interested in are for priorities or things that impact all of nova, not narrow use cases
14:44:02 bauzas mriedem: https://review.openstack.org/#/c/450122/18 is getting 2 +2s from jaypipes and me but I refrained my +W, so I leave you use your axe
14:47:42 mriedem i'm -2 on the vgpus one also
14:47:44 mriedem same reason
14:47:48 sfinucan mriedem: Those use cases are the primary use cases for a lot of our customers
14:48:04 sfinucan the VGPU less so. That needs more exploration, IMO
14:48:08 mriedem sfinucan: then tell me which of the other red hat priority blueprints you'd like to defer in it's place
14:48:19 mriedem emulator threads?
14:48:23 mriedem secure console proxy?
14:48:28 mriedem your other pci scheduler one?
14:48:38 sfinucan emulator threads is done
14:49:06 sfinucan the other PCI scheduler is a two patch change, ~100 line change
14:49:54 sfinucan and, if Gerrit's logs are anything to go by, I'm going to be very fortunate to get the secure console proxy stuff in. No one wants to review it :(
14:50:19 sfinucan the PCI use cases are my primary focus this cycle. There's no lack of reviewer bandwidth on my end
14:56:50 openstackgerrit Peter Hamilton proposed openstack/nova master: Add configuration options for certificate validation https://review.openstack.org/457678
14:56:51 mriedem sfinucan: you can work with artom on the tagged attach/detach stuff then
14:57:03 mriedem sfinucan: honestly look at what we've already approved https://blueprints.launchpad.net/nova/pike
14:57:47 voelzmo @johnthetubaguy I've updated https://review.openstack.org/#/c/416997 with some comments, not sure how we should continue the discussion
14:59:13 johnthetubaguy voelzmo: here is fine, for me it was a case of consistency
14:59:32 sfinucan mriedem: Yeah, I've been horse trading with him for reviews on the secure console proxy stuff, heh :)
14:59:55 johnthetubaguy voelzmo: its a strange API to only support this for half of the nic types, thats really hard API docs and validation, etc
15:00:09 johnthetubaguy voelzmo: but maybe I am seeing it all wrong
15:00:53 mriedem speaking of deleting ports,
15:00:57 mriedem let's fix latent bugs https://review.openstack.org/#/c/452577/
15:01:13 voelzmo @johnthetubaguy I understand the consistency argument, I just fear that it adds scope that I didn't mean to include. Not sure how special the documentation and code really will get. From what I've seen it is already pretty special in the sense that it sets the 'remove port' flag based on whether nova creates it or the user passed it in
15:01:21 sfinucan mriedem: Also get your point about being oversubscribed, but these are the things I'm paid to care about. If push came to shove, could we drop the secure console proxy work in favour of that
15:02:13 johnthetubaguy voelzmo: but saying you can customise only one of those cases seems strange.
15:02:54 sfinucan *that 'share-pci-between-numa-nodes' spec?
15:03:23 voelzmo @johnthetubaguy I agree that for the sake of symmetry that would make sense. Have you heard of someone wanting to keep ports created by nova?
15:04:55 mriedem sfinucan: well, melwitt was also saying in here yesterday that accurately reporting boot from volume disk usage was important for red hat customers, and the answer to fixing that has been claims in the scheduler and shared storage pool resource aggregates
15:05:04 openstackgerrit Gábor Antal proposed openstack/nova master: Fix the FakeDriver using same hypervisor names https://review.openstack.org/456237
15:05:16 openstackgerrit Gábor Antal proposed openstack/nova master: [WIP] Transform instance.live_migration_rollback notification https://review.openstack.org/402124
15:05:24 mriedem sfinucan: and that's a thing melwitt has been trying to get resolved since at least newton, and we keep saying, "once this is done, and once this is done..."
15:05:27 mriedem and it keeps getting pushed out
15:07:45 sdague oomichi: I'm confused by your -1 here - https://review.openstack.org/#/c/454854/2
15:08:50 sfinucan mriedem: I can't speak as to the relative importance of the two so I guess I better go ask :)
15:08:52 sfinucan Crucially though, if either of those took precedence would you be OK with us dropping secure console proxy in favour of one of them?
15:10:35 johnthetubaguy voelzmo: I know I wanted that to re-use an IP a few times
15:11:06 voelzmo @johnthetubaguy and you knew that during VM creation already? Because that's where the user will be able to specify this flag
15:11:27 voelzmo Changing it after the fact is not a thing, currently
15:11:55 mriedem sfinucan: maybe, but it sounds like that's something you need to discuss with your entire team first,
15:12:05 mriedem because there are several blueprints your team is involved in
15:12:17 mriedem and you guys are going to need to agree before you start proposing something to drop i think
15:13:07 sfinucan mriedem: Yup, we've a team meeting tomorrow. I'll bring that up then and see what the story is
15:38:36 johnthetubaguy voelzmo: the other part is making this like the delete_on_termination we have for volumes, but I don't 100% remember the details
15:39:40 openstackgerrit Sylvain Bauza proposed openstack/nova master: Destroy the ReqSpec object when deleting the instance https://review.openstack.org/391060
15:52:15 edleafe Trying to create a functional test that simulates 1000 computes. Would I do this by creating a single n-cpu service and 1000 ComputeNode objects? If so, how do I add those ComputeNode objects to the service's ResourceTracker?
15:52:28 edleafe Or am I completely lost?
15:53:00 mriedem edleafe: did you see my reply about this to cdent's placement update in the ML?
15:53:17 mriedem edleafe: i'm not sure a functional test makes sense for this, since it's just a report, it wouldn't actually fail
15:53:36 mriedem edleafe: i dug out yingxin's tool from the austin summit when he was testing the filter scheduler vs the caching scheduler,
15:53:49 mriedem it might need some tweaking, but the readme says you can run it against a single-node devstack
15:53:52 mriedem so i'd probably start there
15:54:16 edleafe mriedem: no, didn't see your reply yet
15:54:33 bauzas edleafe: I agree with mriedem, I'm pretty sure our infra wouldn't like to have a job faking 1000 nodes for each patch
15:54:46 mriedem bauzas: ed was working on an in-tree functional test i think
15:54:50 mriedem which just simulates things in the db
15:54:53 mriedem and runs the scheduler
15:54:57 edleafe why wouldn't it fail? If you have inventory/allocations that don't meet the request, shouldn't it fail?
15:55:06 mriedem edleafe: i mean the test doesn't really fail
15:55:14 mriedem it's a perf test which is used to compare results
15:55:26 mriedem so with an actual TestCase, what do you compare it to for the benchmark?
15:55:29 mriedem that's all i mean
15:55:31 edleafe And this wasn't going in-tree - it was more of a tool to test our assumptions
15:55:38 mriedem edleafe: ok, that tool already exists
15:55:39 bauzas mriedem: not sure I understand the reasoning behind running 1000 nodes
15:55:40 mriedem we should re-use it
15:55:53 edleafe it does?
15:55:53 bauzas and we already have all the infra for running functional tests
15:56:33 bauzas you can just castascall and run all your services with the fake driver
15:56:45 bauzas plus all the fixtures
15:56:46 edleafe bauzas: the question was whether claiming in scheduler or conductor was better when hitting the race situation
15:57:17 bauzas edleafe: so, that's not needing a functional test - it's different
15:57:34 bauzas what you need is to run a testbed for verifying some things
15:57:41 edleafe bauzas: ok, functional "tool"
15:57:51 bauzas you can write that using the existing fixtures
15:58:06 edleafe mriedem: which tool are you referring to?
15:58:11 bauzas but I think it should rather be something for the implementation :)
15:58:38 mriedem edleafe:
15:58:39 mriedem http://lists.openstack.org/pipermail/openstack-dev/2017-April/115553.html
15:58:48 bauzas FWIW, I think discussing about whether the claim post should be in the conductor or the scheduler is an implementation detail that needs verification during the implementation phase
15:58:54 bauzas I was actually planning to do so
15:59:27 mriedem edleafe: https://github.com/cyx1231st/nova-scheduler-bench
15:59:37 mriedem bauzas: that's why this came up
15:59:56 bauzas honestly, I don't want to defer the spec acceptance by that
16:00:01 edleafe mriedem: thanks - I'll dig into this
16:00:05 mriedem i.e. is it better to retry in the scheduler where we already have the hosts, or conductor which requires the full retry
16:00:11 mriedem bauzas: i don't either

Earlier   Later