| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 13:54:25 | mriedem | jaypipes: huh? i can't handle 3 conversations at once plus reviews right now. | |
| 13:54:27 | sdague | mriedem: we do, but servers' don't also have a server_id field that's a 255 character string | |
| 13:54:36 | mriedem | jaypipes: i thought agreement was on required=? | |
| 13:54:42 | mriedem | since we could have preferred later | |
| 13:54:51 | jaypipes | mriedem: got it. ok, it's settled then. | |
| 13:54:59 | jaypipes | I just wanted to hold a final vote. | |
| 13:55:06 | mriedem | sdague: i don't know why flavor is the weirdo resource with a 255 char id field either | |
| 13:55:19 | sdague | mriedem: because flavor_id == server.name | |
| 13:55:25 | mriedem | but id and name are generally short things | |
| 13:55:26 | sdague | and flavor.name == server.description | |
| 13:55:42 | sdague | or, at least should be treated as such | |
| 13:56:10 | mriedem | how many clouds are filling out the full flavor.name to express everything in that field today? | |
| 13:56:18 | mriedem | including details about baremetal and extra specs | |
| 13:57:09 | sdague | mriedem: don't know, but if that's the concern I'd make the microversion start returning name as a description field instead, and make it mutable after that point | |
| 13:57:39 | mriedem | i'm not going to do that | |
| 13:57:45 | mriedem | we also embed the flavor name in the instance details now, | |
| 13:58:00 | mriedem | so if name starts becoming big ass description, then your output in things like nova show are going to bloat up | |
| 13:58:25 | sdague | mriedem: but that can already be an issue today | |
| 13:59:07 | sdague | if you put a 64 char constraint on id and name at the same time, I'd be fine with it. But I think choose your own adventure on 3 255 character fields is going to lead to more confusion | |
| 13:59:13 | efried | cdent Nice, thanks. | |
| 13:59:40 | bauzas | jaypipes: question in https://review.openstack.org/#/c/497713/10 | |
| 13:59:46 | mriedem | sdague: i don't see how it's confusing, | |
| 13:59:48 | mriedem | name is the name, | |
| 13:59:50 | mriedem | id is a uuid by default | |
| 13:59:59 | mriedem | description is a description, name and description are different things | |
| 14:00:01 | mriedem | in english | |
| 14:00:21 | bauzas | jaypipes: tl;dr say I have a host with 2 PFs, and only one tagged with a trait | |
| 14:00:29 | sdague | but your concern was also bloat because 255 characters should not be used | |
| 14:00:40 | bauzas | jaypipes: if I'm asking for 1 VF with that specific trait, I wouldn't get that host ? | |
| 14:00:45 | jaypipes | bauzas: responding on the review... | |
| 14:00:59 | bauzas | cool thanks :) | |
| 14:01:04 | sdague | so, if that's what you believe, then put a 40 character limit on flavor_id, a 64 on name, and add description as the mutable big one | |
| 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 | RP do not apply to the parent (ancestor) RPs" | |
| 14:20:12 | jaypipes | bauzas: so, your confusion stems from the sentence "However, traits defined on a child | |
| 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 | |