| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-05 | |||
| 16:32:29 | dansmith | efried: this is not that, this is a generic and abstract requested trait.. placement has already filtered out virt hosts that can't do that generic thing | |
| 16:32:41 | efried | okay, "preferred trait" is new to me. | |
| 16:32:55 | dansmith | efried: doesn't matter, required trait is the same | |
| 16:32:58 | dansmith | for this example | |
| 16:33:27 | sean-k-mooney | efriad: the idea was the required traits would be enforced by filter and prefered trais would be consumed by weigher | |
| 16:33:52 | dansmith | sean-k-mooney: and both could feed into how the virt driver does something eventually | |
| 16:34:02 | sean-k-mooney | yes | |
| 16:34:18 | abhi89 | hey guys.. can someone please review https://review.openstack.org/#/c/485121/.. pending from a long time.. | |
| 16:34:40 | sean-k-mooney | my go to examle is dpdk requires sse3 to work but would prefer avx for performance reasons | |
| 16:34:54 | lbragstad | mriedem: https://review.openstack.org/#/c/500918/ | |
| 16:41:25 | mriedem | lbragstad: comment inline | |
| 16:41:37 | efried | What's the plan for associating physnets with RPs? | |
| 16:42:49 | efried | Does the RP have a trait like CUSTOM_PHYSNET_XXX where XXX is somehow associated with the port's physnet? | |
| 16:43:52 | lbragstad | mriedem: good call - done | |
| 16:46:31 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323 | |
| 16:46:32 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324 | |
| 16:46:33 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 17:07:40 | sean-k-mooney | efried: i think physnet can be a standard trait prefix. so NW_PHYSNET_XXX | |
| 17:08:11 | efried | Okay; I thought you weren't allowed to create a trait with anything other than a CUSTOM_ prefix. | |
| 17:08:14 | efried | But that wasn't really my question. | |
| 17:08:22 | sean-k-mooney | efried: this was one of the usecases i wanted to have key value traits for originally but standard prefixes i think are ok too | |
| 17:08:41 | efried | My question is: who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port? | |
| 17:09:46 | sean-k-mooney | efried: technically yes but lacking key value traits i was hoping we could have a set of stadard prefixes that you were also allowed to create. phynets is one the other option is to have physnet be a field of resouce class | |
| 17:10:41 | efried | Okay, but who's responsible for recognizing that the XXX corresponds to the physnet in the neutron port? | |
| 17:10:45 | sean-k-mooney | efried: well if nova reads the phynet form the port it can compute the trait name and placement can then just do a sting match | |
| 17:11:31 | efried | That would be one way... is that how it's going to work? Or is this still part of the open discussion? | |
| 17:12:36 | sean-k-mooney | still open. i was also thinking of ways to have neutron pass traits/resouce prodier request to nova so that nova does not have to compute the trait name | |
| 17:13:25 | sean-k-mooney | for example addint a traits field to the vif_binding details with the physnet name trait so that nova does not have to query neutron for the physnet | |
| 17:13:54 | sean-k-mooney | again this is up for discussion | |
| 17:15:26 | efried | sean-k-mooney Okay, thanks for the info. | |
| 17:16:56 | mriedem | dtantsur|afk: vdrok: do you know if there are any docs that talk about quota considerations for a tenant that is accessing both VMs and BMs? it's a topic i added here for the ptg: https://etherpad.openstack.org/p/queens-PTG-vmbm | |
| 17:17:32 | vdrok | hrm, not in ironic docs I think. | |
| 17:17:57 | sean-k-mooney | nova is currently the main thing interacting with traits and placement but i would like to add some knolowe of those apis to neutron so that nova does not have to know as much deails about the networking contriants going forwand and can jsut fowrad the reques for resouce providers and traints form neutorn. | |
| 17:18:42 | mriedem | sean-k-mooney: i think mlavalle already started something like a placement client in neutron a few releases ago | |
| 17:20:11 | sean-k-mooney | mriedem: cool we will need if for thinks like bandwith qos. e.g. if we model bandwith in placement and you increase the minium bandwith for a port i should go to placement and check that there is capasity left and increase the claim if so or fail the requst if not | |
| 17:21:30 | sean-k-mooney | e.g. if port is bound it should only allow bandwith to be increased if placement says there is capasity to do so and provide error to user if it cannot | |
| 17:30:39 | jaypipes | sean-k-mooney: there is no such thing as a standard trait prefix. | |
| 17:30:51 | jaypipes | sean-k-mooney: that XXX means it has to be a custom trait. | |
| 17:31:42 | sean-k-mooney | jaypipes: correct today. i was hopping we could add them if we were going to use them for standard thing like physnets to differenciate them for user created traits | |
| 17:32:25 | sean-k-mooney | basically any traint that does not start with custom_ i consider to be a trait that must be defiend in os-traits | |
| 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 | |