| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-01 | |||
| 15:15:54 | superdan | or maybe leakypipes does | |
| 15:16:04 | superdan | hence my "I thought" hedging | |
| 15:18:04 | leakypipes | superdan: unfortunately, I don't remember much about that decision either, sorry :( | |
| 15:20:47 | hansmoleman | i don't either | |
| 15:20:56 | hansmoleman | sdague likely might, but | |
| 15:21:01 | superdan | yeah | |
| 15:21:07 | hansmoleman | or alex or ken'ichi | |
| 15:21:16 | hansmoleman | or gmann | |
| 15:21:18 | superdan | am I remembering correctly that we made a point of not allowing unicode there though? | |
| 15:22:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847 | |
| 15:22:21 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 15:22:23 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 15:22:45 | superdan | or do ya'll not remember one way or the other? | |
| 15:23:14 | hansmoleman | i don't really remember | |
| 15:23:31 | hansmoleman | could have been related to how we stored that stuff in the db, but not sure | |
| 15:24:07 | hansmoleman | i'm not sure why we'd have unicode in flavor extra specs, | |
| 15:24:14 | hansmoleman | those are system-defined things that the code needs to understand | |
| 15:24:34 | hansmoleman | user metadata is fuzzy | |
| 15:25:00 | hansmoleman | auggy had a spec related to this also i think... | |
| 15:25:06 | hansmoleman | maybe that was just case sensitivity in the db | |
| 15:26:23 | hansmoleman | https://review.openstack.org/#/c/350843/ | |
| 15:26:26 | hansmoleman | that was case, not unicode | |
| 15:26:59 | hansmoleman | smcginnis: does cinder allow unicode in volume type extra specs? | |
| 15:27:02 | hansmoleman | or volume metadata? | |
| 15:27:37 | smcginnis | hansmoleman: Hmm, I believe the values but not the keys that are set in the extra specs. | |
| 15:27:53 | smcginnis | hansmoleman: And I believe it is fine the the volume metadata. | |
| 15:29:27 | hansmoleman | are you sure? https://github.com/openstack/cinder/blob/master/cinder/api/validation/parameter_types.py#L147 | |
| 15:29:29 | hansmoleman | doesn't look like it does | |
| 15:29:52 | hansmoleman | https://github.com/openstack/cinder/blob/master/cinder/api/schemas/volume_metadata.py#L35 | |
| 15:29:53 | fried_rice | hansmoleman: The *key* doesn't, but the *value* does. | |
| 15:30:16 | hansmoleman | oh right yeah | |
| 15:30:22 | hansmoleman | just a 255 character string | |
| 15:30:36 | fried_rice | okay, so cinder is using the same regex as nova for the key. | |
| 15:31:38 | fried_rice | I don't have a sense of how these things get sprayed around in a real deploy. Does this mean that we can't have one of those regexes be a superset of the other, because chars outside the smaller set would then break when they cross that boundary? | |
| 15:31:43 | hansmoleman | for extra specs, i would ask which specific flavor extra specs do they need unicode values | |
| 15:31:49 | hansmoleman | or is it just out of tree enablement | |
| 15:31:54 | hansmoleman | if it's the latter, then i care much less about this | |
| 15:32:34 | jgwentworth | fwiw I don't remember any discussion about unicode metadata keys | |
| 15:32:39 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Refactor _build_device_metadata https://review.openstack.org/533804 | |
| 15:32:40 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Consider hostdev devices when building metadata https://review.openstack.org/533805 | |
| 15:33:34 | superdan | for extra_specs I think the case to be made is super weak regardless of what they way | |
| 15:33:42 | ralphlauren | finucannot, ^^^ if you want to re-review | |
| 15:33:44 | superdan | for metadata I can imagine more realistic scenarios | |
| 15:34:02 | jgwentworth | it makes sense to me that someone might want that, to be able to set keys/names in their own language | |
| 15:34:33 | jgwentworth | but yeah, not sure if there's some other gotcha that we'd hit somewhere by changing it to allow unicode | |
| 15:34:35 | fried_rice | superdan: The bug isn't real specific about why they want it. But jgwentworth yeah, that. | |
| 15:35:13 | superdan | not sure how we signal it appropriately either.. a microversion will be frustrating as older ones would have to just omit pairs that use unicode | |
| 15:35:15 | hansmoleman | fried_rice: likely because they have out of tree code that's busted | |
| 15:35:20 | superdan | yup | |
| 15:35:29 | hansmoleman | so i'd nack until they can give specifics | |
| 15:36:24 | fried_rice | Roger wilco. | |
| 15:36:27 | fried_rice | thanks guys | |
| 15:37:03 | hansmoleman | i'd be willing to bet Kevin_Zheng knows if we (huawei) have a need for this | |
| 15:37:37 | hansmoleman | like, maybe i need to get my chinese unicode name passed through user metadata to config drive for something running in the image | |
| 15:37:47 | hansmoleman | to register with some internal system | |
| 15:37:48 | hansmoleman | idk | |
| 15:39:36 | PapaOurs | silly question but... does cloud-init support unicode ? | |
| 15:42:38 | hansmoleman | https://cloudinit.readthedocs.io/en/latest/search.html?q=unicode&check_keywords=yes&area=default | |
| 15:42:43 | hansmoleman | the answer is, shrug | |
| 15:43:25 | fried_rice | Marked Incomplete asking for details: https://bugs.launchpad.net/nova/+bug/1737711 | |
| 15:43:27 | SpamapS | PapaOurs: it should, if it doesn't that's a bug. | |
| 15:43:27 | openstack | Launchpad bug 1737711 in OpenStack Compute (nova) "nova boot failed when use the chinese metadata key and value" [Undecided,Incomplete] - Assigned to wanghongtao (hongtao.wang) | |
| 15:44:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Restrict CONF.quota.driver to DB and noop quota drivers https://review.openstack.org/410996 | |
| 15:45:10 | hansmoleman | finucannot: i made that release note update you wanted ^ if you want to just fast approve | |
| 15:46:20 | finucannot | hansmoleman: Done and done | |
| 15:46:23 | hansmoleman | thanks | |
| 15:46:44 | mnaser | so wild Friday cells v2 question: how much does latency affect operations overall? | |
| 15:47:09 | superdan | mnaser: latency to the cell db? no more or less than with one cell | |
| 15:47:40 | mnaser | superdan: well, say you have your api in NA and a cell in .. say.. thailand. | |
| 15:48:02 | superdan | mnaser: that's probably not the best plan | |
| 15:48:17 | mnaser | (nfv use case, and company has world wide presence, so i suggested 4 regions with a single cell split geographically) | |
| 15:48:26 | mnaser | but i was thrown "cells v2" at me | |
| 15:48:40 | SpamapS | mnaser: you'll always get the latency of the slowest round trip from api->cellbits .. so it will suffer as much as your latency varies | |
| 15:48:47 | jgwentworth | mnaser: the api connects directly to cell databases, so that scenario would be slow | |
| 15:48:51 | superdan | mnaser: if unified control plane is what you care about the most, then... | |
| 15:48:54 | superdan | SpamapS: that's not true | |
| 15:49:20 | mnaser | so the thing is, api operations isn't a big deal for them, but i don't know how much slower they'd be | |
| 15:49:32 | jgwentworth | superdan: I think he means for a scatter-gather, yeah? | |
| 15:49:38 | mnaser | aka if the value of having a unified control plane is enough to take that performance hit | |
| 15:49:39 | SpamapS | Well, worst latency that has instances in the project you're listing I suppose | |
| 15:49:40 | superdan | SpamapS: if you spread things evenly across cells then it will, but if you have a tenant per cell (as one example) then you'll get normal performance if you're not in one of theother cells | |
| 15:50:00 | superdan | jgwentworth: yes | |
| 15:50:40 | superdan | mnaser: right, so relatively static workload, they just want a unified view of it, even if operations take a while, because they're infrequentish? | |
| 15:50:48 | SpamapS | I didn't mean to say all operations will suffer that much | |
| 15:50:55 | mnaser | superdan: according to them, correct | |
| 15:51:27 | superdan | mnaser: yeah, so if that's the preference, that's cool. we're not as good as we should be on tolerating faults in the remote links right now, | |
| 15:51:41 | superdan | mnaser: which means you're increasing your chances for things not working if one link is down, but that's on the books to improve | |
| 15:52:01 | mnaser | i guess that's for them to understand as a limitation if we do take this path | |
| 15:52:04 | mnaser | maybe good feedback to bring back :p | |
| 15:52:21 | superdan | at least the story is on the path to improve, but yeah | |
| 15:52:55 | mnaser | i'm suggesting 4 regions instead (na-east, na-west, europe, asia).. sure its not a unified control plane but still a lot better in terms of surprises we'll run into | |
| 15:53:11 | superdan | yep, that's a better approach if they can tolerate it | |
| 15:54:18 | hansmoleman | there are projects meant to abstract the multi-region thing https://wiki.openstack.org/wiki/Kingbird | |
| 15:54:22 | hansmoleman | but no idea how good those are | |
| 15:54:29 | SpamapS | mnaser: those are the 4 regions we have, and we do not have a unified control plane. It's nice that they're isolated from eachother. | |
| 15:54:32 | mnaser | yeah i've heard of kingbird before but it's a bit scary as a concept :p | |
| 15:54:40 | SpamapS | The only thing they share is LDAP. | |
| 15:55:00 | mnaser | yeah, i was thinking share a single keystone, multiple regions in the catalog | |
| 15:55:31 | mnaser | if this works out, hopefully we can share the story, what they're doing with nova is really, really cool. | |
| 15:56:11 | hansmoleman | that would be great | |