Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-26
20:05:09 mriedem what do we lose if we don't have the console proxy stuff done?
20:05:27 mriedem because < 24 hours is tough for something that hasn't had review yet
20:07:12 melwitt mriedem: I think just inability to shard console proxies. current state is the token auth cache and proxies are global. the console stuff moves token auth storage to the cell databases and then shards proxies, one per cell
20:07:45 melwitt and starts on the deprecation timer on eliminating the consoleauth service
20:09:12 bauzas dansmith: looks good for me with the plan
20:09:14 dansmith sounds like a good candidate to punt then
20:09:19 dansmith bauzas: ack
20:09:51 bauzas dansmith: I was just thinking of restoring the original allocation but honestly having both allocations for the source and destination hosts make more sense in terms of "resource usage"
20:10:10 bauzas because when you wanna move, you need to make sure you have double room
20:10:15 bauzas until the move is done
20:10:19 melwitt dansmith: yeah. I think the main concern I had was if a change in deployment topology being out-of-sync with the rest of the multicell changes, but I think based on our current state, superconductor isn't going to be a thing yet, right?
20:11:29 dansmith melwitt: it is, merged in devstack now.. not sure I get the relation
20:11:42 dansmith melwitt: or you mean a change in deployment from pike->queens?
20:11:45 melwitt or rather, I don't know what the current state of multicell is in regard to what we will document for users. I think I asked the question on the etherpad, what does multi-tier mean vs multi-cell?
20:12:26 dansmith no difference, I just used the term once to mean something specific and someone started saying it I think
20:12:26 melwitt like, when we will have the communication of "you'll need to change your deployment of services like this" I was thinking it might be less confusing if the console proxy run location changes coincided with that
20:12:59 dansmith the only people affected by such a change would be people that would split out a cell in pike, and then upgrade to queens I think
20:13:17 melwitt instead of letting someone get started with multicell and global console proxies and then in another release saying, "oh yeah, go back and change what you already deployed"
20:13:19 dansmith and anyone that does that won't have reschedules and affinity checks in pike anyway
20:13:34 dansmith yeah, so that'd be the only concern I think
20:13:37 melwitt right
20:13:40 dansmith I think that the migration wouldn't be bad though,
20:14:03 dansmith because you can just start up console in the cell prior to the upgrade and it won't do anything until after things roll
20:14:13 dansmith up to mriedem to decide which he thinks is less problematic/risky
20:14:25 dansmith merging early, or documenting that change to the people that actually split a cell in pike
20:14:31 melwitt yeah, I guess not. it would be like, stand up console proxies per cell and have to leave the global ones running too until no outstanding tokens are using them anymore
20:14:45 dansmith well, as I've said,
20:14:52 dansmith I don't think that resetting tokens is a big deal
20:15:04 dansmith you just don't want to have a time where you can't get new tokens
20:15:20 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_service_url() https://review.openstack.org/458257
20:15:22 melwitt yeah, true
20:15:43 efried mriedem jaypipes johnthetubaguy (mordred) ^
20:16:29 mordred efried: woot!
20:16:47 efried May need a little help making sure I find all the right places that need to be touched for the followup (other places in nova that talk to endpoints)
20:17:27 bauzas mriedem: jangutter: I have a concern with https://review.openstack.org/#/c/483459/17
20:17:31 efried mordred The difference in ksa usage is dissapointingly tiny in proportion to the amount of ksa work done :)
20:17:42 efried mordred But os-service-types is gold
20:17:46 bauzas mriedem: jangutter: AFAICT, it's depending on an os-vif change, right?
20:17:56 mordred efried: you're setting ks_adapter.interface to a list in utils - isn't there some way to set a conf default or something?
20:17:57 mriedem bauzas: which is already merged and released
20:17:58 mordred efried: woot!
20:18:07 jangutter bauzas: correct
20:18:09 bauzas mriedem: oh nevermind, just saw it
20:18:15 efried mordred The conf options come directly from ksa.
20:18:21 bauzas mriedem: I thought we didn't released it
20:18:32 mordred yah- I thought there was maybe some way to set/override the deafult value for one of them or something
20:19:01 efried mordred Mm, not sure about that. Doug would probably know.
20:19:14 jangutter bauzas: yeah, it snuck in right as the door closed.
20:19:21 efried mordred Not completely sure we would want to do that, exactly.
20:19:35 mordred efried: nod
20:19:38 bauzas jangutter: happy for you
20:19:45 efried I guess I can see the advantage for automatic conf generation or something.
20:20:01 openstackgerrit melanie witt proposed openstack/nova master: Add periodic task to clean expired console tokens https://review.openstack.org/325381
20:20:02 openstackgerrit melanie witt proposed openstack/nova master: Use ConsoleConnection object to generate authorizations https://review.openstack.org/325414
20:20:02 openstackgerrit melanie witt proposed openstack/nova master: Add console connection object https://review.openstack.org/320063
20:20:03 openstackgerrit melanie witt proposed openstack/nova master: Add access_url_base to console_auth_tokens table https://review.openstack.org/334614
20:20:03 openstackgerrit melanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation https://review.openstack.org/333990
20:20:04 openstackgerrit melanie witt proposed openstack/nova master: Add console_auth_token_get() method to DB API https://review.openstack.org/481700
20:20:54 jangutter bauzas: thanks, I owe the gang some serious drinks.
20:21:43 mriedem melwitt: so i think to summarize the statement for multi-cell in pike, is cern will be ok with it since they don't do build retries anyway, but if you rely on retries then you shouldn't do multi-cell in pike, since we don't have the alternatives stuff done
20:22:09 mriedem or if you rely on server group affinity/anti-affinity since the computes and cell conductors can't hit the scheduler or api db
20:22:15 mriedem dansmith: ^ keep me honest on that 2nd one
20:23:29 melwitt yeah, that makes sense. I just wasn't sure what the difference between multi-tier and multi-cell was but if they're synonyms then I think I understand the state
20:23:47 openstackgerrit Merged openstack/python-novaclient master: Change Service repr to use self.id always https://review.openstack.org/487502
20:23:51 bauzas mriedem: dansmith: melwitt: correct me if I'm wrong but you can multi-cell and retry if you are able to upcall ?
20:24:12 bauzas the only problem is when you usually isolate your MQs
20:25:25 mriedem melwitt: multi-tier to me is superconductor, and it's not really worth doing multi-cell if you can't do multi-tier with superconductor, because then your cells are all going to be blasting to every other cell conductor - which breaks a bunch of stuff
20:25:32 mriedem dan mentioned this on a hangout yesterday with me and jay
20:26:09 mriedem well there is no cell conductor,
20:26:13 mriedem there is just conductor
20:26:24 melwitt okay. does that mean we're going to document a multi-cell deployment with no superconductor? I was thinking not
20:26:44 melwitt i.e. multi-cell also means multi-tier to us
20:27:13 mriedem i'm not sure what the advantage of multi-cell w/o superconductor would be if you're sharing MQ everywhere
20:28:17 melwitt what I'm trying to say is, we're in the position of presenting the deployment options in our docs, so are we going to leave out the "multi-cell w/o superconductor" from that? I was thinking so, else it becomes needlessly confusing
20:28:24 mriedem i think we definitely need to document what we're recommending for the deployment, and what the limitations are in pike
20:28:50 mriedem so if you can't live with the limitations in pike, then don't do multi-cell
20:28:58 melwitt because AFAICT, multi-cell without superconductor isn't really supposed to be a thing
20:30:42 cdent edleafe:
20:30:43 mriedem probably need to hash it out with dan when he's got some time
20:30:50 mriedem since this always makes me go in circles
20:31:12 cdent nm
20:31:24 melwitt yeah. it just doesn't sound like something we should document and thus recommend
20:31:48 melwitt document the recommended deployment alongside its limitations
20:32:09 melwitt one for single cell and one for multicell
20:34:19 sdague jlvillal / vdrok ironic is still failing after the devstack change, on the hypervisor count never exceeding 0
20:34:35 sdague is that the same issue you were dealing with, or a different one
20:34:47 sdague http://logs.openstack.org/58/487458/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial/01e5dfe/
20:36:33 jlvillal sdague: I'll be honest and admit I don't know what exactly is going on. vdrok has been driving this issue.
20:37:08 jlvillal sdague: And it is 23:36 at night where he is...
20:37:15 bauzas jangutter: question, are we 100% sure the VIF object we're getting is always having a profile information if it's an Agilio VNIC type ? https://review.openstack.org/#/c/483459/17/nova/network/os_vif_util.py@319
20:37:43 bauzas jangutter: I think it's a reasonable assumption but I want to be sure we're not getting a stupid KeyError exception
20:38:42 jangutter bauzas: It should, or the claim would fail earlier. The only two VNIC types we use are in the SR-IOV list.
20:40:27 sdague jlvillal: ok, the test results hadn't returned yet, so I just figured I'd give an early heads up
20:40:53 jlvillal sdague: Thanks, doesn't look like the test job likes those changes. Based on all the failures
20:40:56 sdague we're about 17 minutes away from the devstack patch passing
20:41:07 jlvillal Ugh
20:41:09 sdague jlvillal: yeh, I don't know what the previous issue was actually
20:42:46 jlvillal sdague: I'm telling people about it over in #openstack-ironic. Reaction not so good ;)
20:44:11 dansmith sdague: jlvillal that's the one yeah
20:44:29 dansmith jlvillal: for the record, I did ask a week ago and things were good in ironic land dependent on the change :)

Earlier   Later