Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-02
13:47:47 cdent mriedem: k
13:52:28 ildikov I got a question on instance HA last week, like having the VM restarted in another host if needed
13:52:40 ildikov I remember discussions and some activity popping about this topic a while ago
13:52:51 ildikov does anyone know whether it got anywhere?
13:53:08 cdent If alex is on holiday does this stack need a buddy this week? https://review.openstack.org/#/c/489206/ If so, I can’t prod it.
13:53:37 cdent ildikov: there’s been some chatter on one of the lists recently about “self-healing"
13:53:51 cdent and I think there might be a proposed forum session
13:54:27 cdent other than that, I don’t know anything
13:54:28 ildikov cdent: cool, thanks, I will check
13:55:05 ildikov cdent: I wanted to double check first that it's not a solved problem that I missed :)
13:55:06 johnthetubaguy ildikov: there is project about that, it just submitted to the TC
13:55:14 ildikov cdent: and have some pointers in either case
13:55:20 cdent solved. no. not yet.
13:55:39 ildikov johnthetubaguy: which one?
13:56:55 johnthetubaguy ildikov: finally found it, Masakari https://review.openstack.org/#/c/500118/
13:57:59 johnthetubaguy I know progress was going a bit slower than they hoped, but it sounds like good things were coming soon there
13:58:12 jaypipes mriedem: might have minimal perf impact, but it fixes a specific *bug* that is definitely backportable.
13:58:14 lajoskatona ildikov & cdent: Hi, actually there was a session in Denver (https://etherpad.openstack.org/p/self-healing-queens-ptg), and a promise that there will be a bi-weekly meeting
13:59:01 lajoskatona ildikov & cdent: I am still hunting for some details, as the saying was that there will be some to have shapes for the thing before the summit....
13:59:14 johnthetubaguy ildikov: aspiers knows the details, I think he was running the meeting
14:00:34 johnthetubaguy ildikov: not 100% sure, but I think http://eavesdrop.openstack.org/#High_Availability_Meeting is the meeting
14:00:50 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: placement: avoid returning duplicated alloc_reqs when no sharing rp https://review.openstack.org/508885
14:00:53 mriedem jaypipes: ok done
14:00:54 mriedem thanks
14:01:33 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter https://review.openstack.org/508886
14:01:38 ildikov johnthetubaguy: lajoskatona: cool, thanks!
14:02:27 ildikov johnthetubaguy: I saw a github repo that looked less active so I got confused, but the project proposal looks to be in good shape, so that's promising
14:02:34 johnthetubaguy ildikov: its more of a workload specific thing, hence not in Nova scope
14:03:06 ildikov johnthetubaguy: yeah, that part is clear
14:03:17 johnthetubaguy ildikov: they are kinda discussing a re-design to smush a few currently competing efforts together, as I understand it
14:03:28 ildikov johnthetubaguy: I didn't expect it to be in Nova's scope, but I was sure I will find people on this channel who have some info :)
14:03:49 johnthetubaguy ildikov: totally
14:03:59 ildikov johnthetubaguy: a-ha, ok, that describes what I saw
14:04:17 ildikov johnthetubaguy: thanks for the info and the pointers!
14:04:25 johnthetubaguy no worries
14:21:40 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactDiskFilter https://review.openstack.org/508893
14:34:22 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactRamFilter https://review.openstack.org/508897
14:37:53 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactDiskFilter https://review.openstack.org/508893
14:47:12 mriedem deprecation window is 3 months minimum across release boudaries right? ^
14:48:25 sdague mriedem: yes
14:52:31 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactDiskFilter https://review.openstack.org/508893
14:54:38 mriedem -2ed then
15:02:21 openstackgerrit Matt Riedemann proposed openstack/nova stable/newton: Add live.migration.force.complete to the legacy notification whitelist https://review.openstack.org/508902
15:11:20 openstackgerrit Matt Riedemann proposed openstack/python-novaclient stable/newton: Fix aggregate_update name and availability_zone clash https://review.openstack.org/507816
15:16:31 mriedem gmann: oomichi: you could probably help direct this a bit https://review.openstack.org/#/c/389482/
15:16:37 mriedem looks like it's NEC
15:24:17 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886
15:26:18 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886
15:31:06 openstackgerrit zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886
15:34:20 sean-k-mooney johnthetubaguy: just as an fyi im going to update https://review.openstack.org/#/c/375580 and reporpose for queens if you have no objection
15:34:47 johnthetubaguy sean-k-mooney: sounds good
15:54:46 openstackgerrit Chris Dent proposed openstack/nova-specs master: Add trait support in the allocation candidates API https://review.openstack.org/497713
16:00:23 mriedem dansmith: sdague: remember the discussion at the ptg about making the ip filtering more efficient when listing instances?
16:00:46 mriedem i thought about something that would be problematic with one of the proposed solutions, which was querying neutron ports first,
16:00:56 mriedem i don't think neutron has a concept like "read_deleted=yes"
16:01:37 mriedem so if you did: nova list --ip 192.168.159.128 --deleted --all-tenants
16:01:56 mriedem i don't think we'd be honoring the --deleted flag if we first filtered by IP using neutron
16:02:05 dansmith mriedem: you mean parallelizing the neutron and nova work, yeah
16:02:19 dansmith mriedem: we'd just get a larger set back than we need and would filter it ourselves
16:02:30 mriedem my understanding of what was proposed was first call neutron to get the list of ports (device_ids) per the ip filter provided
16:02:54 mriedem and then use ^ to filter the results from the cells
16:03:44 dansmith right, but we could still not return things that are deleted
16:03:48 dansmith oh
16:03:49 mriedem you could still honor --deleted if you only did the python filtering on any deleted instances in the results from the cells...but you're still probably wasting time checking which of the 1000 instances are deleted
16:03:51 dansmith I see what you mean
16:03:58 dansmith you don't get back the deleted ips
16:04:02 mriedem right
16:04:03 dansmith I read your logic backwards
16:04:04 dansmith yeah
16:04:08 dansmith but
16:04:20 mriedem but they could be deleted from nova anyway....or archived
16:04:22 dansmith deleted things can be purged at any time, so not being able to satisfy that query doesn't seem terrible to me
16:04:24 dansmith right
16:04:36 mriedem i know we used that as justification for some things in my searchlight spec
16:04:39 mriedem so it could apply here
16:04:47 dansmith and for flavor things I think
16:04:49 sdague so... honestly, I think we need to decouple "as an admin I need to ..."
16:04:54 sdague and it needs to be in the API
16:05:28 sdague because a lot of these things are a pretty straight forward combination of API calls, that if exposed as a single command in openstack client might be sufficient
16:05:54 dansmith well, we said that too yeah
16:06:07 dansmith I think we said we need to ask the people that need to do this if that would be okay
16:07:20 sdague yeh
16:07:28 sean-k-mooney sdague: shade may also be an option for those that want a programatic interface
16:09:44 sdague sean-k-mooney: sure, though if we're really talking about quick search functions, I think openstack client is probably the thing people will be using
16:10:21 mriedem i see notes in the etherpad about the idea for doing it in osc, but nothing saying we were going to ask about that
16:11:26 mriedem if you force it client side, then it has to be duplicated everywhere
16:11:57 sdague mriedem: but that's kind of ok
16:12:23 sdague because this is typically a debug operation
16:12:35 sdague something goes wrong with an ip, and track it back to source
16:13:38 finucannot mriedem: Just to confirm, this doesn't need a microversion because it's a bug?
16:13:39 finucannot https://review.openstack.org/#/c/490722/11
16:14:07 sdague I'm also super unclear whether the regex part of this is really interesting or should be supported
16:14:17 dansmith yeah, that was another question I think
16:14:32 mriedem stephenfin: not just b/c it's a bug, some bugs require microversions
16:14:42 mriedem stephenfin: we discussed it at the ptg, the notes are in https://etherpad.openstack.org/p/nova-ptg-queens
16:14:50 mriedem L657
16:15:21 stephenfin mriedem: So it's a bug and there was never any chance of these requests succeeding?
16:16:20 mriedem stephenfin: yes, the api would pass but the thing would eventually fail, so it never worked, so there was no point in doing a microversion, since 2.1 wouldn't work anyway
16:19:12 stephenfin mriedem: Cool cool. +Wd
16:33:14 openstackgerrit Chris Dent proposed openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540

Earlier   Later