| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-03 | |||
| 17:51:36 | jaypipes | mriedem: you're welcome :) | |
| 17:51:41 | jaypipes | TIL... | |
| 17:51:42 | mriedem | i actually like this format | |
| 17:51:51 | mriedem | puts mine to shame | |
| 17:51:54 | mriedem | damn you | |
| 17:53:34 | mriedem | rxtx factors, ha | |
| 17:53:49 | mriedem | didn't i see sfinucan trying to remove all of that? | |
| 17:55:22 | mriedem | or maybe that's a joke b/c rxtx factors would normally be an extra spec, but aren't | |
| 17:55:26 | mriedem | for whatever reason | |
| 17:57:13 | melwitt | dansmith: do you know what is the purpose of this stringify that puts extra quotes around a string? https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L269 | |
| 17:57:31 | sean-k-mooney | mriedem: aren't rx/tx factors more of a qos thing. e.g. sould they still exist now that neutron has a qos api | |
| 17:57:50 | mriedem | sean-k-mooney: they are only used for port qos yeah | |
| 17:58:04 | dansmith | melwitt: it's because that ends up in the repr, right? | |
| 17:58:20 | mriedem | sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1088 | |
| 17:58:33 | mriedem | sean-k-mooney: that's the only place we ues them for neutron in nova | |
| 17:58:39 | mriedem | but they probably shouldn't be in nova | |
| 17:58:49 | melwitt | dansmith: yeah. I'm trying to wrap my head around this stuff for when a StringField contains a unicode thing. and I was wondering what the adding of the quotes around the StringField value does if it's already a string? | |
| 17:59:00 | mriedem | if you want qos on your port, create the port in neutron and provide it when creating the server | |
| 17:59:10 | melwitt | dansmith: I'm probably dumbly missing something here | |
| 17:59:13 | dansmith | melwitt: it's just for display | |
| 17:59:37 | dansmith | melwitt: so you end up with Instance<name="foo bar"> and not Instance<name=foo bar> | |
| 17:59:38 | sean-k-mooney | mriedem: so they were part of the old port qos support. i think this inclunces the libvirt xml generation somehow if i remember correctly | |
| 17:59:45 | melwitt | dansmith: right, okay. thank you | |
| 18:02:33 | mriedem | sean-k-mooney: i don't see that happening | |
| 18:03:20 | mriedem | sean-k-mooney: in fact the only place i see rxtx* in nova/virt is in the xenapi driver | |
| 18:03:33 | sean-k-mooney | ya im looking at the git repo currently and i cant find it either but i taguht it used too.. | |
| 18:03:36 | mriedem | and it's based on a flag that's only set if you're using nova-network | |
| 18:03:38 | sean-k-mooney | well its set here https://github.com/openstack/nova/blob/501a0fe65afabb7e6a8b1e2d1ca0fbcea941d2d1/nova/tests/unit/virt/libvirt/test_vif.py#L507 | |
| 18:03:45 | sean-k-mooney | but i dont know if its used | |
| 18:03:57 | mriedem | sean-k-mooney: that's just a flavor | |
| 18:04:02 | mriedem | the rxtx_factor is defined on the nova flavor | |
| 18:04:03 | sean-k-mooney | yes | |
| 18:04:20 | mriedem | we don't use that when plugging the vifs in libvirt though, or creating the domain xml, from what i can tell | |
| 18:04:38 | johnthetubaguy | mriedem: thats a rackspace special for quark | |
| 18:04:44 | johnthetubaguy | mriedem: AFAIK | |
| 18:04:48 | mriedem | it's probably time to deprecate rxtx_factor in our flavor api | |
| 18:04:59 | mriedem | and say if you need qos on ports, get it from neutron | |
| 18:05:09 | johnthetubaguy | mriedem: +1 that | |
| 18:05:42 | mriedem | sdague: jaypipes: dansmith: let's remember to put something in the onboarding session about "if you don't know why it's in nova, or what uses/used it, it's probably something to enable out of tree things for rackspace" | |
| 18:05:49 | mriedem | i need constant reminding of that | |
| 18:06:01 | sean-k-mooney | mriedem: ah look at https://docs.openstack.org/admin-guide/compute-flavors.html "this parameter is only available for Xen or NSX based systems." | |
| 18:06:39 | mriedem | sean-k-mooney: ha | |
| 18:06:41 | mriedem | nsx | |
| 18:06:46 | mriedem | the vmware driver doesn't use it | |
| 18:07:07 | mriedem | we should probably update the admin guide to basically say don't use that | |
| 18:07:29 | sean-k-mooney | mriedem: if you try to use that with nutons bandwith limit qos policies you will get consusing behavior | |
| 18:07:30 | mriedem | sean-k-mooney: this is the description from our compute api-ref: "The receive / transmit factor (as a float) that will be set on ports if the network backend supports the QOS extension. Otherwise it will be ignored. It defaults to 1.0." | |
| 18:07:54 | johnthetubaguy | mriedem: so here it is: https://github.com/openstack/nova/blob/cbbe486cd961e7f002c6e9ebdfdfa10527aa6b03/nova/network/manager.py#L551 | |
| 18:08:07 | mriedem | johnthetubaguy: yeah that's what got me to the xen driver | |
| 18:08:09 | mriedem | the rxtx_cap | |
| 18:08:13 | johnthetubaguy | yeah | |
| 18:09:11 | sean-k-mooney | is this code used only when nova networks is used? | |
| 18:09:32 | johnthetubaguy | mriedem: looks very nova-network only I think, given where that code lives. | |
| 18:10:11 | openstackgerrit | Matthew Treinish proposed openstack/nova master: Remove cloudpipe APIs https://review.openstack.org/459470 | |
| 18:10:13 | mtreinish | mriedem: ^^^ I added the missing release note | |
| 18:10:18 | sean-k-mooney | johnthetubaguy: mriedem so it can die with nova-networks in queens when cells v1 is removed | |
| 18:10:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: tests for non-shared with shared https://review.openstack.org/461899 | |
| 18:10:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901 | |
| 18:10:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900 | |
| 18:10:58 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: shared resources when finding providers https://review.openstack.org/461574 | |
| 18:11:54 | mriedem | sean-k-mooney: no it's also used here for neutron https://github.com/openstack/nova/blob/501a0fe65afabb7e6a8b1e2d1ca0fbcea941d2d1/nova/network/neutronv2/api.py#L1087 | |
| 18:12:11 | mriedem | sean-k-mooney: but as you said, having a nova flavor override your qos settings from neutron is confusing at best | |
| 18:12:15 | mriedem | broken at worst | |
| 18:12:27 | mriedem | so in queens we should deprecate that field | |
| 18:12:36 | jaypipes | dansmith: separated _get_all_with_shared() into a module-level function per your request. ^^^ | |
| 18:12:57 | sean-k-mooney | mriedem: yes its prably best to have neutron be the only source of truth when it come to network qos | |
| 18:13:18 | sean-k-mooney | mriedem: have the quots/rate limits been removed form nova yet? | |
| 18:14:13 | mriedem | sean-k-mooney: the extra specs? | |
| 18:14:15 | mriedem | probably not | |
| 18:14:40 | sean-k-mooney | yes. i think they go hand in had with the rxtx_factor removal | |
| 18:14:55 | mriedem | note there is 0 contract on extra specs really | |
| 18:15:32 | jaypipes | and edleafe, I added a fun little ASCII diagram to (probably poorly) describe the "butterfly join" ;) | |
| 18:15:46 | sean-k-mooney | yes but if is reqst a max bandwith or min in neutron nova should proably not override it | |
| 18:16:26 | mriedem | sean-k-mooney: i don't disagree | |
| 18:16:30 | cfriesen | mriedem: thanks....I am going to be at the Summit, as will Steven Webster (our actual PCI guy) | |
| 18:17:29 | cfriesen | mriedem: reason I asked about the version was that we've got a weird case where one compute node is coming up after an upgrade with version 0 instead of version 9 | |
| 18:18:26 | jaypipes | rfolco: answered your question on that error patch :) | |
| 18:18:34 | jaypipes | rfolco: thanks much for hopping on that! | |
| 18:18:41 | mriedem | cfriesen: i feel like that's something dansmith has seen before | |
| 18:18:46 | mriedem | well, rax has seen | |
| 18:19:24 | mriedem | and with that i'm out for an hour for haircutting time | |
| 18:20:37 | sean-k-mooney | mriedem: the bandwidth io extra spec discribed here https://docs.openstack.org/admin-guide/compute-flavors.html are the ones i was thinking of | |
| 18:21:47 | sean-k-mooney | mriedem_away: im pretty sure the dont always work correctly currently e.g. quota:vif_outbound_average=10 will have no effect on vhost-user and perhaps sriov also | |
| 18:22:27 | dansmith | sdague: passed again.. | |
| 18:23:53 | rfolco | jaypipes, nice. Thanks for clarifying. I first got the impression the change was impossible. Another thing that came to my attention is that previously we had in those errors what was the inventory conflicting. Now, without the DB API error, the error message is more generic. Do you see any problem there? Not sure how to get the info for inventory from DB API error. | |
| 18:25:22 | jaypipes | rfolco: not sure it's all that necessary to include the actual inventory in use. all that really matters is that there are *some* allocations for something... at that point, you can't delete the inventory at all... | |
| 18:26:19 | rfolco | jaypipes, sounds reasonable. Thank you Jay. | |
| 18:26:28 | jaypipes | any time. | |
| 18:27:16 | sean-k-mooney | jaypipes: quick question while you answering palcement api questions :) how would you feel about calls to the placement api from neutron as aprt of port binding? | |
| 18:29:12 | sean-k-mooney | i know if 2 backend right now that use vhost-user in a sligly less flexably way where the last part of the socket is used as an id to identify the port e.g. vhost-user-1 is port 1 on the backend | |
| 18:29:20 | edleafe | jaypipes: ooh, I like butterflies! | |
| 18:31:49 | sean-k-mooney | jaypipes: do you think it would be appropriate to create a resouce provider per backend to track the allocated ports via the placement api or would it be better to track the seperatly in the neutron db or something like etcd in the neutron side | |
| 18:32:44 | jaypipes | sean-k-mooney: thinking.. | |
| 18:33:28 | jaypipes | sean-k-mooney: is the "backend" something that provides a particular resource class? and if so, what is that resource class? | |
| 18:34:27 | sean-k-mooney | jaypipes: the backend is a vswitch and it proveds a limited number of acclerated port and effectivly infinity software non acclerated ports | |
| 18:35:10 | jaypipes | sean-k-mooney: would there be multiple "backends" per compute node? | |
| 18:35:45 | sean-k-mooney | jaypipes: that would depend on how the rest of the intergration was done but gernarally no | |
| 18:35:59 | sean-k-mooney | you could support multiple but i dont see a reason too | |
| 18:36:12 | jaypipes | sean-k-mooney: then why not have the "accelerated port" resources belong to the compute node resource provider? | |
| 18:37:16 | sean-k-mooney | jaypipes: you could i just was wondering if the idea of neutron caliming a resouce via the placement api so it new what numerb to use when creating the vhost user socket path would be ok | |