Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-26
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 :)
20:45:14 jlvillal dansmith: I thought we tested it before and it worked.
20:45:32 sdague dansmith: http://logs.openstack.org/58/487458/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa-ubuntu-xenial/01e5dfe/logs/devstacklog.txt.gz#_2017-07-26_19_51_43_735
20:45:43 dansmith jlvillal: that's what was reported yeah, but it turns out that was only the grenade one not the multinode regular job
20:45:57 sdague any idea why nova might not register resources in the new patch?
20:46:19 catintheroof Hi, does anyone has a good guide on how to configure live migration on ocata ? doing the same that worked as of mitaka, doesnt anymore
20:46:21 dansmith yes, there's a dependent one that you need
20:46:22 dansmith hang on
20:46:25 jlvillal sdague: So what patch is about to land? And is that what will cause ironic to break?
20:46:31 jangutter bauzas: I got this from the scheduler: Insufficient compute resources: Requested instance NUMA topology together with requested PCI devices cannot fit the given host NUMA topology; Claim pci failed. _phew_
20:46:54 dansmith https://review.openstack.org/#/c/487458/
20:47:08 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Set Adapter interface defaults in conf https://review.openstack.org/487581

Earlier   Later