Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-18
14:57:08 mriedem s/your/mel's/
14:57:12 dansmith which I think means we had a bug already, but didn't notice it because we wouldn't re-sort the host list for that test where we only had one
14:57:13 mriedem but yeah, i just left some comments
14:57:16 mriedem and was looking at the failing test
14:57:18 dansmith oh, heh, I expected it was you
14:57:35 bauzas gibi: stephenfin is already traveling AFAIK
14:57:38 mriedem so that test doesn't do multi-create, and it doesn't mess with max attempts,
14:57:45 mriedem only triggers a reschedule
14:57:46 bauzas and me is about to disappear now
14:57:50 gibi bauzas: thanks for the info
14:58:03 mriedem dansmith: is this 100% fail or intermittent
14:58:18 bauzas folks visiting YVR, see you next week
14:58:41 dansmith mriedem: 100%
14:58:47 mriedem dansmith: ok, reading back on https://review.openstack.org/#/c/513931/
14:58:53 bauzas gibi: that's why I bail out earlier
14:58:58 gibi bauzas: safe travell
14:59:07 gibi bauzas: see you in YVR
14:59:08 bauzas easy one, just one hop
14:59:16 gibi bauzas: lucky you :)
14:59:29 dansmith mriedem: I'm about to reply to a few of your things which might be relevant
15:00:46 dansmith well, one of your things
15:03:45 dansmith mriedem: I wonder if this is just an artifact of the server group filter thinking our second filter step is a schedule of the next instance in line, and needs to be clamped to the same host
15:03:55 dansmith because before, the only way we'd filter again would be for the next instance
15:04:57 dansmith I'm thinking maybe we really should be doing that second pass as just a sort and not a filter/sort
15:08:51 mriedem ok so with that test, we have a single instance in an affinity group,
15:09:10 mriedem we go through filters once and pick host1 and 'claim' it in _consume_selected_host
15:09:27 mriedem which does if spec_obj.instance_group is not None:
15:09:27 mriedem spec_obj.instance_group.hosts.append(selected_host.host)
15:09:47 dansmith yeah
15:09:48 mriedem then we re-filter and go through the affinity filter again,
15:10:43 dansmith ...and throw out everything but the primary host
15:10:48 mriedem and
15:10:48 mriedem return host_state.host in group_hosts
15:10:54 mriedem it will accept host1
15:10:54 dansmith yup
15:10:56 mriedem and reject host2
15:12:05 mriedem i'm not sure why you changed the logic to ignore the multicreate case though,
15:12:08 dansmith I was trying to think if this is already broken in some other case, where we would re-sort currently, but I don't think there are any legit cases
15:12:13 dansmith mriedem: see my reply?
15:12:14 mriedem if we're just scheduling a single instance, we don't need to re-filter/sort the hosts
15:12:17 mriedem yeah
15:12:30 dansmith mriedem: if you do num_instances=2,max_attempts=1 we would re-sort there for no reason
15:12:54 mriedem sure, i expected the logic to be if index > 0 and num_alts:
15:13:06 dansmith right, but that's the case I just said
15:13:07 mriedem num_alts will be 0 if max_attempts=1
15:13:19 dansmith oh
15:13:24 mriedem if num_alts > 0:
15:13:24 mriedem you changed the code to
15:13:27 dansmith I know
15:13:27 mriedem which i think is wrong
15:13:28 openstackgerrit Kashyap Chamarthy proposed openstack/nova stable/queens: libvirt: Lift the restriction of choices for `cpu_model_extra_flags` https://review.openstack.org/569442
15:13:36 dansmith mriedem: how is it wrong?
15:13:53 mriedem because it essentially reverts https://review.openstack.org/#/c/513931/
15:14:04 mriedem and we'll re-filter/sort the hosts that we already filtered/sorted for the single instance
15:14:07 mriedem which we don't need to do
15:14:22 mriedem we just need to pick alternates in _get_alternate_hosts from the pool of already filtered/sorted hosts
15:14:34 dansmith okay, I guess I was focused on the max_attempts=1 case,
15:14:57 dansmith and wasn't thinking about num_instances=1,max_attempts=2
15:15:23 dansmith so this is what I originally had (which is why that comment is the way it is), but had ruled out needing to look at index at all
15:16:49 mriedem we probably crossed wires at https://review.openstack.org/#/c/569127/3/nova/scheduler/filter_scheduler.py@338
15:17:18 dansmith no, I knew you meant and there,
15:17:23 dansmith and that's what I started with,
15:17:42 dansmith but then was trying to reason about why I still needed index and was just missing the full inverse of the thing I was focusing on
15:20:14 mriedem ok
15:21:06 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300
15:24:55 openstackgerrit Eric Fried proposed openstack/nova master: Normalize inventory from update_provider_tree https://review.openstack.org/569132
15:24:56 openstackgerrit Eric Fried proposed openstack/nova master: libvirt: get_inventory => update_provider_tree https://review.openstack.org/560444
15:24:57 openstackgerrit Eric Fried proposed openstack/nova master: libvirt: Don't report DISK_GB if sharing https://review.openstack.org/560459
15:28:21 mriedem esberglu: just one question in https://review.openstack.org/#/c/549300/
15:30:25 esberglu mriedem: That lock is only needed when we have image caching implemented which we are saving for a follow on change
15:33:22 fried_rice mriedem: It was in response to gibi's comment, which (as usual) was spot on.
15:34:53 fried_rice melwitt / mriedem: Is there going to be a nova/cinder interlock in Vancouver?
15:35:32 openstackgerrit Allen proposed openstack/nova master: Update the deprecate os_region_name option https://review.openstack.org/567829
15:36:15 melwitt fried_rice: not as a scheduled general session. cinder does have a forum session about discussing using placement in cinder which I think would be interesting to attend. cinder is also having a multiattach session IIRC
15:36:54 fried_rice melwitt: Thanks.
15:38:03 edmondsw mriedem you said user-facing strings should reference conf options like this: [powervm]/disk_driver
15:38:11 edmondsw is that '/' correct or a typo?
15:38:45 mriedem it is most correct
15:39:02 edmondsw interesting... what's the reasoning?
15:39:17 mriedem some people do [group]option
15:39:21 mriedem it doesn't really matter
15:39:34 mriedem i just don't like CONF.group.option in docs since that's code, not how it looks in ini
15:39:34 edmondsw k, tx
15:39:36 melwitt fried_rice: here's a list of the nova-related sessions for the forum http://lists.openstack.org/pipermail/openstack-dev/2018-April/129488.html
15:39:43 edmondsw sure
15:40:03 melwitt fried_rice: did you want to meet up with cinder for something specific?
15:40:07 mriedem melwitt: the new api removal session is also going to affect nova
15:40:35 fried_rice melwitt: One of my colleagues is subbing for Gerald at the summit and is asking.
15:40:56 melwitt mriedem: yes, also true. let me send a new mail, I've been meaning to anyway
15:42:27 melwitt and, the forumtopics.o.o site is broken, I don't know what happened there
15:42:41 mriedem they dropped it once the sessions were put into the main schedule
15:42:53 melwitt okay, I missed that memo
15:42:59 mriedem i don't think there was one
15:43:13 melwitt oh
15:44:55 mriedem https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21787/pre-emptible-instances-the-way-forward should also be on the list
15:45:20 melwitt ack. let me know if you notice any others I missed
15:45:33 mriedem https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21749/missing-features-in-openstack-for-public-clouds
15:45:40 mriedem ^ always overlaps with nova requirements
15:45:55 melwitt yup, good one
15:45:58 mriedem https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21881/api-debt-cleanup is the new one

Earlier   Later