| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 20:04:10 | openstackgerrit | Dan Smith proposed openstack/nova master: Address minor feedback in superconductor targeting https://review.openstack.org/443175 | |
| 20:04:10 | openstackgerrit | Dan Smith proposed openstack/nova master: Make server_groups determine deleted-ness from InstanceMappingList https://review.openstack.org/443293 | |
| 20:04:11 | openstackgerrit | Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736 | |
| 20:24:22 | jaypipes | mriedem: sorry, been out for a few hours dealing with a couple things. yes, ComputeNode.stats is where that stuff lives, IIRC. | |
| 20:26:38 | mriedem | dansmith: this one is a bit hairy https://review.openstack.org/#/c/442162/ | |
| 20:26:42 | mriedem | but pretty sure _find_service is busted | |
| 20:27:08 | mriedem | jaypipes: np. want to get this in? https://review.openstack.org/#/c/415885 | |
| 20:30:54 | dansmith | mriedem: there's a reason I did it that way, give me a sec to remember | |
| 20:30:58 | dansmith | mriedem: but I commented on the others | |
| 20:34:03 | jaypipes | mriedem: sure, gimme a sec | |
| 20:35:19 | dansmith | mriedem: I'm not sure, it works locally and in the gate in the not-first cell looking for n-cpu | |
| 20:35:29 | dansmith | but I'm having trouble fetching the context from my brain | |
| 20:36:54 | dansmith | oh, no, wait | |
| 20:36:55 | dansmith | I bet that is only in the path of service delete, | |
| 20:37:07 | dansmith | which might not be n-cpu | |
| 20:37:33 | dansmith | dangit | |
| 20:38:03 | mriedem | yeah service delete calls service_get_by_id | |
| 20:38:12 | mriedem | and we never test service delete | |
| 20:38:20 | mriedem | not in tempest anyway | |
| 20:38:41 | mriedem | could have a simple functional test with multiple nova-compute services in 2 cells and you delete one in the 2nd cell | |
| 20:38:52 | mriedem | that's also going to be jacked... | |
| 20:39:08 | mriedem | b/c 2 nova-computes in 2 cells are going to have ids 1 and 2 | |
| 20:39:18 | mriedem | so you'll delete the first one found in the first cell | |
| 20:39:18 | mriedem | shit | |
| 20:39:28 | mriedem | which might not be the one you wanted to delete | |
| 20:39:47 | mriedem | i want to delete nova-compute 2 in cell 2, but it depends the service with id=2 in cell1 | |
| 20:40:54 | dansmith | yeah, this api is fairly retarded | |
| 20:42:17 | mriedem | wasn't there a similar one for getting a compute node by id | |
| 20:42:32 | mriedem | yeah compute_node_get | |
| 20:42:40 | dansmith | the api does that by name though right? | |
| 20:43:02 | mriedem | no | |
| 20:43:16 | mriedem | your comment even says "Unfortunately this API exposes database identifiers | |
| 20:43:16 | mriedem | # which means we really can't do something efficient here" | |
| 20:43:27 | mriedem | so the os-hypervisors uptime and show APIs pass in the compute node id | |
| 20:43:40 | dansmith | mriedem: that comment is about service | |
| 20:43:43 | mriedem | so we'll be showing details and uptime info for the first match on that id in the first cell we hit | |
| 20:43:49 | mriedem | dansmith: it's in there twice | |
| 20:43:55 | mriedem | as i said, this is a hairy change :) | |
| 20:44:00 | mriedem | lots of moving parts | |
| 20:44:11 | dansmith | okay, I remember seeing name in os-hypervisors multiple times.. maybe there's a search or something? | |
| 20:44:21 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=show-hypervisor-details-detail#show-hypervisor-details | |
| 20:44:24 | mriedem | there is the search one | |
| 20:44:41 | dansmith | okay maybe that's what I'm thinking of | |
| 20:44:51 | mriedem | dansmith: that would be this one https://developer.openstack.org/api-ref/compute/?expanded=search-hypervisor-detail#search-hypervisor | |
| 20:45:12 | mriedem | yeah so service delete, and compute node show and uptime are going to be wrong | |
| 20:45:15 | mriedem | in multi-cell | |
| 20:45:48 | mriedem | there is also some pci device jackholery in _get_all_nodes_pci_devices but that's probably already cell-specific / context aware at that point | |
| 20:45:50 | mriedem | at least i hope so | |
| 20:46:13 | mriedem | oh no that's in the f'ing api too | |
| 20:46:27 | dansmith | come on, the internal DB ids leak out for PCI? | |
| 20:46:36 | mriedem | heh, of course we don't actually document the pci api | |
| 20:47:20 | mriedem | f yeah they do https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/pci.py#L105 | |
| 20:47:27 | mriedem | oh well | |
| 20:47:30 | mriedem | maybe not in that case | |
| 20:48:18 | dansmith | admins can see them? | |
| 20:48:25 | dansmith | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/pci.py#L28 | |
| 20:48:25 | mriedem | so for listing pci devices, we get all compute nodes in all cells, and then get all pci devices for all compute nodes in all cells | |
| 20:50:15 | dansmith | mriedem: okay so I squashed the revision patch from the top into the base patch, which needed a recheck in the gate anyway, | |
| 20:50:33 | dansmith | mriedem: and I guess I'll stack this one at the endish so we can proceed separate from the compute id problem | |
| 20:50:46 | mriedem | i thought you needed this hypervisor one to get tests passing? | |
| 20:51:07 | mriedem | also, cells meeting in 9 minutes | |
| 20:51:09 | dansmith | I surely do, but not any more than any of the rest of it | |
| 20:51:22 | dansmith | although this touches a lot of stuff, so it'll probably not be easy to move it.. fsck | |
| 20:51:45 | dansmith | or not.. it moved with no conflicts | |
| 20:55:10 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288 | |
| 20:55:29 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: console https://review.openstack.org/409402 | |
| 20:56:46 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022 | |
| 20:56:47 | openstackgerrit | Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |
| 20:56:48 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach os-migrations about cells https://review.openstack.org/442685 | |
| 20:56:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024 | |
| 20:56:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388 | |
| 20:56:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach os-aggregates about cells https://review.openstack.org/442200 | |
| 20:57:06 | dansmith | okay, that's ^ a partial stack of things you have not yet shat upon | |
| 20:57:15 | dansmith | that hopefully can go ahead of the things that have bigger questions | |
| 20:59:07 | mriedem | i've got an idea of the path forward, but we can talk about it during the cells meeting | |
| 20:59:11 | dansmith | when those are done in check I'll push up the rest, which has the edits to the HostAPI patch, minus anything about the id leakage | |
| 20:59:14 | mriedem | where i'm sure you'll sh*t upon it | |
| 20:59:24 | dansmith | ...says the major shitter in this convo | |
| 20:59:51 | mriedem | hey, i know you appreciate it deep down | |
| 21:09:22 | jaypipes | sfinucan: https://review.openstack.org/#/c/385023/ | |
| 21:56:54 | macsz | mriedem: want to talk now? | |
| 21:56:55 | mriedem | macsz: sure | |
| 21:56:58 | mriedem | let me find the link | |
| 21:57:11 | mriedem | macsz: this is what i had started for ci testing https://review.openstack.org/#/c/441696/ | |
| 21:57:22 | mriedem | i use devstack-gate to test out changes that eventually go into project-config for job changes | |
| 21:57:34 | mriedem | i'm trying to get a ci run with searchlight deployed, | |
| 21:57:48 | mriedem | and everything setup such that nova is sending notifications and searchlight is consuming them | |
| 21:57:59 | mriedem | since we'll need that in a ci job when nova-api starts using searchlight to list instances | |
| 21:58:15 | mriedem | it should be fairly mechanical, i'm just having a hard time finding the time to work on it | |
| 21:58:27 | mriedem | for example, the searchlight devstack plugin doesn't configure anything except searchlight, | |
| 21:58:35 | mriedem | but when reading the searchlight deploy docs, they talk about configuring nova | |
| 21:58:42 | mriedem | e.g. https://review.openstack.org/#/c/441711/ | |
| 22:00:44 | macsz | mriedem: hmm ok | |
| 22:01:26 | mriedem | macsz: it might also just be a matter of getting searchlight setup locally with devstack, including the horizon plugin, | |
| 22:01:37 | macsz | I will look through the docs and will try to deploy it locally | |
| 22:01:38 | mriedem | and then make sure when you create an instance in nova, does it show up in searchlight in horizon | |
| 22:01:55 | mriedem | and then note any deployment changes you need to make to devstack along the way, and that is the list of stuff we have to do for the CI job | |
| 22:02:13 | mriedem | the CI job won't need the searchlight ui plugin since we don't test horizon, but that would help you locally | |
| 22:02:40 | mriedem | i'm thinking it will be a pretty small set of changes we need, but i haven't had the time to do it locally - would be awesome if someone can go through that | |
| 22:02:46 | jaypipes | rfolco: https://review.openstack.org/#/c/416669/ ready for rebasing. | |