| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-01 | |||
| 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 | |
| 15:56:12 | jgwentworth | bpoulos: just fyi cert validation is back in a review runway, so be on the lookout for reviews https://etherpad.openstack.org/p/nova-runways-rocky | |
| 15:58:01 | mnaser | jgwentworth: superdan SpamapS thanks for the input | |
| 16:02:21 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: libvirt: handle DiskNotFound during update_available_resource https://review.openstack.org/571432 | |
| 16:02:22 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ocata: libvirt: Skip fetching the virtual size of block devices https://review.openstack.org/571433 | |
| 16:03:44 | superdan | mnaser: since you're around, and since you do upgrades a lot, let me ask... | |
| 16:04:03 | mnaser | i'm always around :p what's up? | |
| 16:04:24 | superdan | mnaser: when you do an upgrade from say pike to queens, do you move everything off of every compute node before you do anything to that node, or do you just stop compute services, upgrade packages, and then re-start services? | |
| 16:04:58 | mnaser | we have the ability to live migrate everything because of ceph, but i've never needed to do that, my thought process is -- services are control plane and they don't affect vms | |
| 16:05:04 | mnaser | so it's always been in place upgrades | |
| 16:05:13 | superdan | mnaser: right okay, that's what I'd expect | |