Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-14
11:52:13 openstackgerrit Chen Hanxiao proposed openstack/nova master: libvirt: remove TODO on validation of scsi model https://review.openstack.org/525055
12:00:25 openstackgerrit Chen Hanxiao proposed openstack/nova master: libvirt: add Linux distribution guest only description for inject_xxx options https://review.openstack.org/528441
12:18:18 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/544277
12:30:02 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/544282
13:19:20 openstackgerrit Lajos Katona proposed openstack/osc-placement master: Random names for functional tests https://review.openstack.org/542745
13:58:24 mriedem happy valentines day everyone <3
13:59:48 gibi mriedem: same to you :)
14:02:55 openstackgerrit Bence Romsics proposed openstack/nova master: Clarify 'capacity' in placement api-ref https://review.openstack.org/544347
14:03:59 gibi mriedem: I left two questions in https://review.openstack.org/#/c/543971/3/nova/compute/manager.py@4457
14:09:39 mriedem replied
14:12:18 mriedem ildikov: i realized yesterday that we never handled this https://review.openstack.org/#/c/544152/1/specs/queens/implemented/multi-attach-volume.rst@136
14:12:44 mriedem ildikov: but then realized, the only volume types that rely on that, don't support multiattach, so it's not really a problem we need to worry about right now
14:12:55 mriedem things like NFS
14:13:36 ildikov mriedem: good points, thanks for looking into it
14:14:16 ildikov agreed on let's worry about it later
14:14:38 ildikov do you think it should be a PTG micro topic or we're good for now?
14:15:00 mriedem nah
14:15:09 mriedem unless someone really cares about making NFS support multiattach
14:15:10 mriedem which i doubt
14:15:32 mriedem well, NFS + multiattach + snapshot
14:16:00 ildikov yeah, let's not encourage people if don't have to :)
14:17:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Test websocketproxy with TLS in the nova-next job https://review.openstack.org/513160
14:22:16 ildikov mriedem: I also didn't talk about shared_targets in the docs for now, wonder whether I should or not?
14:23:07 mriedem probably not necessary; nova uses them for locking if the microversion is available
14:23:14 mriedem but it's not required
14:28:37 ildikov ok, fine, I'll leave it then
14:29:05 ildikov it's something more interesting for driver maintainers anyway so does not seem to be admin guide content, but wanted to check
14:55:30 openstackgerrit Merged openstack/nova-specs master: Fix missing blueprint URLs https://review.openstack.org/542543
14:56:22 mriedem dansmith: i won't be around for the cells v2 meeting today (if there was going to be one)
14:58:56 openstackgerrit Merged openstack/nova-specs master: List/show all server migration types https://review.openstack.org/540256
14:59:34 dansmith mriedem: ack
14:59:55 dansmith I'm around for it, but I don't really have anything specific other than my reviews
15:07:29 belmoreira have some placement related questions. dansmith, mriedem do you have some time?
15:07:49 dansmith belmoreira: I can try
15:08:03 belmoreira thanks dansmith
15:08:14 belmoreira we are running local placements in ocata. Trying to consolidate them and get some performance numbers.
15:08:39 belmoreira But, when nodes are retired (removed from the cloud) they continue to exist in placement. Are they eventually removed? not seeing how
15:08:49 dansmith no they're not
15:09:29 belmoreira and they are included in the candidates?
15:09:44 mriedem hmm, they probably are,
15:09:51 dansmith they would be from placement yeah, but scheduler would filter them out
15:09:56 mriedem similarly, we don't have a direct hook to remove entries from the compute_nodes table
15:10:08 belmoreira we are seeing that placement continue to include them
15:10:10 dansmith this isn't really any different from our compute nodes befoe placement
15:10:31 mriedem belmoreira: when you retire a node, do you manually remove it's entry from the nova.compute_nodes table?
15:10:54 belmoreira the difference is that the scheduling is now global
15:11:29 belmoreira removing few hundred nodes could impact the performance of the entire cloud
15:11:45 mriedem what did you do when you removed them before this?
15:11:57 belmoreira mriedem currently we remove entire cells, so we don't have this problem
15:12:12 mriedem ok so you drop the entire nova db
15:12:14 mriedem for that cell
15:12:19 belmoreira correct
15:12:32 dansmith hmm, and compute nodes don't get mirrored up?
15:12:42 dansmith I can't remember how that works, but maybe they don't
15:12:54 mriedem we've talked before about adding a nova-manage CLI to remove a compute_nodes entry
15:12:59 belmoreira dansmith what do you mean?
15:13:11 mriedem the host_mappings table would be pointing at hosts that no longer exist too
15:13:13 dansmith belmoreira: well, in cellsv1 a bunch of stuff gets mirrored up to the top db
15:13:28 dansmith belmoreira: I would have expected compute_nodes would too, but I don't really know I guess
15:13:34 dansmith it doesn't matter though
15:13:39 belmoreira dansmith compute nodes are only in the child cells
15:13:46 dansmith going forward, pruning will have to happen when you remove stuff
15:14:01 dansmith ack
15:14:14 belmoreira is there any work already done in that?
15:14:16 dansmith so one way to do that, I think,
15:14:29 mriedem we likely could use a nova-manage CLI that removes the compute_nodes table entry in the cell, the host_mappings entry in the api db, and the resource_providers entry in placement
15:14:37 dansmith would be to go through host_mappings, find any mappings that don't have a cell, remove them and tell placement about it
15:14:53 dansmith mriedem: yeah, but if you remove a cell first, you'll need a way to clean up the mess too
15:15:07 tssurya mriedem : yes that would be a useful command
15:15:18 mriedem can we delete a cell mapping that has host mappings?
15:15:24 mriedem don't we have a fkey?
15:15:33 dansmith idk
15:15:50 mriedem nullable=False)
15:15:50 mriedem cell_id = Column(Integer, ForeignKey('cell_mappings.id'),
15:16:06 mriedem and nullable=False
15:16:14 mriedem yeah, so we have to remove host mappings if we remove a cell mapping
15:16:17 dansmith but,
15:16:29 dansmith you can delete a cell with delete_cell and it will nuke all the host mappings
15:16:33 dansmith so then you're really toast
15:16:41 mriedem if you use --force yeah
15:17:27 dansmith so we have delete_host
15:17:58 dansmith which unmaps the compute node, and deletes the hostmapping
15:18:06 dansmith so in both of those I guess we need to update placement
15:18:23 mriedem i'm not sure why delete_host requires a --cell_uuid arg,
15:18:26 mriedem but that's unrelated
15:18:37 dansmith although nova-manage doesn't do any rpc or calls to other services right now, AFAIK, so we kinda need a --no-placement flag to each of those in case you're operating in an island
15:19:13 mriedem well,
15:19:29 mriedem nova-manage could use the scheduler report client and handle an http error response if it can't talk to placement
15:19:43 dansmith yes, but you dont' want to proceed then,
15:19:48 dansmith unless you tell it to
15:20:00 dansmith because if we can't talk to placement, we can't proceed without corrupting the linkage (as we are now)
15:20:07 dansmith so you need to fail in that case, unless instructed to ignore
15:20:36 dansmith someone with placement down during an upgrade pruning a host wants to know that they're about to orphan some placement records
15:20:38 mriedem could just throw another --force on delete_host
15:20:48 dansmith we need it for both though
15:20:54 dansmith delete_cell and delete_host
15:21:00 mriedem sure, we have --force on delete_cell already
15:21:04 dansmith and delete_cell has --force already which means something else though
15:21:15 dansmith it means "delete all the things, yeah", but this would be "and also, don't delete some stuff"
15:21:21 mriedem ha

Earlier   Later