| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-08 | |||
| 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. | |
| 22:02:52 | mriedem | like, i already noticed some issues in the searchlight docs just reading it | |
| 22:02:59 | mriedem | and pushed fixes | |
| 22:03:42 | rfolco | jaypipes, I just saw. Would work on that firt hour tomorrow morning. Thanks for your help on that. | |
| 22:04:04 | rfolco | jaypipes, need a microversion bump also | |
| 22:04:05 | jaypipes | rfolco: np. I'll look for it and review tomorrow. should be able to merge that pretty quickly. | |
| 22:04:10 | jaypipes | rfolco: yup. | |
| 22:04:55 | macsz | mriedem: ok, I will try to push this further, will keep you posted on the progress and if anything pops up | |
| 22:05:02 | mriedem | macsz: awesome, thank you | |
| 22:05:52 | rfolco | jaypipes, and I would bother you for keeping active on some upstream work too, if any pointer on where you need some help, let me know pls. | |
| 22:06:29 | jaypipes | rfolco: what's your level of tolerance for NUMA? :) | |
| 22:06:58 | macsz | mriedem: np :) | |
| 22:07:06 | rfolco | jaypipes, very very interested. I found some bugs on ppc testing numa :) | |
| 22:08:29 | rfolco | jaypipes, like this one https://review.openstack.org/#/c/340599/ | |
| 22:08:31 | jaypipes | rfolco: k. read this spec and thoroughly understand the concepts in it: https://review.openstack.org/#/c/284094/10/specs/ocata/approved/libvirt-emulator-threads-policy.rst. Then come help sfinucan and I on the review series here: https://review.openstack.org/#/c/400875/. While reviewing, consider how such resources might be represented in the new placement API (once nested resource providers are mergerd) | |
| 22:08:55 | dansmith | jaypipes: I threw up a bit in my mouth just *reading* that | |
| 22:09:00 | jaypipes | dansmith: yup. | |
| 22:09:10 | jaypipes | NUMA and I have a love-hate relationship. | |
| 22:09:26 | dansmith | like it loves you and you hate it? | |
| 22:10:06 | jaypipes | heh | |
| 22:10:32 | mriedem | jaypipes: you forgot to tell him to understand wtf nested resource providers are | |
| 22:11:25 | jaypipes | mriedem: tru enough. rfolco we can discuss tomorrow what nested resource providers are :) but in case you're interested in some "light" reading. https://review.openstack.org/#/c/386710/1/specs/ocata/approved/nested-resource-providers.rst | |
| 22:14:49 | rfolco | jaypipes, cool. Thanks! | |
| 22:15:09 | jaypipes | rfolco: don't thank me until you read those ;P | |
| 22:16:52 | edleafe | rfolco: you can't hide :) | |
| 22:19:29 | rfolco | edleafe, :-/ | |
| 22:25:34 | mriedem | pcidevice.address is a mac? | |
| 22:25:36 | mriedem | jaypipes: ^? | |
| 22:25:56 | dansmith | mriedem: no it's a pci address I think, like 1.34 | |
| 22:26:00 | mriedem | oh | |
| 22:26:03 | dansmith | or 0:1.34 or something like that | |
| 22:26:16 | mriedem | ok, was wondering why we needed the compute node id to uniquely identify a pcidevice by address | |
| 22:26:17 | mriedem | in pci_device_get_by_addr | |
| 22:26:38 | openstackgerrit | Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |
| 22:26:38 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach os-migrations about cells https://review.openstack.org/442685 | |
| 22:26:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024 | |
| 22:26:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388 | |
| 22:26:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach os-aggregates about cells https://review.openstack.org/442200 | |
| 22:26:40 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor cell loading in compute/api https://review.openstack.org/443337 | |
| 22:26:44 | mriedem | if we don't want to expose the pcidevice.id in the rest api, and get them by that id, and we don't have a uuid, we need something else | |
| 22:27:16 | mriedem | unless we add a uuid to the pcidevices table/object | |
| 22:27:31 | dansmith | *shudder* | |
| 22:27:45 | mriedem | yeah the only unique constraints are the id (primary key) and node_id/address | |
| 22:27:52 | mriedem | so, we'd have to add a uuid | |
| 22:28:14 | mriedem | heh, or we just deprecate that dumbass api and say you can't use it with multiple cells :) | |
| 22:28:22 | dansmith | heh | |
| 22:28:31 | mriedem | i feel like that was a half-baked api | |
| 22:28:42 | dansmith | s/api// | |
| 22:29:06 | mriedem | and if you want to know what pci devices are on a given compute node, you get them via the compute node resource provider | |
| 22:29:12 | mriedem | traits on the resource provider | |
| 22:29:23 | mriedem | jaypipes: will pcidevices be a trait on a compute node resource provider? | |
| 22:29:34 | mriedem | will/can | |
| 22:31:56 | jaypipes | mriedem: depends on what kind of PCI device. | |
| 22:32:06 | mriedem | dansmith: shart, services table doesn't have uuid either | |
| 22:32:57 | jaypipes | mriedem: SRIOV physical functions will be either child providers of a compute node *or* child providers of a NUMA socket resource provider, depending on whether the SRIOV NIC is affined to a particular NUMA socket. | |
| 22:33:29 | efried | mikal - Any chance we can start getting some reviews on change sets under https://review.openstack.org/#/q/topic:bp/powervm-nova-compute-driver ? The ones with +1s from nova-powervm cores (e.g. thorst adreznec esberglu) are ready for your look. Conveniently numbered, too ;-) | |
| 22:33:48 | jaypipes | mriedem: but pcidevices will definitely not be a "trait". Rather, things like the physical network tag would be a trait on the SRIOV physical function resource provider. | |
| 22:33:59 | mriedem | jaypipes: ack | |
| 22:34:24 | mriedem | i was looking for a way to weasle out of the compute rest api needing to show pcidevice per node information | |
| 22:34:54 | openstackgerrit | Sarafraj Singh proposed openstack/nova-specs master: WIP: Replace live migration steps and delays with memory iteration logic https://review.openstack.org/443339 | |
| 22:34:57 | mriedem | it's all information in os-pci, like all pcidevices on a node, and all pcidevices for a server | |
| 22:35:08 | mriedem | *informational | |
| 22:35:11 | jaypipes | mriedem: right. | |
| 22:35:24 | mriedem | and if i could say, get that information elsewhere... | |
| 22:35:26 | mriedem | my life would be easier | |
| 22:35:54 | mriedem | seems to fall into the 'nova does not want to be a metrics gatherer' anymore stadium | |
| 22:36:02 | jaypipes | mriedem: eventually the placement API will be able to represent the tree of providers on a compute node, yes. But things like PCI address information will not be in the placement API. | |
| 22:36:14 | mriedem | sure | |
| 22:36:24 | mriedem | ok, well i'll just spec this up with the way things are today then | |
| 22:36:33 | jaypipes | kk | |