| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-26 | |||
| 20:02:30 | melwitt | don't think we have to have a meeting but I was just gonna say the console stuff is still up and passing jenkins. I have a devstack change up that Depends-On the stack and runs console proxies per cell and that works too | |
| 20:02:31 | bauzas | dansmith: looking | |
| 20:03:03 | dansmith | melwitt: orly, okay, I should go look at that | |
| 20:03:11 | bauzas | melwitt: dansmith: mriedem: if you need me reviewing things before pike-3 for cells v2, just lemme know | |
| 20:03:20 | dansmith | if mriedem agrees, hopefully we just had our meeting | |
| 20:03:27 | dansmith | bauzas: console stuff | |
| 20:03:32 | bauzas | ok | |
| 20:04:19 | melwitt | CONSOLEZ. I'm about to update it to redact tokens in the debug logs but other than that, it's been ready. mostly unchanged from when PaulMurray was working on it | |
| 20:04:49 | mriedem | ok to ditch the meeting | |
| 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 | 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:26 | dansmith | no difference, I just used the term once to mean something specific and someone started saying it I think | |
| 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: Add console connection object https://review.openstack.org/320063 | |
| 20:20:02 | openstackgerrit | melanie witt proposed openstack/nova master: Use ConsoleConnection object to generate authorizations https://review.openstack.org/325414 | |
| 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:03 | openstackgerrit | melanie witt proposed openstack/nova master: Add access_url_base to console_auth_tokens table https://review.openstack.org/334614 | |
| 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 | |