Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-06
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 superdan maybe that's in messaging
22:50:19 melwitt on top of the whole cells_api thing? damn
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
23:24:05 mriedem ok i'll abandon #2
23:24:25 jroll cool, thanks
23:24:50 jroll looks like this is rebased on it, which isn't good https://review.openstack.org/#/c/388756/
23:24:57 jroll but I'll make sure that gets cleaned up
23:25:41 mriedem ok. do i get to supersede the portgroups bp by the attach/detach bp, or is there still something unique about the portgroups bp that we keep it around, like this network metadata patch?
23:25:59 jroll portgroups depends on attach/detach
23:26:01 mriedem in other words, does https://review.openstack.org/#/c/388756/ get rebased on https://review.openstack.org/#/c/364413/ ?
23:26:20 jroll yep
23:26:30 mriedem ok i'll just leave the LP bits alone for now then
23:26:33 mriedem thanks for clarifying
23:26:40 mriedem i'm going down my list and checking it twice, obviously
23:26:41 jroll that passes in the metadata to tell the instance it's a bond
23:26:43 jroll no problem
23:27:01 jroll btw, are you attending our meeting monday or just wanted to put that thing in the agenda as a note?
23:28:52 mriedem jroll: just put it as a note
23:29:00 jroll cool, I'll announce it
23:34:23 mriedem jroll: what is higher priority, vif attach/detach or rescue/unrescue, because the latter is in merge conflict down the stack - i'm assuming the former is higher priority though
23:35:51 mriedem should maybe also push on this next week since the ironic API change is already done https://review.openstack.org/#/c/407977/
23:41:25 jroll mriedem: the former, I don't expect rescue to land in nova this cycle
23:41:37 jroll +1
23:41:59 mriedem ok. if i remember after going through the list i'll update the ironic meeting agenda with things i think are close but need the push
23:44:08 jroll awesome, thank you
23:44:47 mriedem claudiub|2: are you planning a release request for os-win to get https://review.openstack.org/#/c/398215/ released? that's needed for https://review.openstack.org/#/c/398509/ which you need to update.
23:45:41 claudiub|2 mriedem: indeed i am. monday
23:45:49 mriedem claudiub|2: great, thanks

Earlier   Later