| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-22 | |||
| 13:50:42 | bauzas | as I said earlier, I'm fine with anyone working on my changes if we're not duplicating work | |
| 13:50:50 | jaypipes | bauzas: cool, thank you sir. | |
| 13:51:24 | bauzas | anyway, I'm still around for 24h | |
| 13:51:29 | dansmith | efried: --strict means we keep existing behavior without that being passed to avoid breaking anyone current right? | |
| 13:51:57 | dansmith | that's probably the best, in which case I'm good with not finding anything is an "error" | |
| 13:52:24 | efried | dansmith Right. Adding --strict would mean, "any result that isn't 'I discovered a host' is a failure." | |
| 13:52:36 | dansmith | yep | |
| 13:53:33 | efried | dansmith For current impl, is there a command I can use to ask whether this host has been discovered (registered with a cell)? | |
| 13:54:03 | dansmith | efried: no, such a command would be welcome too I think | |
| 13:54:12 | dansmith | efried: also I think you can backport the --strict patch | |
| 13:54:15 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 13:54:19 | efried | dansmith To ocata? | |
| 13:54:34 | efried | Cause none of this was implemented in newton? | |
| 13:54:34 | dansmith | efried: aye | |
| 13:54:39 | efried | (or at least not required) | |
| 13:54:45 | dansmith | not required yeah | |
| 13:54:47 | efried | dig | |
| 13:55:11 | dansmith | efried: just MHO but we did similar things before to make the transition easier before people got there, so I think it's legit | |
| 13:55:36 | dansmith | that way esberglu_ gets the full gamut of nova dev interaction :) | |
| 13:56:00 | efried | Trial by fire | |
| 13:57:11 | efried | dansmith So `nova-manage cell_v2 list_cells [--verbose]` doesn't show which hosts are in which cells? | |
| 13:57:53 | dansmith | efried: I think it does, but it won't return pass/fail for a single host.. but you can use grep and get that I think | |
| 13:57:53 | efried | nope | |
| 13:58:03 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 13:58:09 | dansmith | oh wait, | |
| 13:58:14 | dansmith | not after my faster-er patch | |
| 13:58:15 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081 | |
| 13:58:18 | dansmith | but in ocata you can I think | |
| 13:58:31 | dansmith | in master now, it is able to efficiently determine which hosts are unmapped | |
| 13:58:37 | dansmith | in ocata it couldn't, which means it had to get them all | |
| 13:59:32 | efried | dansmith Would list_cells be an appropriate place to put the "include mapped hosts" behavior? Potentially via a new flag? | |
| 14:00:04 | mriedem | is it odd that migration.status goes from accepted -> pre-migrating -> done | failed; with no 'evacuating' or middle state? | |
| 14:00:09 | mriedem | for evacuate i mean | |
| 14:00:36 | efried | dansmith Versus a whole new command, like `nova-manage cell_v2 host_mapping` | |
| 14:02:10 | dansmith | efried: I think a command of "is host $hostname mapped" that returns a boolean is likely to be useful for scripting deployments | |
| 14:02:19 | dansmith | list_cells shouldn't return hosts, IMHO | |
| 14:02:26 | efried | dansmith okay. | |
| 14:02:27 | dansmith | but a list-hosts-in-cell command is probably also useful | |
| 14:04:09 | esberglu_ | efried: dansmith: Just getting caught back up. Sounds like the two takeaways are that we want to add | |
| 14:04:26 | esberglu_ | - A --strict flag to the discover_hosts command (and backport to ocata) | |
| 14:04:51 | esberglu_ | - A new command to check if a host is mapped | |
| 14:05:07 | esberglu_ | - A new command to list hosts in a cell | |
| 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 | |