Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-06
22:24:56 superdan but if you know other, please point to it
22:25:13 smcginnis Does Nova actual use limits? "nova limits"
22:25:40 smcginnis And if so, where are these set? I've found references that limits are set in the project.conf file, but nothing stating what needs to actually be set.
22:25:57 melwitt superdan: yeah, double checking to see if I missed something last time
22:26:14 smcginnis Cinder has absolute limits too, but it appears to be left over from the Nova split. Trying to figure out if they are actually used/working.
22:38:51 mriedem smcginnis: limits == quotas
22:38:55 mriedem os-quota-sets API
22:39:04 smcginnis mriedem: nope
22:39:14 mriedem the limits API is just the read-only API for getting the quota limits
22:39:22 smcginnis mriedem: Not from what I've seen. Though maybe that's changed in Nova?
22:39:33 smcginnis mriedem: Ah, that might explain some things. :)
22:39:36 mriedem smcginnis: well,
22:39:39 mriedem ...
22:39:40 mriedem ...
22:39:47 mriedem trying to figure out how long i want to make this
22:39:47 smcginnis mriedem: Some really misleading stuff out there.
22:39:57 mriedem quotas come from 3 different places in nova,
22:40:01 mriedem 1. config
22:40:06 smcginnis mriedem: It's late on Friday. Probably better just to tell me to step off.
22:40:11 mriedem 2. quota classes
22:40:12 melwitt superdan: this is where I don't see how instance.create() is ever called in compute cells https://github.com/openstack/nova/blob/master/nova/compute/cells_api.py#L194-L198 so ... I dunno, we'll see
22:40:20 mriedem 3. i might only be thinking of 2
22:40:43 mriedem basically if you don't have default quotas overridden in the API, then the default quotas for all projects comes from config,
22:40:56 mriedem but if you change default quota in the REST API, then it's in the nova DB
22:41:03 mriedem and we never read from config for that resource type again
22:41:11 mriedem and you can tailor default quota globally or per-tenant
22:41:17 mriedem i think that was my #4
22:41:19 mriedem *#3
22:41:31 mriedem 1. check if there is quota in the db for this project and resource, if not,
22:41:37 smcginnis mriedem: OK, that makes sense. Maybe just thrown off by having two different names and some old or incorrect comments I read.
22:41:41 smcginnis mriedem: Thanks
22:41:43 mriedem 2. check if there is default quota in the db for this resource, if not,
22:41:45 mriedem 3, check config
22:41:56 superdan melwitt: okay, but.. the only thing in db_api that will create an instance row is db.instance_create(), and I don't see us calling that from anywhere other than the object, right?
22:42:15 mriedem smcginnis: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108997.html and the linked spec might help a bit
22:42:26 mriedem the spec gives more background in a distilled way on how this all works today
22:42:59 mriedem i should actually move the problem description from https://review.openstack.org/#/c/411035/2/specs/pike/approved/deprecate-os-quota-class-sets.rst into the devref
22:43:13 mriedem since it took me a day plus sanity checking from melwitt to sort it out
22:43:23 smcginnis heh, how timely.
22:43:28 melwitt superdan: that's what I wasn't sure about, I assumed db.instance_update_and_get_original can somehow create an instance row, being that I never found a place instance.create() was called
22:43:45 superdan pretty sure not.. it should fail immediately if you do
22:44:09 superdan melwitt: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2696-L2697
22:44:11 superdan should fail right there
22:45:09 melwitt oh, hmm. I'm stumped then
22:45:52 superdan ah
22:46:53 superdan well,
22:46:59 superdan there is this weird automatic hijack of the compute rpc,
22:47:06 superdan which might have had it before
22:47:18 superdan where we neuter the rpc at the api level, and auto-call to the child in some cases
22:47:20 superdan but create isn't in there
22:47:24 superdan build is though
22:47:55 superdan anyway, seems like it has to be something like that
22:48:17 superdan if not, I have no idea how it works,
22:48:26 superdan but I've said that like three times today already so,..
22:49:07 melwitt yeah ... well, at least that means the hack will probably work, so yey for that at least
22:49:10 superdan oh yeah, here
22:49:28 superdan https://github.com/openstack/nova/blob/master/nova/compute/cells_api.py#L85-L86
22:49:59 superdan which is set somewhere so that we get to hijack calls
22:50:01 melwitt O.o
22:50:13 superdan and I think there's some split of things that are new (objecty) and old (not objecty) somewhere, but I always forget that piece
22:50:19 melwitt on top of the whole cells_api thing? damn
22:50:19 superdan maybe that's in messaging
22:50:36 superdan yeah, there is a ton of indirection and magic in here
22:50:54 superdan this is why I'm always talking about all the replaying :)
22:51:16 superdan because there's .. a .. lot of it
22:51:21 superdan and several ways of doing it
22:51:57 melwitt yeah, I thought all of the replaying could be seen in the ComputeCellsAPI methods and never realized there are separate bits that can interleave in there from the RPCProxy whatever
22:52:53 superdan yeah, there are implicit paths in tere
22:52:54 superdan *there
22:53:52 melwitt "good times"
23:01:10 melwitt superdan: gdi http://logs.openstack.org/75/396775/25/check/gate-tempest-dsvm-cells-ubuntu-xenial/7105ddd/logs/screen-n-api.txt.gz?level=TRACE#_2017-01-06_22_45_29_711
23:01:25 superdan gah
23:01:57 openstackgerrit Dan Smith proposed openstack/nova: WTFWIP: Multicell support for instance listing https://review.openstack.org/396775
23:17:15 mriedem jroll: when can we get an ironicclient release for https://review.openstack.org/#/c/335964/ ?
23:17:22 mriedem jroll: like, early next week?
23:17:28 mriedem or is that already in the works?
23:18:26 jroll mriedem: see the comments there. tl;dr nova won't use portgroups for things until attach/detach is implemented. that still has a client patch out there. so no point in releasing now
23:18:34 jroll er, not there, but on the nova patch
23:19:33 mriedem hmm
23:19:35 mriedem so https://review.openstack.org/#/c/206163/
23:19:46 mriedem has a comment from vdrok: "This patch is not needed anymore, as after this one https://review.openstack.org/364413 it will be happening on ironic side."
23:20:06 mriedem oh which is https://review.openstack.org/#/c/364413/
23:20:10 mriedem for attach/detach
23:20:13 jroll right, so here's the two ways we can do this
23:20:32 jroll 1) (the way we're doing it) do attach/detach first, nova just makes an api call, ironic does the ports/portgroup/order/etc logic
23:20:51 jroll 2) implement portgroups in plug_vifs now, make that work, then rip it all out to do attach/detach
23:21:06 mriedem 2 is https://review.openstack.org/#/c/206163/ right?
23:21:22 jroll yes, that should be abandoned
23:21:47 mriedem jroll: so the other one for attach/detach depends on this ironic patch https://review.openstack.org/#/c/404240/
23:21:51 mriedem which looks like it's not ready
23:22:16 jroll it's pretty close
23:22:27 mriedem and the ironicclient change for that https://review.openstack.org/#/c/364420/ is dependent on the same ironic api change,
23:22:29 jroll we keep merging crap that conflicts, it seems, I'll make sure we stop doing that
23:22:46 mriedem so i guess the api change would realistically have to be merged by eow next week,
23:22:52 mriedem to get the client release in by 1/19
23:23:02 mriedem and then the nova change 1 week after that :)
23:23:12 jroll yeah I think we can get the client next week even
23:23:21 mriedem i assume the ironicites like their schedules like they like their jeans, tight
23:23:39 jroll no we just have too much shit to do and keep crossing wires
23:23:55 mriedem yeah i know, i just wanted to make a skinny jeans joke

Earlier   Later