Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-27
15:14:13 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test alloc_cands with indirectly sharing RPs https://review.openstack.org/519601
15:14:51 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add ProviderSummary.resource_class_names @property https://review.openstack.org/517646
15:24:56 openstackgerrit Dan Smith proposed openstack/nova master: Refined fix for validating image on rebuild https://review.openstack.org/521186
15:24:57 openstackgerrit Dan Smith proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
15:24:57 openstackgerrit Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
15:27:08 efried dansmith Is https://review.openstack.org/#/c/507638/ related to the "Migration fixups" priority at https://etherpad.openstack.org/p/nova-ptg-queens-placement L49?
15:27:25 efried dansmith Perhaps a better question: what all is related to the "migration fixups" priority at ^ ?
15:27:46 dansmith that's the last one
15:27:51 dansmith all the others merged already
15:28:07 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement query param schema for delete assisted vol https://review.openstack.org/513668
15:28:12 openstackgerrit Lajos Katona proposed openstack/nova master: Extend ServerMovingTests with custom resources https://review.openstack.org/497399
15:28:57 efried dansmith Cool. Looks like it needs a rebase?
15:29:02 dansmith hmm, yeah I guess so
15:30:13 efried dansmith (cdent) Is POST /allocations for multiple consumers (https://review.openstack.org/#/c/500073/) not related to the same effort?
15:30:23 dansmith it is
15:30:30 efried okay, thanks.
15:42:58 openstackgerrit Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638
15:45:02 openstackgerrit jiangpf proposed openstack/nova master: Encode libvirt domain XML in UTF-8 https://review.openstack.org/522161
15:45:12 efried jaypipes edleafe dansmith Draft: http://paste.openstack.org/show/627496/ -- As owners of the Three Priorities, would you please vet this for proper inclusion of linkitude?
15:49:42 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove unnecessary self.flags and ConfPatcher https://review.openstack.org/522993
15:53:35 edleafe efried: except for the double spaces after periods, it looks good
15:53:58 efried edleafe Thanks. Appreciate you taking a look. I'll work on the spacing thing.
15:54:21 edleafe It probably looks fine on a typewriter
15:55:35 efried edleafe That's how I proofread all my work.
16:24:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Versioned notifications for service create and delete https://review.openstack.org/519588
16:36:25 jaypipes efried: sure, looks fine to me, thank you!
16:36:32 efried jaypipes Thanks.
16:43:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Address nits from service create/destroy notification review https://review.openstack.org/523162
16:44:15 cdent nice placement functional test to get in: https://review.openstack.org/#/c/493865/
17:00:27 openstackgerrit Merged openstack/nova master: Implement query param schema for flavor index https://review.openstack.org/515413
17:00:34 openstackgerrit Merged openstack/nova master: Implement query param schema for fping index https://review.openstack.org/513890
17:13:52 dansmith mriedem: this is about to pass check: https://review.openstack.org/#/c/521186/
17:13:57 dansmith we gonna get that in soon?
17:15:26 mriedem haven't looked at the latest,
17:15:36 mriedem was going through your live migration swap allocs change quick
17:30:18 mriedem dansmith: ok looks like the only change in https://review.openstack.org/#/c/521186/ is the NUMATopologyFilter (which is looking at image properties so we should run it on rebuild) and the commit message title
17:32:17 mriedem artom: are you good with ^ now?
17:32:25 mriedem i think the only thing remaining is a release note
17:53:48 openstackgerrit Merged openstack/python-novaclient master: [ci] Use pseudo-random names for new resources https://review.openstack.org/479777
18:00:31 dansmith mriedem: yep, which you were going to do
18:00:57 mriedem yup
18:12:40 belmoreira mriedem, dansmith I have been working in enabling placement in newton with a nova_api DB per cell. I have some comments. Are you around?
18:13:22 dansmith belmoreira: depends, are they nice comments?
18:14:09 belmoreira :) a problem actually. And I would like your guidance
18:14:31 belmoreira A problem that I found is the deletion of the build_request in nova_api. Conductor that runs in the cell will try to delete it from the local nova_api
18:15:14 dansmith does the api cell have a dedicated nova_api db?
18:15:52 dansmith I guess it must
18:16:10 belmoreira yes, on cellsV1 we also have the same concept
18:16:32 dansmith what I mean is, you have a placement for the api cell, and a placement for each compute cell
18:16:42 mriedem belmoreira: is this when we delete an instance? it gets routed to the child cell api and that tries to delete the build request?
18:16:51 dansmith so I'm guessing the api puts in a buildrequest, but the compute cell tries to delete it during boot
18:17:23 dansmith which means you keep getting the buildrequest listed out of the api, and maybe compute goes to delete it, finds it deleted, and assumes the instance was deleted?
18:17:49 belmoreira dansmith, the plan was to enable placement also in api_cell just to be already there for the pike upgrade
18:18:59 belmoreira dansmith the issue is because the build_request is not deleted, the instance is created but remains in build state when the user list its instances
18:19:13 dansmith okay so the first half of what I said
18:19:24 belmoreira yes
18:19:32 dansmith belmoreira: so you'll need something in the instance sync back to the api cell that deletes the build request
18:20:27 belmoreira dansmith what I did was to change delete_build_request to delete the request from the nova_api DB in the top cell
18:20:53 belmoreira basically adding a new conf option to point to that DB that is used in this function
18:20:55 dansmith belmoreira: I think you want to delete the buildrequest here: https://github.com/openstack/nova/blob/master/nova/cells/messaging.py#L998
18:21:41 dansmith if you can test that, I think we could probably merge that change
18:22:27 belmoreira but it does it in the nova_api DB?
18:23:13 dansmith that code will run at the top-level nova-cells service, which would be configured to point to the top-level nova_api db right?
18:24:31 belmoreira I wasn't aware that nova-cells would sync nova_api DB. Only nova DB in top cell.
18:24:52 dansmith well, it doesn't do anything other than what you tell it to
18:25:13 dansmith historically there was no api db, so it didn't do anything there, but if you put code in there to find/delete the buildrequest then it will start to do some of that :)
18:25:34 belmoreira I see :)
18:25:53 belmoreira do we already have an example that nova_api DB is updated?
18:26:31 dansmith in nova-cells? not that I know of
18:27:14 dansmith it'll need to be graceful about buildrequest being deleted already, for the people that have a unified api db for all their cellsv1 cells
18:28:53 dansmith are you asking because of consistency or just because you're not sure how to go about the lookup/delete/
18:29:15 belmoreira my current patch changes the the delete_build_request in conductor/manager to delete it in the nova_api cell. I wasn't aiming to merge it upstream :)
18:29:16 dansmith because it should be roughly the thing done in delete_build_request
18:29:43 dansmith okay but wouldn't you rather a change that doesn't need a new config option and _is_ upstream?
18:30:12 belmoreira I started this conversation because I'm not sure if we are missing something else
18:30:37 belmoreira or this can have any consequence when upgrading then to ocata/pike
18:31:45 belmoreira dansmith sure I would prefer a proper fix
18:35:37 belmoreira dansmith thanks. I will have a look on how to have it in cells/messaging
18:36:19 dansmith belmoreira:
18:36:24 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Fix cellsv1 build request deletion if multiple api databases are used https://review.openstack.org/523187
18:36:38 dansmith belmoreira: see if that ^ works and/or tweak until it does and then we can move on with it
18:37:46 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Fix cellsv1 build request deletion if multiple api databases are used https://review.openstack.org/523187
18:40:07 belmoreira dansmith: thanks a lot. I will let you know
18:40:25 dansmith belmoreira: cool
18:50:36 artom mriedem, haven't had a chance to look at the latest version yet
18:50:41 artom Will do that now
18:54:57 openstackgerrit Jay Pipes proposed openstack/nova master: Use oslo_db Session in resource_provider.py https://review.openstack.org/523192
18:54:59 jaypipes mriedem, efried_rollin: ^
18:58:24 mriedem that is a large change, but looks like it's inevitable
18:59:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix 'force' parameter in os-quota-sets PUT schema https://review.openstack.org/523194
19:00:00 mriedem sdague: ^ is that 1 line os-quota-sets 'force' regression fix. the functional api samples are just to show the regression
19:05:51 artom Ohhh, the "need to open every PS individually to leave comments on each" thing is gone!
19:06:04 artom Man, my life just keeps on improving
19:06:09 artom This morning I learned about pssh
19:06:52 jaypipes mriedem: well, I figured it would be silly to fix only the conn.execute() calls in the lookup_entry_in_table() function and leave the other call locations.
19:08:08 mriedem jaypipes: if we need to backport that fix, then it would be best to fix the one place and do the massive refactor on top
19:08:44 jaypipes mriedem: there's latent bugs in all those other call locations.
19:09:18 jaypipes mriedem: you want to backport >1 patch or just one?
19:09:37 jaypipes mriedem: also, I'm happy to create a backport patch for pike/ocata
19:10:17 mriedem i single backport patch would be ideal, however, with the amount of refactoring that's gone on already in queens, the backport is probably going to suck, but if you want to own the backport then that's ok with me for a single change

Earlier   Later