| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-14 | |||
| 11:41:05 | cdent | no, I think it should be fixed | |
| 11:41:28 | bauzas | cdent: if so, reopen the bug with your comment please | |
| 11:41:33 | bauzas | I'm fine with reopening it | |
| 11:41:36 | cdent | if allocation_ratio is one and reserved is > 0 then it is wrong | |
| 11:41:37 | cdent | will do | |
| 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 | |