| *** takashin has quit IRC | 00:39 | |
| *** takashin has joined #openstack-placement | 01:24 | |
| *** edleafe has quit IRC | 02:17 | |
| *** irclogbot_2 has quit IRC | 02:17 | |
| *** altlogbot_0 has quit IRC | 02:19 | |
| *** irclogbot_3 has joined #openstack-placement | 02:20 | |
| *** altlogbot_2 has joined #openstack-placement | 02:21 | |
| *** dklyle has joined #openstack-placement | 03:22 | |
| *** dklyle has quit IRC | 03:37 | |
| *** dklyle has joined #openstack-placement | 03:37 | |
| *** yikun has joined #openstack-placement | 06:41 | |
| *** helenafm has joined #openstack-placement | 07:40 | |
| *** e0ne has joined #openstack-placement | 08:51 | |
| *** takashin has left #openstack-placement | 09:33 | |
| *** cdent has joined #openstack-placement | 10:02 | |
| cdent | stephenfin: if you're around could you have a look at https://review.opendev.org/#/c/661922/ . Might be something that's on your consciousness since you've been looking at nova's api config | 10:03 |
|---|---|---|
| *** jaypipes has joined #openstack-placement | 11:02 | |
| *** ttsiouts has joined #openstack-placement | 11:35 | |
| *** ttsiouts has quit IRC | 11:37 | |
| *** ttsiouts has joined #openstack-placement | 11:37 | |
| *** openstackgerrit has joined #openstack-placement | 11:40 | |
| openstackgerrit | Merged openstack/placement master: Add olso.middleware.cors to conf generator https://review.opendev.org/661769 | 11:40 |
| *** ttsiouts has quit IRC | 11:42 | |
| *** jroll has quit IRC | 11:54 | |
| *** jroll has joined #openstack-placement | 11:54 | |
| *** edleafe has joined #openstack-placement | 12:13 | |
| cdent | for something that used to be 17s, .5s is a pretty nice improvement http://logs.openstack.org/45/662245/6/check/placement-perfload/ce03da1/logs/placement-perf.txt.gz | 12:30 |
| *** artom has quit IRC | 13:16 | |
| *** yikun has quit IRC | 13:41 | |
| *** mriedem has joined #openstack-placement | 13:54 | |
| efried | sean-k-mooney: You okay with https://review.opendev.org/#/c/658852/ at this point? | 14:57 |
| efried | cdent: to what do you attribute that ~30x improvement? | 14:57 |
| efried | removal of null root provider ID handling? | 14:57 |
| cdent | efried: the 17s was months and months ago, and was the thing that inspired the creation of perfload, we went from 17s to around 2 or 3 fixing some naive sql that I can't remember now | 14:58 |
| cdent | going from 2 to 1 ish was removing ovo | 14:58 |
| cdent | and since then it is removing null stuff, and some of tetsuro's cleanups | 14:59 |
| sean-k-mooney | efried: yes its still rather long but im fine with it | 14:59 |
| sean-k-mooney | efried: i would prefer if we did not need it | 15:00 |
| sean-k-mooney | but since we do i think its fine | 15:00 |
| sean-k-mooney | efried: ideally we would stop using the netdev names and jsut use pci address | 15:00 |
| *** artom has joined #openstack-placement | 15:01 | |
| efried | sean-k-mooney: I don't understand the infrastructure terribly well (the whole bw rp thing happened during my "blip" when IBM had me working on non-openstack). | 15:02 |
| efried | sean-k-mooney: In a world where all PCI devices are being reported in placement, where would this datum (identifier of the parent device) go? | 15:03 |
| efried | Would it be part of the RP name, like what we're doing for VGPUs? Would there be a parent provider (possibly with no resources, just a placeholder) associated with the parent device? Would this potentially tie into information supplied by the admin via providers.yaml? | 15:04 |
| cdent | I know we're already sometimes doing this but if we can avoid putting meaning in names, that would be great | 15:06 |
| sean-k-mooney | efried: it could be the RP name yes | 15:10 |
| efried | cdent: assuming you mean "provider names" specifically, ++. If you've been following the providers.yaml spec, one of the things I noted in there was that it could be used to get rid of the need to encode information in provider names. | 15:10 |
| sean-k-mooney | we are planning to have 1 RP per PF anyway so that shoudl work fine | 15:10 |
| cdent | efried: in practice, provider names, yes. But in general using names in a way that is to be interpreted by something is bad news: identifiers are preferred and in order for something to be a successful (that is persistent/long-lived) identifier it has to be meaningless. | 15:12 |
| cdent | or worms | 15:12 |
| efried | cdent: which kind of begs the question why we should need both a name and a uuid | 15:12 |
| cdent | i've wondered that from the start | 15:13 |
| cdent | and it is for the same reason as always: humans | 15:13 |
| efried | I'm a fan of name from a human debuggability standpoint, yes. | 15:13 |
| sean-k-mooney | the uuid are not easy to retrofit | 15:13 |
| cdent | and it works out okay as long as the names are only used as labels | 15:13 |
| efried | But it seems like these days we wind up using UUIDs as (at least part of) the name anyway. | 15:13 |
| sean-k-mooney | nova currently passes a pci address to neutron to indicate which vf or pf will be asigned to the guest | 15:14 |
| efried | anyway, I wasn't trying to get off onto a philosophical tangent here. I'm just trying to understand where this "SRIOV VF parent name reporting" thing will happen in the utopian future where the SRIOV device is modeled in placement. | 15:14 |
| efried | okay, what does neutron do with that information? | 15:14 |
| sean-k-mooney | in the case of a VF it can perform action such as applying qos or ther things to the prot | 15:15 |
| efried | neutron goes and messes with the hardware? | 15:16 |
| sean-k-mooney | the sriov nic agent does | 15:16 |
| sean-k-mooney | it used to manage the link state on the vf | 15:16 |
| efried | (where "hardware" could be software of course) | 15:16 |
| efried | okay | 15:16 |
| sean-k-mooney | so if you set the neuton port down it would aftully set the linkstate down | 15:17 |
| efried | but in this case | 15:17 |
| efried | we're talking about sending neutron a) the identity of the VF (or rather, its parent, since that's where the qos would be established??) and b) the QoS info itself (bw limits) - which are already part of the port's metadata since gibi's bw work. | 15:18 |
| sean-k-mooney | in the case of min bandwith it does not need to do anything | 15:18 |
| sean-k-mooney | neutron basically messed up the api | 15:18 |
| efried | For SRIOV VF, does the qos get established at the PF level, or can it handle individual VFs? | 15:18 |
| sean-k-mooney | the neutron config and the nova one used the pci addres to whitelist things and nova tell neutron what vf it is with the pci address too but for some reason they decided to use the PF netdave name and encode it in the RP name | 15:19 |
| sean-k-mooney | efried: it configred via the PF per vf | 15:19 |
| sean-k-mooney | the bandwith rps created by neutron encode a special meaning into the RP name | 15:20 |
| efried | so neutron needs to be told *both* the VF and the PF PCI addresses | 15:20 |
| sean-k-mooney | i belive its <hostname>:<agent name>:<PF netdev name> | 15:20 |
| efried | maybe I need to back up a little bit: The bw qos support in stein, is that SRIOV-capable at all? | 15:21 |
| sean-k-mooney | efried: no it can workout the PF name form the VF | 15:21 |
| sean-k-mooney | /name/address | 15:21 |
| efried | ...then why do we need this trait? | 15:21 |
| sean-k-mooney | efried: yes it is | 15:21 |
| efried | SRIOV only with direct PF, but not yet with VF? | 15:21 |
| sean-k-mooney | i am not sure why gibi wanted this trait | 15:22 |
| efried | Well, it sounds like he wants to use it to do prefiltering | 15:22 |
| sean-k-mooney | i think it was to avoid host that dont support it but the invetoryes do that already | 15:22 |
| sean-k-mooney | see prefiltering does not make sense to me | 15:23 |
| sean-k-mooney | the bandwith inventories only exist if you manully configure the bandwith in the neutron config | 15:23 |
| sean-k-mooney | the only nova that would be able to report this trait would be new enough to not need too | 15:24 |
| efried | Okay. I'm going to no-vote (in case I'm just thick) and chat with gibi about it when he's available. | 15:26 |
| efried | Thnaks for the talk sean-k-mooney | 15:26 |
| efried | cdent: You +2'd, do you understand what's going on here? | 15:27 |
| efried | (talking about https://review.opendev.org/#/c/658852/) | 15:27 |
| sean-k-mooney | i think gibi was trying to gaurd against upgrade issues with migration but we are only going to allow migration between nodes that are alredy runing train and since libvirt report the pf assocation form stine its not really an issue | 15:28 |
| sean-k-mooney | and on hyperviors that are not libvirt you just dont define the neutron config options | 15:29 |
| cdent | efried: I took the need for it as given, based on some of the other warts present in the network related stuff. I don't really have a problem with creating a trait that we then don't use. The issue is more with creating something that is -wrong- from the outset | 15:31 |
| cdent | "as given" in the sense of "if gibi says this is needed, I guess we probably do" | 15:31 |
| efried | okay | 15:35 |
| *** helenafm has quit IRC | 15:43 | |
| sean-k-mooney | efried: cdent this is why we need the pf name by the way currently https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2125-L2140 | 15:45 |
| sean-k-mooney | its really fragile sicne we dont know the agent name and there are case wher eyou can have two agents managing the same PF | 15:46 |
| sean-k-mooney | e.g. where the PF is used by ovs and the VF are used for sriov | 15:46 |
| efried | lovely | 15:47 |
| sean-k-mooney | im not sure if we can change neutron to report the RP differently but really we need a mapping service somewhere to avoid this | 15:48 |
| efried | If we had traits like CUSTOM_IFNAME_FOO and CUSTOM_AGENTNAME_BAR on the provider... | 15:48 |
| sean-k-mooney | i think this can go away entirly with newer palcement | 15:48 |
| sean-k-mooney | efried: i think this is working around the fact we didnt know how to map the allcoation candiate back to the rp | 15:49 |
| efried | ...then we would have to find them: | 15:49 |
| efried | for t in placement.get_all_traits(rp_uuid): | 15:49 |
| efried | if t.startswith('CUSTOM_IFNAME_'): ... | 15:49 |
| efried | if t.startswith('CUSTOM_AGENTNAME_'): ... | 15:49 |
| efried | yup, so mappings will help, and providers.yaml will help. | 15:49 |
| sean-k-mooney | efried: this was unrealted to the provider.yaml and was related to provider summiries or allocation candiate not having all the info you need | 15:50 |
| efried | it's both really | 15:50 |
| sean-k-mooney | im refering to the feature where we need to be able to map allocations back to resouce groups that requested tehm | 15:51 |
| efried | Yes. Encoding info into the provider name to help derive the mapping which tells you which PCI device is associated. | 15:51 |
| sean-k-mooney | for both cycborg and neutorn ports | 15:51 |
| efried | having the mapping in GET /a_c response is only half of the puzzle. | 15:52 |
| efried | With just that, you still need things encoded into the RP name. | 15:52 |
| sean-k-mooney | yes but i think its what forced us to use the name in stien | 15:52 |
| efried | sure. | 15:52 |
| efried | But with providers.yaml, you've gotten the "RP to real thing" mapping given by the admin. | 15:53 |
| efried | so you don't need to encode in the rp name anymore | 15:53 |
| sean-k-mooney | well you dont. if we have that mapping nova never need to decode teh RP name | 15:53 |
| efried | right | 15:53 |
| efried | providers.yaml doesn't exist yet :) | 15:53 |
| sean-k-mooney | but you dont need the provder yaml for that | 15:53 |
| efried | where else do you get the "RP to real thing" mapping? | 15:53 |
| sean-k-mooney | you dont unlesss you have an api for it i guess | 15:54 |
| sean-k-mooney | the issue with bandwith for sriov is we have two service trying to manage different aspect of the same hardware | 15:55 |
| sean-k-mooney | nova will own the inventory of VFs on the PF RP and neuton want to own the bandwtih of the PF | 15:55 |
| efried | Mm. That's kind of problematic. | 15:56 |
| efried | I can handle it mentally if different services wholly own different RPs. | 15:56 |
| sean-k-mooney | we havent pick back up the work to report the PCI devices in placement from 2 cycles ago but we need to get back aroudn to that | 15:56 |
| efried | But having different services own different inventories on the same RP... that'll take me a minute to grasp. | 15:56 |
| efried | sean-k-mooney: Yes, we need providers.yaml for that, because we don't want to try to retrofit [pci]passthrough_whitelist into placement. | 15:57 |
| sean-k-mooney | well today nova select the vf from the devices we track in the pci tracker and tell netuon this is the one you get | 15:57 |
| sean-k-mooney | we are using the Parent PF name to corralted to the value in the pci_devices table | 15:58 |
| sean-k-mooney | and we get teh parent pf name form the allocation the bandwith came form by parsing the RP name | 15:58 |
| sean-k-mooney | which is all supper messy | 15:58 |
| sean-k-mooney | because when placment select the bandwith inventory we dont know if the numa affint is correct for the vf or if there is still a vf free on that pf | 15:59 |
| sean-k-mooney | the provider.yaml could help if neutron also used it to know how much bandeith each pf should have. | 16:00 |
| sean-k-mooney | or rather if we just didnt set the neutron config values and only used the provdier.yaml | 16:00 |
| cdent | presumably putting everything in provider.yaml is not going to be ideal as that file is on the compute node and some of the stuff neutron cares-about/controls is not. | 16:15 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Implement allocation candidate mappings https://review.opendev.org/662245 | 16:16 |
| cdent | efried, sean-k-mooney ^ that is ready for real review. spec has merged. and it helps with some of the above discussions | 16:17 |
| *** e0ne has quit IRC | 16:22 | |
| sean-k-mooney | cdent: right that is the feature i was refering to that fixes half of the issue | 16:27 |
| sean-k-mooney | * spec -> feature | 16:28 |
| efried | cdent: Did we forget reshaper? | 16:45 |
| cdent | meh! | 16:45 |
| cdent | how much do I hate reshaper? | 16:45 |
| cdent | |-------------------------| < at least that much | 16:46 |
| * cdent fixes | 16:46 | |
| cdent | can't we just get rid of reshaper instead? | 16:47 |
| efried | cdent: Oh, sure, do that instead. | 16:47 |
| cdent | \o/ | 16:47 |
| efried | cdent: Don't fix up too quickly, ima leave a couple other minor comments on this pass. | 16:48 |
| * cdent mumbles something about legacy providers | 16:48 | |
| cdent | aye | 16:48 |
| * cdent grumbles some more about reshaper | 17:02 | |
| * edleafe notices that cdent is especially grumbly today | 17:03 | |
| efried | cdent: Finished, have at r. | 17:09 |
| cdent | thanks | 17:10 |
| openstackgerrit | Merged openstack/placement master: Modernize CORS config and setup https://review.opendev.org/661922 | 17:12 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Implement allocation candidate mappings https://review.opendev.org/662245 | 17:31 |
| cdent | efried: that might be better now, but I probably added some other typo | 17:34 |
| efried | ack | 17:34 |
| efried | cdent: What's the incantation to see request & response payloads in gabbi? | 17:35 |
| cdent | for one test add 'verbose: True' | 17:35 |
| efried | thx | 17:35 |
| cdent | for all the tests in one file you can add it to defaults | 17:36 |
| *** amodi has quit IRC | 17:40 | |
| *** e0ne has joined #openstack-placement | 18:02 | |
| efried | cdent: Can we confirm our respective understandings of (d), please? | 18:06 |
| *** e0ne has quit IRC | 18:07 | |
| efried | It may help or it may hurt for you to read my latest comment. | 18:07 |
| * cdent experiences fear | 18:08 | |
| cdent | efried: I'm going to have to read that multiple times, because I don't agree with your statements about how it works today nor about the concepualization of what would change to make d true | 18:10 |
| cdent | but that's only after an initial read | 18:10 |
| efried | cdent: Okay, cool, cause I tested the way it works today, so that's the only part I'm pretty sure about. | 18:10 |
| cdent | then it is _extremely_ likely that we are using the similar terms to mean different things | 18:11 |
| cdent | when you say "there is *no* interaction between the unsuffixed group and other groups" my brain flips to "of course there is an interaction, they must be on the same compute host" | 18:12 |
| cdent | (i.e., share a root) | 18:12 |
| efried | okay, let me put it a different way: the unsuffixed group has the same effect on the result within the same tree regardless of what happens in the other request groups. | 18:15 |
| cdent | yes | 18:15 |
| efried | what we're talking about with (d) will change that paradigm. | 18:16 |
| efried | agree? | 18:16 |
| *** mriedem has quit IRC | 18:17 | |
| * cdent thinks | 18:17 | |
| *** mriedem has joined #openstack-placement | 18:19 | |
| cdent | efried: can you re-state why the ideas thus far must "change the behavior for unsuffixed+resourced;" | 18:22 |
| efried | Was just about to say: | 18:23 |
| efried | I think the first thing to clear up is that we're talking about making resourceless+unsuffixed a special case. Because any attempt to define behavior that applies to unsuffixed for both resourced and resourceless would change behavior for the former. | 18:23 |
| cdent | okay, if you re-explain that, I may understand where you are coming from better | 18:24 |
| cdent | because in my digging around in the code we're already pretty weird about how traits and aggregates work compared to how inventory works | 18:24 |
| efried | Because today the trait component of unsuffixed+resourced only applies to providers that satisfy the inventory component. | 18:24 |
| efried | ...of the same group | 18:25 |
| efried | which is nonsensical (or would simply be a no-op) if extended to resourceless | 18:25 |
| cdent | which is how we ended up with "traits and aggregates flow down" and we all agreed (in denver) that that's how it should have been all along, and yes it changes things | 18:26 |
| cdent | (and it avoids cousins) | 18:27 |
| cdent | (distant cousins) | 18:27 |
| efried | okay, I was under the impression we had ultimately decided *not* to do "flow down". | 18:27 |
| cdent | you did | 18:27 |
| efried | because we didn't wind up needing it. | 18:27 |
| efried | ...until (maybe) now | 18:28 |
| cdent | you said "if we have substree we don't need flow down" | 18:28 |
| efried | though I thought through "flow down" and I still don't see how it helps the situation here. | 18:28 |
| cdent | can you give the simplest overview of "the situation here"? | 18:29 |
| efried | wow, "though I thought through". English sucks | 18:29 |
| cdent | I suspect it is a modelling problem we might be able to get around... | 18:29 |
| efried | What is the meaning (in English) of unsuffixed+resourceless+forbidden? | 18:30 |
| cdent | okay, that (to me) is a ncie succinct statement | 18:31 |
| * cdent thinks | 18:31 | |
| cdent | the straightforward answer is: that trait doesn't show up in any of the proposed providers: it's a late check | 18:32 |
| efried | By the same token, unsuffixed+resourceless+required => the trait must show up in at least one of the proposed providers. | 18:33 |
| cdent | it's not going to exactly mirror required because of the nature of forbidden: it's always forbidden | 18:33 |
| efried | right | 18:34 |
| efried | which *kind of* maps, because today unsuffixed+resourced+forbidden means "trait must not show up in *any* of the providers contributing to the *inventory* in the *same* (unsuffixed) group" | 18:34 |
| cdent | if you do [t 7sBF] you get cousins contributing when they shouldn't, which is why you need to choose wisely on where the trait is | 18:34 |
| purplerbot | <efried> By the same token, unsuffixed+resourceless+required => the trait must show up in at least one of the proposed providers. [2019-06-10 18:33:50.290394] [n 7sBF] | 18:34 |
| cdent | so if you flow down, instead, you avoid an e.g. nic accidentally contributing in a complex tree | 18:35 |
| efried | no, [t 7sBF] means cousins don't contribute *unless* they also contribute resources, right? | 18:35 |
| purplerbot | <efried> By the same token, unsuffixed+resourceless+required => the trait must show up in at least one of the proposed providers. [2019-06-10 18:33:50.290394] [n 7sBF] | 18:35 |
| cdent | what do you mean by proposed providers? I mean any of the providers in the tree, not those contributing inventory | 18:36 |
| cdent | s/not/not just/ | 18:36 |
| efried | oh | 18:37 |
| cdent | so "proposed providers" means "the providers that show up in provider summaries" | 18:37 |
| cdent | which is superset of those that show up in allocation requests | 18:37 |
| *** amodi has joined #openstack-placement | 18:38 | |
| cdent | I've run out of time for today. I think we're probably closer to something workable than we think because: a) our terms are getting closer, b) we agree that some change in behavior is okay | 18:38 |
| efried | um | 18:39 |
| efried | at least b) not so | 18:39 |
| efried | I think changing the behavior for resourced is a baaad idea. | 18:39 |
| efried | But okay, let's reconvene tomorrow. | 18:40 |
| cdent | resource_d_ or resource_s_? | 18:40 |
| efried | Perhaps we can encourage tetsuro to be present for Wednesday office hours and hash this out. | 18:40 |
| cdent | seems a good idea. Do you ever see him? I usually do not? | 18:40 |
| efried | resourced. Changing behavior for request groups containing a 'resources*' component is a bad idea IMO. | 18:40 |
| efried | I don't, no. His hours seem to be the exact reverse of ours. | 18:41 |
| cdent | it's something that we talked about quite a bit during the pre-ptg and in denver: pretty much everybody wanted something like X flows down | 18:41 |
| cdent | regardless of resourced or unresourced | 18:42 |
| efried | well | 18:42 |
| cdent | you might go back over the mail archives to see if there's anything in there to convince you differently (or conversely to strengthen your arguments) | 18:42 |
| efried | If we do that, I think we probably want to do it in its own microversion. I.e. not try to implement resourceless at the same microversion. | 18:42 |
| cdent | that sounds painful | 18:43 |
| efried | srsly? | 18:43 |
| cdent | since we're struggling to conceptualize how resourceless works without it | 18:43 |
| cdent | we want a unified conceptual shift, where possible | 18:43 |
| efried | I'm struggling to conceptualize how it works without bringing resourceless into the mix | 18:43 |
| efried | which is why I think it should ride on its own. | 18:44 |
| efried | "how does this affect what we do today?" | 18:44 |
| cdent | again, our prepositions may be losing us: I'm not entirely sure what you mean by "it" | 18:44 |
| efried | "flow down" | 18:44 |
| efried | Introducing "flow down" to what we already have established (at microversion 1.33, say) is going to be a mindfuck, at least for me. | 18:44 |
| cdent | hmm. I am confused, because above I thought we were discussing "we can't figure out how to do resourceless well unless we introduce something like flow down" | 18:45 |
| efried | so I want to be able to grasp it independently, before putting another really confusing thing like resourceless into the mix. | 18:45 |
| efried | ^ it = "flow down" | 18:45 |
| cdent | oh. you're saying flow down _first_ | 18:45 |
| efried | yes | 18:45 |
| cdent | I read it the other way, and couldn't grok how that would work | 18:46 |
| efried | yeah, no, that wouldn't make any sense | 18:46 |
| cdent | this is why I hate anything under 10,000 words | 18:46 |
| cdent | anyway: i must go. I do think I chew over the pre-ptg discussion would likely do us both some good for the next round | 18:46 |
| cdent | if you get a brainwave, put it on the spec | 18:47 |
| cdent | especially because that appears to be the best way to engage tetsuro and he's got some clear thinking on this stuff | 18:47 |
| efried | perhaps the way to go is to enumerate explicitly some use cases and what we want them to mean in English; then try to come up with a unified definition (or set of definitions, if we need special cases) that satisfies them. | 18:48 |
| efried | have a good evening o/ | 18:48 |
| * cdent has no use cases, which makes this a harder problem | 18:50 | |
| cdent | my use cases are | 18:50 |
| cdent | destroy nested and the reshaper | 18:50 |
| cdent | no wait | 18:50 |
| cdent | good night all | 18:52 |
| *** cdent has quit IRC | 18:52 | |
| *** amodi has quit IRC | 19:21 | |
| *** jaypipes has quit IRC | 20:06 | |
| *** jaypipes has joined #openstack-placement | 20:06 | |
| *** amodi has joined #openstack-placement | 20:25 | |
| *** artom has quit IRC | 21:19 | |
| *** mriedem has quit IRC | 22:08 | |
| *** artom has joined #openstack-placement | 22:33 | |
| *** efried has quit IRC | 22:39 | |
| *** efried has joined #openstack-placement | 22:41 | |
| *** takashin has joined #openstack-placement | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!