| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 13:34:11 | mriedem | which part specifically are you referring to there? | |
| 13:34:40 | rabel | mriedem: so, let me summarize: the only quota class is "default" and the concept of quota classes will probably soon be removed. default quotas are quotas that take effect if there is no project-specific quotas. and having default quotas for a project/class does not make sense. is this correct in your opinion? | |
| 13:35:24 | mriedem | "and having default quotas for a project/class does not make sense" - why does that not make sense? | |
| 13:35:34 | mriedem | rabel: having default quota (limits) is fine | |
| 13:36:08 | mriedem | having an api and database for quota classes when there is only ever a single entry though, is weird | |
| 13:36:15 | mriedem | *database table | |
| 13:36:57 | mkoderer | mriedem: this part blocks: https://github.com/openstack/nova/blob/902b7bf6f5425824a0661b8e4beac4a894749c03/nova/virt/libvirt/driver.py#L7022 | |
| 13:37:28 | dansmith | sdague: mriedem: setting the precedent of loading json in mysql seems not awesome | |
| 13:37:28 | rabel | mriedem: default quotas do make sense. but how are they connected to a specific project? isn't the idea of default quotas that they are global? | |
| 13:37:42 | dansmith | sdague: mriedem: I'd almost rather just build a separate index of that thing, if it's a thing people do often | |
| 13:38:06 | dansmith | sdague: mriedem: also, it's something rather easy that a client can do right? find the port/device_id in neutron and then show the instance in nova? | |
| 13:41:57 | bauzas | dansmith: edleafe: tbc, I'm working on updating my series given dan's comments | |
| 13:42:14 | dansmith | bauzas: sweet :) | |
| 13:42:33 | bauzas | just has a problem with a 2-instances request | |
| 13:42:42 | bauzas | because I need more hosts than just 4 | |
| 13:42:42 | edleafe | bauzas: cool. I'll be pushing an update to my series, but it's just a pep8 fix, so don't freak out | |
| 13:42:56 | sdague | dansmith: expect, neutron api isn't always exposed correctly directly to users | |
| 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 | sean-k-mooney | sfinucan: cool thanks, just going true my review queue which is always fun :) | |
| 14:45:19 | bauzas | but that's still a nova thing | |
| 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: Delete existing allocations when retrying https://review.openstack.org/460433 | |
| 14:54:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 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 | |