Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-17
14:57:28 bauzas 2/ scheduler as a lib in Queens
14:57:33 edleafe bauzas: baby steps forward, while taking full steps back
14:57:49 bauzas 3/ conductor uses that lib for filtering/weighting in Queens/Rocky
14:58:05 bauzas 4/ other services could possibly be using that scheduler lib by Rocky
14:58:24 bauzas (c) by dansmith for the library thing
14:58:32 bauzas which I totally agree with
14:58:33 edleafe bauzas: no they couldn't, if we start tying scheduler to nova more and more
14:59:26 edleafe instead of getting rid of a nova-ism and making it part of the interface, we're now making scheduler more dependent on that nova-ism
14:59:38 bauzas edleafe: that's a truism, and I don't disagree with your statement
14:59:41 dansmith bauzas: no, it was johnthetubaguy's idea, I just fell in love with it
14:59:48 edleafe making it even less likely that any other service will ever use scheduler
14:59:58 bauzas what I disagree is with you saying that we go into that direction
15:00:15 bauzas dansmith: oops, hail to johnthetubaguy then :)
15:00:29 edleafe dansmith: that contradicts what you were saying earlier: that the scheduler is nova's scheduler
15:00:50 bauzas anyway, back to work for updating the conductor now
15:00:59 edleafe why do any of those steps if the end goal isn't to make it useful for other services?
15:01:01 dansmith edleafe: I don't want it as a library for other projects to use, I want it to be nothing but code in nova (i.e. not a service)
15:01:15 dansmith edleafe: because placement is the generic thing useful for other services
15:01:22 johnthetubaguy placement is for everyone right, and +1 what dansmith just said
15:01:48 edleafe ok, then let's tie scheduler to nova ever more tightly
15:02:16 cdent library is a bit of a misnomer, I guess? We mean something more like "module"?
15:02:21 dansmith cdent: yeah
15:02:37 edleafe cdent: yeah, "library" means generally useful
15:02:52 cdent library would be fun, but seems unlikely. Also, why would we replicate that confusing mass?
15:03:23 johnthetubaguy my think was, stop making RPC API calls to it, since it the process is no longer special, but thats a different thing
15:03:26 edleafe cdent: because the concept of choosing one RP over another is rather generic
15:03:29 dansmith edleafe: I think we've been on this "keep scheduler in nova, split out placement" path for quite a while, but I'm not sure the distinction was made explicit and given the "split the scheduler" talk before that, you're probably not the only one confused by the "plan"
15:03:45 cdent there could be a library for things that filter resource providers that is implemented outside of nova, using more clear techniques
15:04:02 cdent I think that would be useful
15:04:06 dansmith could be,
15:04:06 edleafe cdent: sure, but there was never any work even considered for that
15:04:17 johnthetubaguy cdent: yeah, thats a sepearate, quite interesting thing, that is a library
15:04:24 dansmith and you could also build a generic scheduling library that makes it clear we should dump much of what nova's scheduler does
15:04:32 dansmith and when you guys build that, we can evaluate :)
15:04:40 edleafe cdent: whereas we've spent a lot of effort on cleaning up the interface between nova and the scheduler
15:05:11 cdent edleafe: I still think that interface should be kept as clean and explicit as possible. That's simply good practice.
15:05:30 edleafe cdent: and if the scheduler were an independent library, it could be cleaned up radically, as long as the interface contract was maintained
15:05:50 edleafe cdent: well, that's why I started this conversation.
15:06:01 edleafe We're making the interface dirtier
15:06:10 cdent can someone point me at this dirtying?
15:06:13 johnthetubaguy edleafe: where?
15:06:23 edleafe basing the number of returned hosts on max_attempts
15:06:37 edleafe which is a nova-ism that we've discussed removing in the past
15:06:45 bauzas I would certainly appreciate reviews on my changes
15:07:17 edleafe IOW, any other potential user of scheduler would now get back the number of hosts that nova wants
15:07:51 edleafe IMO, it would be cleaner to make the number of hosts to return per request explicit
15:08:11 edleafe and move max_attempts out of the scheduler config
15:08:14 johnthetubaguy edleafe: so the retry configuration needs to be set by the operator where?
15:08:45 edleafe johnthetubaguy: somewhere in nova's config, not in scheduler's config
15:08:59 johnthetubaguy scheduler config is nova config right now, and there is no plan to change that right?
15:09:02 edleafe johnthetubaguy: Unless, of course, we are deciding to keep the two locked together
15:09:08 johnthetubaguy placement config is a totally different thing
15:09:25 edleafe johnthetubaguy: no plan, correct. It's been pointed out several times as something we need to change
15:09:38 edleafe if we want an independent scheduler
15:09:53 cdent fwiw, edleafe, I agree with you: the config of attempts should be outside of the nova-scheduler's domain, it should accept an arg
15:10:06 cdent _even_ if that code never becomes a lib
15:11:44 bauzas cdent: well, technically, we said to return alternatives by the number of retries
15:11:53 johnthetubaguy seems like you want the retry conf set centrally not different on every compute node, thats the bit that matters I guess?
15:11:59 bauzas cdent: and atm we have that flag in the scheduler group
15:12:29 bauzas although it's settable per compute given it's used by the scheduler.utils module
15:12:44 johnthetubaguy bauzas: hmm, joy
15:13:01 edleafe johnthetubaguy: by not passing the number of hosts to return to the scheduler, it doesn't matter what config file it's set in.
15:13:18 bauzas again, I beg people to review https://review.openstack.org/#/c/465175/ if they have matters
15:13:18 edleafe it's set and unchangeable for any other service
15:13:53 edleafe it seems like since keeping the interface clean is more work, we'll just keep doing things the old way with tying scheduler to nova
15:14:04 edleafe which dansmith says is what we're going to do
15:14:37 johnthetubaguy I am all for keeping the interface clean, it just feels like that belongs inside the scheduler to me, but I am kinda just stuck in the old ways I guess
15:15:08 edleafe johnthetubaguy: so you don't ever see any service other than nova ever ever ever using the scheduler?
15:16:31 johnthetubaguy edleafe: basically no, I could see another seam being added to extract the filter/weigher stuff thats been cut and paste all over the place, and some placement helper utils, but that feels like a set of problems we should ignore for now, so we can make quicker progress
15:17:03 edleafe johnthetubaguy: agree that we shouldn't spend time on it now
15:17:04 dansmith johnthetubaguy: agree
15:17:15 edleafe johnthetubaguy: disagree that we should actively make things worse
15:17:32 edleafe worse == tighter coupling
15:19:02 johnthetubaguy right now there is random util dust sprinkled all over, thats bad, I need to go review the proposed code
15:20:02 sean-k-mooney dansmith: johnthetubaguy out of interest do you ever see a case where i would be allowed to pass a set of claime to nova boot? not saying that is desireable but has that come up as a topic before?
15:20:16 dansmith sean-k-mooney: it has
15:20:25 johnthetubaguy sean-k-mooney: yeah, came up with the watcher folks I think
15:20:49 johnthetubaguy reservations, etc
15:20:52 sean-k-mooney cool was any desion reached on that or was it defered to later
15:21:02 dansmith sean-k-mooney: what do you think? :P
15:21:12 sean-k-mooney much later haha
15:21:14 dansmith we can't even agree which color to paint the bike shed
15:21:27 dansmith well, some of us can, but .. :P
15:23:37 sean-k-mooney ok cool as long as we can at least all agree to use the placement api for track resources and allocations of those resources thats better then what we have today
15:24:24 sean-k-mooney well thats perhaps unfair neutron is already using it for ip pools for the l3 routing stuff so we have made more progress then just agreeing to use the placement api
15:27:59 sean-k-mooney dansmith: by the way you summit talk on the cells v2 work was really good. jays talks on the placement apis were also good to watch
15:28:11 dansmith sean-k-mooney: thanks :)
15:43:42 cfriesen kashyap: what would you think of https://review.openstack.org/#/c/461456 ? The rationale being that it's defined as a realtime mask so if the user specifies "1-2" they should get vCPUs 1 and 2 as realtime.
15:45:41 sfinucan cfriesen: I took a look at it. Looks sensible to me. Do we document support image metadata anywhere though?
15:45:47 sfinucan ...or is that up to Glance to do?
15:47:40 sfinucan dansmith: RE: https://review.openstack.org/#/c/408242/, what would be the preferred pattern -
15:48:03 sfinucan hardening all the access to various InstanceNUMACell attributes to check if the attribute is set first
15:48:09 johnthetubaguy sfinucan: did you see the image meta object stuff?
15:48:23 sfinucan or always setting those attributes anywhere we create an object?
15:48:25 johnthetubaguy sfinucan: we should probably generate docs from that at some point
15:48:38 cfriesen sfinucan: not actually sure
15:48:39 sfinucan johnthetubaguy: To which "stuff" do you refer? :)
15:49:01 johnthetubaguy sfinucan: https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py
15:49:38 sfinucan johnthetubaguy: Oh, yeah - I knew where that was defined, alright. I meant docs that you don't need to read the code for :)
15:50:22 johnthetubaguy sfinucan: we should generate some docs off that I think, I suspect a few have got into the admin guides, but unsure on the details there

Earlier   Later