| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 14:01:31 | mriedem | sdague: that would be an upgrade issue for anyone that has larger values for those fields already, as a workaround | |
| 14:01:49 | bauzas | jaypipes: oh and FWIW, just discovered https://www.instagram.com/itsdougthepug/ | |
| 14:01:54 | sdague | mriedem: start with it as json schema enforcement | |
| 14:02:25 | mriedem | that might e ok | |
| 14:02:26 | mriedem | *be | |
| 14:02:47 | efried | mriedem sdague jaypipes bauzas edleafe Put me to work, guys. | |
| 14:03:02 | mriedem | review specs | |
| 14:03:20 | edleafe | efried: paint my house | |
| 14:03:23 | efried | Right right; any particular ones? (Is there a dashboard to look at? | |
| 14:03:24 | efried | ) | |
| 14:03:30 | efried | edleafe Be there in 90 minutes | |
| 14:04:21 | jaypipes | bauzas: :) on dougthepug | |
| 14:04:41 | bauzas | sorry, I'm living in the countryside | |
| 14:04:57 | sdague | mriedem: ok, well that's my current counter proposal in the spec. If we really believe people should only be doing flavor_id as uuid and name should be short, then enforce that on new types past that microversion. | |
| 14:05:01 | bauzas | so, in case that's something people know like since 2 years, :p | |
| 14:07:56 | mriedem | efried: https://goo.gl/QidAVs | |
| 14:08:01 | efried | coo | |
| 14:09:21 | bauzas | jaypipes: sorry, my question wasn't clear | |
| 14:09:28 | bauzas | jaypipes: if I'm taking your example | |
| 14:09:39 | mriedem | lyarwood: a few small things in https://review.openstack.org/#/c/490824/ to update | |
| 14:10:00 | bauzas | jaypipes: what if I'm having a node that is having 2 PFs, each of them having 8 VFs ? | |
| 14:10:20 | bauzas | jaypipes: in a nested world, I'd have a root RP (the node) and 2 chidren (the PFs) | |
| 14:11:00 | bauzas | jaypipes: then, if I'm asking for required=HW_NIC_OFFLOAD_TSO, should I get that node as a candidate? | |
| 14:11:28 | bauzas | jaypipes: because alex_xu is saying NO to this https://review.openstack.org/#/c/497713/10/specs/queens/approved/add-trait-support-in-allocation-candidates.rst@44 | |
| 14:12:07 | bauzas | jaypipes: to clarify, only *one* PF would have HW_NIC_OFFLOAD_TSO | |
| 14:12:18 | bauzas | the other PF would have other traits | |
| 14:12:41 | edleafe | jaypipes: on https://review.openstack.org/#/c/498830/9/specs/queens/approved/return-selection-objects.rst - are you saying that I should drop the limits field entirely? | |
| 14:13:22 | jaypipes | edleafe: yes, and add a numa_limits field that is a NUMATopologyLimits object. | |
| 14:13:45 | edleafe | jaypipes: ok, I'll revise | |
| 14:14:33 | jaypipes | bauzas: when you say "what if I'm having a node that is having 2 PFs" are you really saying "what if I am *requesting* an instance that has two PFs"? | |
| 14:15:24 | bauzas | jaypipes: no, that's probably where I'm unclear | |
| 14:15:25 | sdague | mriedem: does https://review.openstack.org/#/c/466595 solve cburgess's desire as well? | |
| 14:15:35 | bauzas | jaypipes: nevermind the SR-IOV language | |
| 14:15:50 | bauzas | and keep things simple : one root RP and 2 children RPs | |
| 14:15:51 | efried | bauzas jaypipes If I'm understanding the algorithm correctly, we'll hit the PF that has the right trait; and then look up that guy's root_provider_id to include in the result set. | |
| 14:16:04 | mriedem | sdague: that is the exact same spec/blueprint we've shot down numerous times, | |
| 14:16:12 | mriedem | which i commented on back in may | |
| 14:16:14 | efried | So we don't even consider the child PF RP that lacks the trait in question. | |
| 14:16:38 | bauzas | jaypipes: each of those children RPs would have an inventory of 'foo': 8 | |
| 14:16:42 | efried | mriedem Paperwork question: I don't see esberglu's https://review.openstack.org/#/c/503061/ in that dashboard. (Expected to see it under "needs final +2") | |
| 14:16:57 | bauzas | jaypipes: but only one would have a trait 'MISC_FOO' | |
| 14:17:20 | jaypipes | bauzas: k | |
| 14:17:36 | bauzas | jaypipes: my question is, if I'm asking in my query for resources=FOO:1&required=MISC_FOO, could I get that node ? | |
| 14:17:43 | jaypipes | bauzas: yes | |
| 14:18:03 | jaypipes | bauzas: Alex is talking about *aggregates* on line 43-44. | |
| 14:18:10 | mriedem | sdague: -1ed again | |
| 14:18:11 | sdague | mriedem: sure, but if there really are a bunch of different operators that are all coming forward with "please we need this" it would be good to figure out who they are all | |
| 14:18:26 | jaypipes | bauzas: he's being explicit that aggregates don't have traits associated with them. only RPs do. | |
| 14:18:36 | bauzas | ah, shiy | |
| 14:18:38 | bauzas | shit | |
| 14:18:57 | mriedem | sdague: don't know who they all are now, at one point i found the various proposals and blueprints for this, and ML threads, | |
| 14:19:02 | mriedem | that could be collected, but i'm not going to do it today, | |
| 14:19:11 | jaypipes | bauzas: ah, hold up, I see now where your confusion lies | |
| 14:19:16 | mriedem | it could probably be better served as a user survey question, but i do'nt really want to tie us to the response | |
| 14:19:28 | sdague | mriedem: right, that's fair, not actually asking you to do it | |
| 14:19:35 | jaypipes | bauzas: one sec. | |
| 14:19:36 | mriedem | we've said, since boston, | |
| 14:19:38 | efried | jaypipes bauzas Yeah, from that point of view, the traits *do* in fact propagate upwards. | |
| 14:19:44 | efried | sort of | |
| 14:19:46 | sdague | but cburgess might be the right volunteer for that activity | |
| 14:19:56 | sdague | given his interest | |
| 14:20:08 | mriedem | implement the cinder ephemeral backend and you can pass the volume type through extra specs - but that doesn't really pertain to non-ephemeral volumes we create on behalf of the user | |
| 14:20:12 | jaypipes | bauzas: so, your confusion stems from the sentence "However, traits defined on a child | |
| 14:20:12 | jaypipes | RP do not apply to the parent (ancestor) RPs" | |
| 14:20:22 | bauzas | exactly | |
| 14:20:29 | jaypipes | bauzas: what he's saying is correct, but weird :) | |
| 14:20:30 | bauzas | it doesn't bubble up | |
| 14:20:48 | bauzas | so I just want to make sure we walk in the tree | |
| 14:20:57 | efried | jaypipes bauzas I take that to mean: if the parent RP has *inventory*, you wouldn't get that *inventory* | |
| 14:21:13 | efried | It would be weird (but not forbidden) for a parent to have inventory in the same resource class as its child. | |
| 14:21:21 | jaypipes | bauzas: the trait itself doesn't apply to the parent specifically, but when looking for providers to return in allocation candidates, any traits for any provider in a *tree* will be considered as being "traits of the tree" | |
| 14:21:22 | efried | That's the case where the traits don't propagate upwards. | |
| 14:22:49 | bauzas | well, I'd say I would easily imagine the same resources:FOO:9&required=MISC_FOO not getting the node if only the child is having 8 FOOs per child | |
| 14:22:56 | mriedem | stephenfin: this has been around for a month without any patches https://bugs.launchpad.net/nova/+bug/1714017 | |
| 14:22:57 | openstack | Launchpad bug 1714017 in OpenStack Compute (nova) "User guide was not migrated to the nova repo" [Medium,In progress] - Assigned to Pavlukhin Max (mpavlukhin) | |
| 14:23:06 | mriedem | stephenfin: so if you're keen maybe you want to take that over, | |
| 14:23:06 | jaypipes | bauzas: that is correct. | |
| 14:23:15 | jaypipes | bauzas: quantitatively it's not possible. | |
| 14:23:16 | mriedem | stephenfin: keeping in mind we need to backport whatever the changes are | |
| 14:23:29 | mriedem | so maybe step 1 is just import the user guide docs and backport, then step 2 is re-arrange and clean them up | |
| 14:23:36 | mriedem | since some of the config drive user guide docs are really for admins | |
| 14:23:44 | bauzas | jaypipes: but I had the same concern without traits, say I have 2 children with each of them having 8 FOOs | |
| 14:23:46 | jaypipes | bauzas: but remember that the max_unit/min_unit part of hte inventory records will solve that query problem. | |
| 14:23:57 | stephenfin | mriedem: I was going to, but Takashi NATSUME (I don't know his IRC nick) might be on it | |
| 14:24:12 | bauzas | jaypipes: if I'm asking for 9 FOOs, I wouldn't get them even if I could have 8 in a child and 1 in the other child | |
| 14:24:14 | stephenfin | see https://bugs.launchpad.net/nova/+bug/1720873 | |
| 14:24:15 | openstack | Launchpad bug 1714017 in OpenStack Compute (nova) "duplicate for #1720873 User guide was not migrated to the nova repo" [Medium,In progress] - Assigned to Pavlukhin Max (mpavlukhin) | |
| 14:24:38 | bauzas | jaypipes: mmm, I don't see how that helps but okay :) | |
| 14:24:48 | jaypipes | bauzas: if you request 9 foo and there are 2 child providers having 8 foo inventories, each of those inventory records would have max_unit = 8 and that would mean a failing WHERE condition on max_unit <= $requested_amount | |
| 14:25:11 | bauzas | jaypipes: I certainly understand *why* it's failing | |
| 14:25:32 | bauzas | jaypipes: but I can easily imagine operators asking for spreading their resources | |
| 14:25:34 | efried | yeah, that's a bug. | |
| 14:25:34 | mriedem | stephenfin: ok | |
| 14:25:50 | stephenfin | If they haven't done anything by next week, I'll pick it up | |
| 14:26:14 | bauzas | snap, I need to disappear for my daily daddy work | |
| 14:26:24 | jaypipes | bauzas: sorry, I'm not following you still. :( | |
| 14:26:26 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Move 'ips' field from Subnet object to VIF object https://review.openstack.org/508498 | |
| 14:27:21 | jaypipes | efried: do you think bauzas is talking about the resources1=, required1= stuff we discussed at the PTG? | |
| 14:28:34 | stephenfin | jaypipes: Fancy taking a look at this some time today? https://review.openstack.org/#/c/502056/ | |
| 14:28:39 | stephenfin | (it's docs) | |