Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-22
14:05:21 esberglu_ (3 takeaways)
14:05:35 efried esberglu_ Probably not #3
14:06:10 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901
14:06:11 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900
14:06:21 dansmith #3 seems useful to me too, but that's the order of importance, yeah
14:07:42 esberglu_ K I'm on the hook for that. I'll be back with questions I'm sure
14:32:20 openstackgerrit sahid proposed openstack/nova master: libvirt: update the logic to configure volume with scsi controller https://review.openstack.org/459741
14:32:21 openstackgerrit sahid proposed openstack/nova master: libvirt: update LibvirtConfigGuestDeviceAddress to provide XML https://review.openstack.org/459737
14:32:21 openstackgerrit sahid proposed openstack/nova master: libvirt: update logic to configure device for scsi controller https://review.openstack.org/459740
14:32:22 openstackgerrit sahid proposed openstack/nova master: libvirt: set full description of the controller used by disk https://review.openstack.org/459738
14:32:22 openstackgerrit sahid proposed openstack/nova master: libvirt: rearange how scsi controller is defined https://review.openstack.org/459739
14:37:16 mriedem https://review.openstack.org/#/c/430608/ worries me a bit - it's defining what "in progress" means for various types of migrations which is going to impact how the API works
14:37:32 mriedem i.e. post-copy is not considered in-progress,
14:37:43 mriedem and there is no 'evacuating' status while we're actually performing the evacuate
14:38:02 mriedem seems like this could be a mess to manage in the future, since we're exposing an internal state machine out of the api
14:39:57 openstackgerrit Dan Smith proposed openstack/nova master: De-complicate some of the instance delete path https://review.openstack.org/458636
14:39:58 openstackgerrit Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
14:39:59 openstackgerrit Dan Smith proposed openstack/nova master: Fix live migration devstack hook for multicell environment https://review.openstack.org/458537
14:39:59 openstackgerrit Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
14:40:00 openstackgerrit Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059
14:52:18 danpawlik mriedem: : Hi. Can you review https://review.openstack.org/#/c/459753/ when you have some free time? Thanks
14:55:07 mriedem cdent: alex_xu: wondering about your opinions on 400 vs 409 here https://review.openstack.org/#/c/459483/5/nova/api/openstack/compute/server_migrations.py@89
14:55:16 mriedem it might not matter since we're never very consistent on those
15:18:33 mriedem sfinucan: replied in https://review.openstack.org/#/c/464088/
15:18:40 mriedem sfinucan: i think we can assume the db name doesn't have / in it
15:18:47 mriedem sfinucan: and / is the url separator
15:18:55 sfinucan mriedem: Then we're good
15:18:59 mriedem i'd rather not over-complicate this until someone shows up with a case that breaks this
15:19:12 sfinucan I was just making sure - I've been caught rotten with rstrip before
15:19:22 mriedem ok
15:19:26 melwitt dansmith, jaypipes, johnthetubaguy, mriedem: just a heads up that the quotas set is ready to look at again
15:19:48 jaypipes melwitt: awesome. will review after bauzas/edleafe claims series.
15:20:01 mriedem melwitt: then i shall review now
15:20:35 melwitt cool, thanks :)
15:39:42 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Remove dead code https://review.openstack.org/460662
15:46:48 openstackgerrit melanie witt proposed openstack/nova master: convert unicode to string before we connect to rados https://review.openstack.org/465404
15:54:15 bauzas jaypipes: thanks for commenting my series, good points there
15:54:24 bauzas jaypipes: just rev'ing
15:57:04 bauzas jaypipes: I think we agreed on having the conductor doing the allocations, right?
15:57:20 jaypipes bauzas: I don't remember such an agreement, no.
15:57:33 bauzas jaypipes: and scheduler passing a list of alternatives to the conductor for that, as per dan's session
15:57:43 bauzas because of the rescheduling issue
15:57:45 mriedem melwitt: random questions https://review.openstack.org/#/c/446239/7/nova/compute/api.py@5167
15:57:55 jaypipes bauzas: there are no rescheduling issues if we do the claims in the scheduler.
15:57:55 dansmith jaypipes: wat. really?
15:58:03 jaypipes dansmith: yes.
15:58:17 dansmith jaypipes: we totally said we were doing them in the conductor in boston :)
15:58:32 bauzas jaypipes: I explained why the scheduler sould be a wrong possibilty in some email
15:58:34 bauzas lemme find it
15:58:53 jaypipes dansmith, bauzas: reschedule issues go away if we do the claims in the scheduler.
15:59:02 dansmith jaypipes: eh?
15:59:16 bauzas jaypipes: http://lists.openstack.org/pipermail/openstack-dev/2017-May/117039.html
15:59:20 dansmith jaypipes: if we do it in the scheduler, then we end up with scheduler claiming first, then conductor claiming on reschedules
15:59:24 dansmith jaypipes: which I don't like
15:59:25 bauzas "There are multiple reasons why we chose to use conductor for that :"
15:59:30 jaypipes dansmith: you remember when I told operators that "95% or more of the reasons for retries go away when the scheduler does claims"?
15:59:51 jaypipes dansmith: there is no reason to do reschedules at all if we do claims in the scheduler.
15:59:52 dansmith jaypipes: sure, but we're talking about claiming during the scheduling phase
16:00:10 dansmith I can't believe we're having this conversation again :)
16:00:20 mriedem the problem is no one is defining what 'reschedule' means here
16:00:26 jaypipes dansmith: I thought you were cool with getting rid of retries entirely?
16:00:33 dansmith lol
16:00:34 mriedem i think what jaypipes is talking about is calling select_destinations again
16:00:37 bauzas that's at least a bit unfortunate I spent my week on something I thought we had a consensus :)
16:00:50 bauzas without doing any reviews (sorry folks!)
16:01:00 mriedem i think dansmith is talking about deleting failed allocations and looping to the next host in our list, which is not the same
16:01:13 mriedem which we could do in conductor,
16:01:19 mriedem if the scheduler gives a list from select_destinations
16:01:30 bauzas mriedem: I implemented that in https://review.openstack.org/#/c/460455/15/nova/conductor/manager.py
16:01:31 jaypipes mriedem: no, I'm talking about the scheduler doing the "retry" of a claim/allocation.
16:01:33 mriedem "reschedule" is a broad ass term
16:01:51 bauzas jaypipes: please see at http://lists.openstack.org/pipermail/openstack-dev/2017-May/117039.html
16:01:58 dansmith how about a hangout at the bottom of the hour?
16:02:09 bauzas jaypipes: there are 4 reasons why I disagree with doing the allocation within the scheduler worker process
16:02:22 openstackgerrit Stephen Finucane proposed openstack/nova master: utils: Replace 'utf8' with oslo.utils equivalent https://review.openstack.org/466799
16:02:22 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Remove dead code https://review.openstack.org/460662
16:02:29 mriedem dansmith: yeah need a hangout, so 1PM ET?
16:02:57 jaypipes dansmith, bauzas: I strongly think we should be calling placement's POST /allocations from the scheduler, not the conductor. Sorry if this surprises people.
16:03:03 dansmith mriedem: mriedem sure
16:03:26 dansmith jaypipes: yes that's very surprising.. we all had this conversation in boston and I was sure we had consensus
16:03:33 jaypipes I specifically remember saying "doing claims in the scheduler gets rid of the retry issues (and all associated "upcall shenanigans")
16:03:50 bauzas jaypipes: well, I do remember exatly operators nodding at dansmith's proposal of passing down a list of possible acceptable hosts
16:03:53 dansmith jaypipes: so, we also agreed we can't fully get rid of retries right away, which means conductor _will_ have to do allocation calls as well
16:03:56 dansmith right
16:03:57 mriedem note we've also been saying "claims in the scheduler*"
16:04:16 dansmith jaypipes: I'm opposed to doing it in scheduler first and conductor second.. I think that's a mess
16:04:23 melwitt mriedem: thanks. short answer is, you're right. replying on the review now
16:04:35 jaypipes dansmith: I see no reason to "do it in the conductor second".
16:04:45 mriedem melwitt: ok - so basically wtf for how this behaves, but it's not backward incompatible so ok
16:04:52 jaypipes dansmith: if the scheduler does the claim, there is no reason for anything else to do the claim.
16:05:00 dansmith jaypipes: reschedule
16:05:06 mriedem jaypipes: retries from the computes go up to the cell conductor
16:05:10 jaypipes dansmith: we should *not* support reschedule. period.
16:05:16 dansmith jaypipes: there was almost zero support in the room for eliminating reschedules
16:05:30 bauzas I thought we had that discussion in Boston :/
16:05:33 dansmith jaypipes: which was the whole point of the "send extra hosts down to the cell" discussion, which you were definitely there for
16:05:36 dansmith bauzas: we did
16:05:36 jaypipes dansmith: yes there was when I said "95% of the causes of reschedules currently will be eliminated"
16:05:44 dansmith *facepalm*
16:06:03 melwitt mriedem: yeah ... I'm trying to make all of the formats of count as dict consistent. before, I had some dict and some int so that only things that could have project and user would be dict, but people found that more confusing

Earlier   Later