| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 13:43:17 | sdague | dansmith: yeh, secondary index would be fine as well | |
| 13:43:36 | bauzas | edleafe: which one do you think you want to update ? the ones about passing the UUIDs and the scheduler claims? | |
| 13:44:26 | edleafe | bauzas: yep | |
| 13:44:30 | bauzas | ok | |
| 13:45:19 | dansmith | sdague: could we also just special case that search by asking neutron ourselves and then pulling the relevant instances out ? | |
| 13:45:33 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/465283 | |
| 13:45:35 | sdague | dansmith: they support search by regex? | |
| 13:46:02 | sdague | I think it gets complicated when there are multiple filters | |
| 13:46:15 | sdague | but especially what we allow in our filters today | |
| 13:46:24 | dansmith | sdague: I dunno, they'd have to for the client approach to work, but I didn't realize that searching by regex was a thing, I thought the use-case was "find me the instance with this ip" | |
| 13:47:06 | sdague | it's definitely a regex today, which is kind of suck | |
| 13:47:09 | sdague | but that's what it is | |
| 13:47:14 | sdague | and has been | |
| 13:48:43 | mriedem | mkoderer: that's in a ploop block, are you using ploop? | |
| 13:49:14 | mriedem | mkoderer: is there a way to detect a bad mountpoint with nfs? | |
| 13:53:10 | dgonzalez | mriedem: mkoderer sent the wrong line, the correct line is https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7025 (below the loop block) | |
| 13:53:31 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Transform keypair.delete notification https://review.openstack.org/463946 | |
| 13:53:50 | dgonzalez | mriedem: But both lines basically have the same content, so I guess the issue could occur in both blocks | |
| 13:54:53 | mriedem | i'm going to be away for a couple of hours | |
| 13:58:49 | alex_xu | johnthetubaguy: sdague it would be great to merge this one first when you have free time, it can reduce some conflict in later patch. thanks in advance | |
| 13:59:06 | sdague | alex_xu: which patch? | |
| 13:59:20 | alex_xu | sdague: oops, https://review.openstack.org/462825 | |
| 14:00:23 | sdague | alex_xu: done | |
| 14:01:00 | alex_xu | sdague: thanks! | |
| 14:02:12 | johnthetubaguy | will take a look at that series next, looking a the policy docs first | |
| 14:02:38 | johnthetubaguy | I also need to work out why that highlight didn't make any noise in this (franctionally less stupid) IRC client | |
| 14:10:37 | rabel | mriedem: I was shortly disconnected. have you by chance answered my last question? | |
| 14:19:48 | dims | sdague : Do we need to suppress this ERROR traceback? http://logs.openstack.org/58/465458/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d240f9b/logs/screen-n-sch.txt.gz#_May_17_08_54_38_996958 | |
| 14:22:15 | sdague | dims: yeh, probably | |
| 14:22:34 | sdague | we should support at least a 60 second grace before we emit that | |
| 14:22:41 | sdague | it's a service race startup | |
| 14:37:44 | edleafe | This isn't the best forum for discussion, but I wanted some clarification about the request from ops for additional host for retries. Was this simply for Nova? I remember talking about getting rid of the dependence on max_attempts in the scheduler, because it was a nova-ism. | |
| 14:37:49 | edleafe | Basing the number of returned hosts on max_attempts seems like we're once again linking nova to the scheduler. IOW, if max_attempts is 5, then *every* service that might ever use the scheduler will get back 5 resource providers per request, whether they need them or not. Wouldn't it be a better design to have the service calling select_destinations ask for more if they want more than 1? | |
| 14:38:00 | edleafe | ^^ bauzas dansmith cdent jaypipes | |
| 14:38:53 | bauzas | edleafe: because the conductor would be cell-local | |
| 14:39:05 | bauzas | edleafe: so it would be an upcall which we disagree with | |
| 14:39:13 | edleafe | bauzas: you're missing the point | |
| 14:39:26 | edleafe | I'm not saying returning more than one host is a bad thing | |
| 14:39:47 | edleafe | I'm asking if we want to tie the number of returned RPs to nova's needs | |
| 14:39:55 | bauzas | no | |
| 14:40:05 | bauzas | the RP call returns the full list | |
| 14:40:12 | cdent | edleafe: when you say "returned RPs" do you mean placement -> scheduler or scheduler -> something else | |
| 14:40:15 | bauzas | then the filters/weighters filters out that list | |
| 14:40:26 | edleafe | cdent: returned from scheduler | |
| 14:40:57 | cdent | ✔ | |
| 14:41:07 | edleafe | cdent: I still try to think of scheduler as independent from nova | |
| 14:41:19 | edleafe | (as a design goal) | |
| 14:41:59 | cdent | seems a reasonable practice, although I've always assumed that while placement would always be independent, it would have as clients lots of different "things that do filtering" (including nova-scheduler) | |
| 14:42:33 | edleafe | cdent: oh definitely for placement, since we got to create it separately | |
| 14:42:53 | bauzas | edleafe: no, we clearly said during Forum that while placement could be eventually independent, scheduler is a nova-ism | |
| 14:42:55 | edleafe | I'm wondering if we're giving up on the notion of the scheduler ever being useful for anything besides nova | |
| 14:43:19 | bauzas | edleafe: at least jay told that in his presentations | |
| 14:43:50 | cdent | I think maintaining a strong contractual boundary is always good | |
| 14:43:55 | edleafe | so it was decided that every service that needs scheduling will create its own? | |
| 14:44:16 | sean-k-mooney | sfinucan: can you look at https://review.openstack.org/#/c/451049/9 the os-vif requirements file on master has conflicting with the global requirement for a while so we should probably merge this | |
| 14:44:18 | edleafe | or just that nova doesn't want to waste cycles on making that happen | |
| 14:44:23 | cdent | so I would think that the answer to your original question is "yes, we should be explicit" | |
| 14:44:30 | sfinucan | sean-k-mooney: on it | |
| 14:44:47 | bauzas | edleafe: every service could be using Placement differently | |
| 14:45:02 | edleafe | bauzas: nobody's talking about placement | |
| 14:45:03 | bauzas | edleafe: and scheduler could be a library by Queens | |
| 14:45:19 | bauzas | but that's still a nova thing | |
| 14:45:19 | sean-k-mooney | sfinucan: cool thanks, just going true my review queue which is always fun :) | |
| 14:45:43 | edleafe | I'm talking about making a change that ties the scheduler closer to nova | |
| 14:46:14 | edleafe | that we will decide to undo in N cycles because the winds have changed direction | |
| 14:50:12 | dansmith | edleafe: I think we've been on a path to keep scheduler closely tied to nova and split out placement as the generic thing, ever since placement was a thing | |
| 14:50:25 | dansmith | that's been my understanding | |
| 14:53:23 | edleafe | dansmith: so it's OK to add more things to tie them together? | |
| 14:53:56 | dansmith | to tie nova and the scheduler together? | |
| 14:54:03 | dansmith | or nova and "nova's scheduler" I should say | |
| 14:54:19 | edleafe | I think you've answered my question | |
| 14:54:23 | dansmith | heh | |
| 14:54:28 | edleafe | bleh | |
| 14:54:36 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Scheduler returning alternatives per destination https://review.openstack.org/465175 | |
| 14:54:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 14:54:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Delete existing allocations when retrying https://review.openstack.org/460433 | |
| 14:54:39 | dansmith | making the claim in the scheduler is tying them closer together right? | |
| 14:54:46 | edleafe | no | |
| 14:55:01 | dansmith | hmm, okay :) | |
| 14:55:19 | bauzas | dansmith: edleafe: just in case you're interested in, I just updated my series | |
| 14:55:39 | dansmith | bauzas: cool | |
| 14:55:40 | bauzas | working now back on the conductor change now that we have the alternatives | |
| 14:55:44 | edleafe | assuming an independent scheduler, if a service requests some resources, the scheduler would make a selection, claim the resources to ensure that nothing else uses them, and then returns the selected RP | |
| 14:56:05 | edleafe | Nothing nova-y about it | |
| 14:56:29 | bauzas | edleafe: again, like I said, we plan to make scheduler a library for Queens | |
| 14:56:44 | bauzas | so it would eventually be possible for other services to use that lib | |
| 14:56:54 | edleafe | bauzas: that seems kind of silly if only Nova can use it | |
| 14:56:54 | bauzas | but for the moment, consider it as a nova-ism | |
| 14:57:06 | bauzas | baby steps at least | |
| 14:57:13 | bauzas | ie. the plan is | |
| 14:57:19 | bauzas | 1/ claims in Pike | |
| 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 | |