| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 17:32:33 | jaypipes | sean-k-mooney: I would oppose that. traits are boolean values. | |
| 17:33:02 | jaypipes | sean-k-mooney: the physical network that a NIC is associated with must be a custom trait. | |
| 17:33:08 | sean-k-mooney | but just as we have defiend the custom_ as a user defiend prefix i was hoping we could have other prefiex reseved for internal use such as the physnet | |
| 17:33:21 | jaypipes | sean-k-mooney: why though? | |
| 17:33:35 | jaypipes | sean-k-mooney: what benefit does that bring? | |
| 17:33:51 | sean-k-mooney | so i can tell the differnece between traits used by openstack to function and ones added by admins for there own use | |
| 17:34:37 | jaypipes | sean-k-mooney: that' | |
| 17:34:39 | dansmith | sean-k-mooney: that's custom | |
| 17:34:41 | jaypipes | s the CUSTOM_ prefix. | |
| 17:34:58 | sean-k-mooney | dansmith: a physnet is custom? | |
| 17:35:10 | dansmith | o.O | |
| 17:35:19 | dansmith | if it's not a standard one, then it's custom :) | |
| 17:35:33 | sean-k-mooney | we need to apply physnets to all sriov vf otherwise we cant use them with neutron networks | |
| 17:35:38 | jaypipes | there's no such thing as a "standard physnet"... | |
| 17:36:03 | jaypipes | it's a named entity | |
| 17:36:18 | sean-k-mooney | yes we cant standaries the full trait because its just a config option | |
| 17:36:31 | sean-k-mooney | hence haveing a standard prefix | |
| 17:36:40 | jaypipes | no, it's not a config option... it's an attribute of the port profile isn't it? | |
| 17:36:48 | sean-k-mooney | no | |
| 17:36:54 | dansmith | not for sriov right? | |
| 17:36:59 | sean-k-mooney | it a neutorn and nova config option | |
| 17:37:05 | dansmith | but even still, those'll all have to be custom ones anyway right? | |
| 17:37:10 | sean-k-mooney | for sriov its set in the pci whitelist | |
| 17:37:16 | jaypipes | ugh | |
| 17:37:17 | dansmith | because they're not enumerable across all deployments | |
| 17:37:46 | jaypipes | what dansmith said. | |
| 17:37:48 | sean-k-mooney | well no because i have no ideay which pci device is connected to which phyical network unless you tell me | |
| 17:38:02 | dansmith | um, wat? | |
| 17:38:18 | jaypipes | dansmith: he's saying "you" as in the nova.conf setting. | |
| 17:38:43 | sean-k-mooney | yes its not automatically discoverable so we have to declare it statically in the nova.conf | |
| 17:38:51 | dansmith | we will probably have to do something like we were going to do for ironic, which is synthesize CUSTOM_PHYSNET_$thing_in_your_config | |
| 17:38:53 | jaypipes | i.e. unless the nova.conf pci whitelist indicates which PCI devices are asssociated with which physnet, there's no way for code on the compute host to know. | |
| 17:38:58 | dansmith | sean-k-mooney: right, I know | |
| 17:39:02 | dansmith | sure | |
| 17:39:06 | dansmith | we have that today | |
| 17:39:33 | sean-k-mooney | dansmith: yes so when we systesize traiths i was suggesting uses a prefix other then custom to do that | |
| 17:39:44 | dansmith | sean-k-mooney: yeah but that does't work | |
| 17:39:53 | dansmith | sean-k-mooney: because anything but a CUSTOM_ is a hard enum in a library | |
| 17:40:02 | dansmith | sean-k-mooney: anything synthesized by the operator or somecode has to be CUSTOM_ | |
| 17:40:40 | sean-k-mooney | dansmith: correct so im suggesting that we extend os tratis to have other prefixes that are not enums. if that is not desirabel then CUSTOM_ works too | |
| 17:41:04 | sean-k-mooney | i just can tell if its created by a person of synthesize by openstack | |
| 17:44:16 | sean-k-mooney | may main concern is that as an enduse i have no way of knowing is CUSTOM_PHYSNET_<XYZ> is special custom trait that casuse a change in the behaior of openstack vs CUSTOM_MY_TRAIT_<XYZ> that does not. | |
| 17:48:13 | sean-k-mooney | anyway got to run. food is calling | |
| 17:55:49 | gvrangan | https://docs.openstack.org/nova/pike Folloed the latest install in centOs7 | |
| 17:55:56 | gvrangan | the hypervisot list is not listing | |
| 17:56:03 | gvrangan | the computes are not added to cells | |
| 17:56:09 | gvrangan | Should the doc be updated? | |
| 18:04:12 | gvrangan | when I execure the discover, the computes are not getting listed | |
| 18:04:29 | gvrangan | should the nova compute be configure differntly in pike? | |
| 18:07:09 | melwitt | gvrangan: which instructions did you follow? this? https://docs.openstack.org/nova/latest/user/cells.html#fresh-install | |
| 18:07:11 | jaypipes | gvrangan: pls see /topic. Best to ask your question on the @openstack mailing list. | |
| 18:08:31 | gvrangan | melwitt, I followed only the nhttps://docs.openstack.org/nova/pike/install/controller-install-rdo.html and https://docs.openstack.org/nova/pike/install/compute-install-rdo.html | |
| 18:11:53 | openstackgerrit | Jackie Truong proposed openstack/python-novaclient master: Microversion 2.54 - Add trusted_certificates param https://review.openstack.org/500396 | |
| 18:13:34 | melwitt | gvrangan: okay. I see all of the commands you need are in those docs. so you have to make sure you see cell0 and cell1 when you do 'nova-manage cell_v2 list_cells' and then make sure you did 'nova-manage cell_v2 discover_hosts --verbose' after you have brought up the compute node | |
| 18:20:28 | rybridges1 | Hello all | |
| 18:20:35 | rybridges1 | I had a quick question about nova cells | |
| 18:21:24 | rybridges1 | We are currently attempting to deploy a fresh ocata cluster. I was wondering if [cells] section of nova.conf is required for cells v2 at all? I read in the comments that the stuff under that section is only for cells v1, but just wanted to make sure | |
| 18:23:19 | melwitt | rybridges1: that's correct. see 4. on the FAQ, [cells] section is not to be used https://docs.openstack.org/nova/latest/user/cells.html#faqs | |
| 18:24:53 | efried | jaypipes We were talking last week about how to model e.g. minimum egreess bandwidth support on SR-IOV VFs. | |
| 18:24:56 | rybridges1 | Okay great! Thanks melwitt | |
| 18:25:08 | jaypipes | efried: who is we? :) | |
| 18:25:25 | efried | dansmith suggested we would model the PF as a RP with e.g. SRIOV_VFS=48,EGRESS_BW_PCT=100 | |
| 18:26:15 | efried | So that basically you would grab some number of VFs and some percentage of the bandwidth, and whichever you exhausted first would take that PF out of the running for subsequent requests, kind of thing. | |
| 18:26:28 | efried | First of all, is this along the lines of what you've been thinking? | |
| 18:27:05 | efried | Doesn't have to be percentage; could be bps or whatever; point is the number of VFs and the total bandwidth are separate but parallel resource classes in the RP. | |
| 18:27:33 | cdent | “parallel”? | |
| 18:27:59 | efried | just meaning that they're RC inventories on the same RP | |
| 18:28:37 | cdent | isn’t that what we do around here? | |
| 18:28:45 | efried | Some of us shouldn't. | |
| 18:29:25 | jaypipes | efried: yep. that's pretty close. I don't like the pct versus using bytes_per_sec but yeah. | |
| 18:29:39 | jaypipes | efried: in fact, that's pretty close to what I had written on the ML, no? | |
| 18:29:47 | efried | jaypipes okay, so help me fill in the gaps here. | |
| 18:30:16 | efried | IRL I'll have multiple PF-y RPs, and let's say they each have both of those RC inventories defined. | |
| 18:30:30 | jaypipes | k | |
| 18:31:14 | efried | When I make a request for, say, SRIOV_VFS=1,EGRESS_BW_PCT=20 -- what's to stop placement from allocating the VF inventory from one RP and the egress bandwidth inventory from another?? | |
| 18:32:47 | openstackgerrit | Mateusz Kowalski proposed openstack/nova stable/pike: Handle keypair not found from metadata server using cells https://review.openstack.org/500953 | |
| 18:32:59 | openstackgerrit | Mateusz Kowalski proposed openstack/nova stable/ocata: Handle keypair not found from metadata server using cells https://review.openstack.org/500954 | |
| 18:36:59 | jaypipes | efried: actually currently stressing out trying to figure out how to deal with this hurricane that is going to hit us. | |
| 18:37:13 | efried | jaypipes Been there, done that. Where you at? | |
| 18:37:26 | jaypipes | efried: and getting my girls to safety and my wife to her plane flight to Italy on Sunday :( | |
| 18:37:33 | jaypipes | efried: Sarasota | |
| 18:38:29 | efried | Totally counts as (b) | |
| 18:40:28 | jaypipes | efried: the answer to your question is: nothing would stop placement from doing so. | |
| 18:40:52 | efried | jaypipes Then... "eek". | |
| 18:40:59 | jaypipes | efried: yeah | |
| 18:41:37 | efried | The followup, of course, is what about SRIOV_VFS=4,EGRESS_BW_PCT=20 ? | |
| 18:42:11 | jaypipes | efried: we would need to add some mechanism to the request that says "make sure the thing providing EGRESS_BW_PCT and SRIOV_VF is the same provider. | |
| 18:42:44 | efried | jaypipes Rojah dat. Any thoughts been assayed in that regard to this point? | |
| 18:43:39 | melwitt | mriedem: I'm gonna sign up for that nova project update redhat interview thing at the PTG | |
| 18:44:05 | jaypipes | efried: resource_constraints=same_provider:SRIOV_NET_VF,NET_EGRESS_BYTES_SEC&resources=SRIOV_NET_VF:1&NET_EGRESS_BYTES_SEC:20000 | |
| 18:44:06 | mriedem | melwitt: awesome | |
| 18:44:53 | openstackgerrit | Merged openstack/nova master: Replace dd with shred for zeroing lvm volumes. https://review.openstack.org/495532 | |
| 18:46:35 | efried | jaypipes What stage is that semantic in? Just popped out of your head, in a spec somewhere, implemented, released? | |
| 18:48:20 | jaypipes | efried: popped off the top of my thick, oh so thick, head of hair. | |
| 18:48:30 | melwitt | mriedem: let me know if there's anything else you'd like me to highlight other than cells and placement. I was gonna go through the rel notes and dev ML announcements to see what else to mention | |
| 18:49:10 | melwitt | and then I'll use the nova PTG etherpad to summarize what's coming up in queens | |
| 18:49:10 | efried | jaypipes Cool, will add it to discussion points. | |
| 18:49:46 | efried | I still need to complete my reading, but presumably there's a syntax for requesting multiple different resources of the same class with different traits? | |
| 18:51:26 | efried | jaypipes So like, pursuant to the anti-affinity grouping conversation avolkov and I were having earlier, I want to be able to say gimme (SRIOV_NET_VF:1&NET_EGRESS_BYTES_SET:2000&traits=CUSTOM_PF_HA_GROUP_1; SRIOV_NET_VF:1&NET_EGRESS_BYTES_SET:2000&traits=CUSTOM_PF_HA_GROUP_2) | |
| 18:51:36 | mriedem | melwitt: i can send you my list that i sent internally | |