| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 18:53:12 | mriedem | what others? | |
| 18:53:17 | mriedem | changes or people? | |
| 18:53:38 | mriedem | or https://en.wikipedia.org/wiki/The_Others_(2001_film) ? | |
| 18:53:44 | edleafe | mriedem: any other group that is waiting for placement to be fully funcitonal for their needs | |
| 18:53:46 | mriedem | gggghost kids! | |
| 18:54:01 | mriedem | edleafe: let those groups speak up if they are | |
| 18:54:06 | mriedem | because so far they are silent | |
| 18:54:18 | mriedem | probably b/c they are ghost kids | |
| 18:54:19 | edleafe | mriedem: I just have this silly voice in my head that wants me to think that Placement != Nova | |
| 18:54:29 | mriedem | sure, but realize we have 3 weeks | |
| 18:54:39 | mriedem | claims in the scheduler is the end goal right? | |
| 18:54:46 | mriedem | and allocation candidates is a dependency for that | |
| 18:54:49 | edleafe | mriedem: for pike, yes | |
| 18:54:58 | mriedem | any other utopian sugar is probably queens | |
| 18:55:17 | edleafe | I didn't mean to imply that it would be a thing for pike, just that it might be useful to others at some point | |
| 18:55:45 | mriedem | sure, but let's worry about that when it definitely is | |
| 18:56:20 | edleafe | if we never worry about it, it never will be | |
| 18:58:22 | mriedem | are we going to compete on the worriness scale? | |
| 19:01:08 | edleafe | like I said, I keep thinking that placement is a thing in itself, and not a nova subsystem | |
| 19:01:45 | mriedem | nothing i'm talking about makes it a nova subsystem | |
| 19:04:16 | jmlowe | thanks! | |
| 19:04:22 | jmlowe | you have my attention | |
| 19:04:27 | jaypipes | cdent: parity, no. will there likely be a couple more parameters to the allocation candidates call? yeah. | |
| 19:04:47 | cdent | jmlowe: that's all you get | |
| 19:05:15 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/481189 | |
| 19:05:28 | jmlowe | damn, I'll go back to ignoring this channel for another 1k-2k messages | |
| 19:05:42 | cdent | best choice for your mental health | |
| 19:06:35 | openstackgerrit | Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavors API https://review.openstack.org/449288 | |
| 19:06:46 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 19:16:09 | melwitt | dansmith: I've mostly removed the instance uuid from the access url for the console stuff, but met a confusing point regarding the transition period between consoleauth/memcached and the database backend, | |
| 19:16:32 | melwitt | the code in the console proxy was using the presence of the instance uuid to determine whether to go to the database backend for validation vs going to the consoleauth service, | |
| 19:16:45 | melwitt | without the instance uuid, we don't really know if the access url is old or new, memcached or database. I'm not sure what to do about that | |
| 19:16:57 | melwitt | I thought, could try first for the database, if that fails, try consoleauth, if that fails too then it's really invalid. but that assumes the operator is running consoleauth still. which might be okay | |
| 19:17:18 | melwitt | my concern there is after all of the outstanding consoles have moved to the database backend, it's safe to stop running consoleauth, but then the fallback behavior should also be turned off. | |
| 19:17:31 | melwitt | so I was thinking we might need a config option | |
| 19:17:49 | dansmith | I don't have this cached in my head.. if hitting the DB is the way forward, | |
| 19:17:51 | dansmith | why not just always do that and stop looking at the auth cache? | |
| 19:18:03 | dansmith | could have a workaround conf for it I guess, but if database always works... | |
| 19:18:17 | melwitt | because of existing urls that people might be using, that had been generated pre-database | |
| 19:18:21 | mriedem | jaypipes: ok comments inline https://review.openstack.org/#/c/476631/ | |
| 19:18:43 | dansmith | melwitt: aren't those expired in like an hour or something? | |
| 19:19:32 | melwitt | dansmith: maybe. I was thinking that, the easy way would be just invalidate them all and make people get new urls. but I dunno how accommodating we need to be about the transition | |
| 19:19:53 | dansmith | melwitt: if it's a short timeout, I don't think we should need to jump through crazy hoops for that | |
| 19:20:06 | melwitt | k. I'll double check what it is | |
| 19:20:20 | dansmith | I wish we could talk about this and fix it in like one week.. I keep paging this data in and out of my brain | |
| 19:29:14 | mriedem | give your mind a break, | |
| 19:29:19 | mriedem | with christopher cross https://www.youtube.com/watch?v=VMkIuKXwmlU | |
| 19:29:59 | mriedem | he's like the fat older brother of that guy from the guardians of the galaxy movies | |
| 19:30:13 | melwitt | hah, I was just thinking, he looks like somebody else | |
| 19:30:17 | mriedem | chris pratt | |
| 19:30:41 | mriedem | http://i.huffpost.com/gen/1939272/images/o-CHRIS-PRATT-facebook.jpg | |
| 19:30:44 | mriedem | same fing person | |
| 19:31:00 | melwitt | hahaha | |
| 19:32:05 | mriedem | he's got 18 strings but only needs like 6 | |
| 19:32:09 | mriedem | maybe 4 | |
| 19:32:32 | melwitt | there's a lot about this scene I didn't expect considering how the song sounds | |
| 19:32:38 | mriedem | the jersey | |
| 19:32:56 | mriedem | laid | |
| 19:32:57 | mriedem | back | |
| 19:35:44 | melwitt | this consoles code doesn't make any sense to me. says "Remove expired tokens from the cache." but I only see a "get" no delete of them | |
| 19:38:23 | mriedem | shouldn't the cache auto remove things based on the timer? | |
| 19:38:36 | mriedem | using oslo.cache i assume | |
| 19:38:50 | mriedem | it might just be an old comment from when we switched over to oslo.cache, | |
| 19:38:54 | mriedem | that was never cleaned up | |
| 19:39:01 | melwitt | the token cache is a memcached thing. and as far as I can tell, it doesn't expire anything. I'm sure I'm just not finding where it is maybe | |
| 19:39:01 | mriedem | i.e. maybe before that refactor we were manually removing things? | |
| 19:39:10 | melwitt | oh, hm | |
| 19:39:13 | mriedem | i think there is a default timeout in oslo.cache | |
| 19:39:49 | mriedem | https://docs.openstack.org/oslo.cache/latest/opts.html | |
| 19:40:29 | melwitt | I see. thanks | |
| 19:40:50 | mriedem | i'm only guessing, i do remember going over the patch in nova that converted to use oslo.cache though and had questions like this | |
| 19:42:02 | melwitt | yeah, I think you're right though. the consoleauth stuff just uses nova/cache_utils and in cache_utils I see there's oslo_cache.dict and dogpile.cache.memcached as options. I'm not sure what/how we default to | |
| 19:45:27 | melwitt | default TTL is 600, so 10 minutes. a lot shorter than I thought | |
| 19:47:34 | mriedem | ildikov: i see the live migration change isn't in this series https://review.openstack.org/#/c/330285/ | |
| 19:47:54 | mriedem | ildikov: so, i guess to test the new api flow plus live migration, we can just do a DNM nova change that depends on both | |
| 19:47:56 | mriedem | yeah? | |
| 19:50:10 | ildikov | mriedem: I can add it to the chain or just do what you say | |
| 19:50:30 | mriedem | ildikov: let's test it out first, i'll push a patch | |
| 19:51:08 | ildikov | mriedem: sounds good, thanks | |
| 19:51:29 | melwitt | okay, so if they configured oslo.cache themselves we use that, if they didn't, we make it a oslo_cache.dict | |
| 19:52:06 | mriedem | from what i remember, if it's not configured for some other backend, we use an in-memory dogpile cache dict cache yeah | |
| 19:52:21 | melwitt | your memory is excellent | |
| 19:53:11 | openstackgerrit | Moshe Levi proposed openstack/nova master: hardware offload support for openvswitch https://review.openstack.org/398265 | |
| 19:53:31 | mriedem | all that clean livin' | |
| 19:55:42 | melwitt | dansmith: so the default TTL is 10 minutes but they could configure it for a lot longer | |
| 19:55:56 | dansmith | melwitt: yeah | |
| 19:56:59 | dansmith | melwitt: I dunno, I think it's fine to say "db is the way forward, memcache is deprecated, if you need, make sure you've configured for db and given enough time for things to expire before rolling | |
| 19:57:17 | melwitt | I dunno how big of a deal it would be. if we don't try to fall back on consoleauth, then at worst they get a InvalidToken and have to re-get a new access url and do again | |
| 19:57:34 | dansmith | right | |
| 19:58:01 | dansmith | there's some config thing now to choose whether we use memcache for that or not, right? | |
| 19:58:44 | melwitt | dansmith: not yet. there was described in the spec, but I think it wasn't added bc instance uuid presence could be used to detect old vs new (that's my speculation, I don't see it documented why they didn't go ahead with the config option) | |
| 19:58:53 | dansmith | oh I see | |
| 19:59:06 | dansmith | but | |
| 19:59:16 | dansmith | and so the code to always do it in the DB is unmerged? | |
| 19:59:45 | melwitt | I think the original design didn't have instance uuid (that was only added bc cells v2 + one proxy at top) and so they had the idea of the config option | |
| 19:59:56 | melwitt | yeah, nothing is happening in the DB yet | |
| 20:00:01 | dansmith | ah, okay I see | |
| 20:00:15 | dansmith | so | |
| 20:00:24 | dansmith | how about: | |
| 20:00:28 | dansmith | 1. Default to only db | |