| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-11-08 | |||
| 14:58:59 | mordred | samueldmq: yes - that's right - and you're exactly right | |
| 14:59:09 | mordred | samueldmq: refstack started well after there were already many production deployments | |
| 14:59:15 | mordred | so it has to take a conservative approach | |
| 15:00:01 | samueldmq | oh well, that's a good story to be written... thanks!! | |
| 15:00:08 | mordred | sdk also started after many production deployments - so it was able to look at what reality was, and then provide an abstraction on top of that to hide differences that exist due to refstack not existing in the beginning | |
| 15:00:12 | mordred | samueldmq: \o/ | |
| 15:00:39 | samueldmq | \o/ | |
| 15:51:46 | elmiko | edleafe: i will be around here, but i have a call to listen in on at the same time. just a heads up | |
| 15:55:21 | edleafe | elmiko: dtantsur: no problem | |
| 15:55:33 | edleafe | I'll try to handle the crowds all by myself :) | |
| 16:00:07 | edleafe | The API-SIG Office Hour has officially begun. | |
| 16:01:08 | elmiko | lol | |
| 16:02:06 | edleafe | Well, we don't use #startmeeting, so I gotta write something :) | |
| 16:02:22 | elmiko | #putsfeetondesk | |
| 16:03:09 | elmiko | and i wasn't lol'ing at your announcement (i like it), i was laughing at the exchange between you and mordred =) | |
| 16:04:37 | edleafe | That mordred thinks he's so tough | |
| 16:05:01 | elmiko | indeed | |
| 16:36:50 | openstackgerrit | Ed Leafe proposed openstack/api-sig master: Add idempotent DELETE guidance https://review.openstack.org/616610 | |
| 16:36:55 | edleafe | elmiko: dtantsur: finally got around to writing this ^^ | |
| 16:37:05 | elmiko | \o/ | |
| 16:38:18 | dtantsur | w00t | |
| 17:01:05 | edleafe | wow, another busy office hour | |
| 17:02:44 | elmiko | lol | |
| 17:02:51 | elmiko | hey, you posted a PR! | |
| 17:03:59 | elmiko | edleafe: just a heads up, i won't be around next week. gonna be at a conference | |
| 17:04:21 | elmiko | although, isn't next week the forum too? | |
| 17:04:35 | edleafe | elmiko: Unfortunately, next week I *won't* be at a conference | |
| 17:04:41 | elmiko | =( | |
| 17:04:53 | elmiko | ++ | |
| 17:05:11 | elmiko | just running around all willy-nilly dropping 34B here and there XD | |
| 17:05:40 | edleafe | They just wanted to get you working for them | |
| 17:05:51 | elmiko | lol | |
| 17:20:21 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Add project param in LimitList parser https://review.openstack.org/611789 | |
| 18:07:02 | mordred | Shrews: incidentally, in writing tests for the statsd patch, I actually discovered a bug that was lurking in the existing code | |
| 18:07:10 | mordred | Shrews: also - I have tests now | |
| 18:10:36 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Collect request stats https://review.openstack.org/614834 | |
| 18:12:15 | mordred | Shrews, tobiash: ^^ it still needs docs added ... and tobiash, I'd love feedback on the metric names and labels (obviously it's not immediately useful if we don't decided to expose that directly in nodepool - but since you're using things already, I figureyou've got good context) | |
| 18:27:18 | tobiash | mordred: what is the openstack_http_requests supposed to be? | |
| 18:27:37 | mordred | tobiash: the equiv of the task counter | |
| 18:28:07 | mordred | tobiash: so what you're translating to nodepool_task now | |
| 18:28:11 | tobiash | mordred: then I think it should be a counter, not a gauge | |
| 18:28:59 | mordred | tobiash: ok - the counter docs said something about resetting on restarts - was I just understanding that wrong? | |
| 18:29:32 | mordred | tobiash: ah - I see! (found better docs) | |
| 18:29:34 | mordred | and I agre | |
| 18:29:52 | tobiash | mordred: https://prometheus.io/docs/concepts/metric_types/ | |
| 18:29:52 | mordred | and good - because I find spelling gauge very hard | |
| 18:30:09 | tobiash | that's the reference of the prometheus metric types | |
| 18:30:21 | tobiash | mordred: in statsd this is probably a counter too? | |
| 18:31:37 | mordred | tobiash: yah | |
| 18:31:44 | tobiash | gauge is not very useful for aggregating stuff, it should only be used if you are interested in the current value of something like current quota usage | |
| 18:32:07 | mordred | yah - makes sense | |
| 18:32:16 | tobiash | with counters instead you can do things like calculating rates per any time interval | |
| 18:34:39 | tobiash | mordred: I think using a histogram however is a good choice | |
| 18:34:48 | tobiash | for the timers | |
| 18:35:16 | mordred | woot! | |
| 18:36:26 | tobiash | especially if you want to aggregate and calculate quantiles of more than one series you *need* historgrams instead of summaries | |
| 18:36:50 | tobiash | some background info on that: https://prometheus.io/docs/practices/histograms/ | |
| 18:37:00 | tobiash | it's really interesting | |
| 18:38:01 | Shrews | ya know, i was thinking about stats stuff (since it seems to be all the rage this week)... we could just let folks configure the statsd keys themselves via config file (at least in nodepool). | |
| 18:39:08 | Shrews | that probably makes less sense in sdk | |
| 18:39:33 | Shrews | where there can be lots of them | |
| 18:39:46 | Shrews | bah, silly thinking | |
| 18:41:25 | Shrews | mordred: can we please not add both statsd and the prometheus stuff in a single review? | |
| 18:44:49 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Collect request stats https://review.openstack.org/614834 | |
| 18:45:19 | mordred | tobiash: updated to counter | |
| 18:45:37 | mordred | Shrews: sure - once I get the docs written, I'll split it up | |
| 18:45:53 | Shrews | mordred: actually, it's not that overly burdonsome here | |
| 18:45:58 | mordred | *phew | |
| 18:46:54 | mordred | Shrews: I tink that test file should have all the things we need to do further tests - I put in things to add the statsd and prometheus content to details on failure - cause otherwise it's like "1 doesn't match None" and you're like WTF??? | |
| 18:47:24 | mordred | Shrews: that said - the stastd fixture starts a thread - and when I added it just to the base test case I wound up hitting too many open files :) | |
| 18:47:58 | mordred | which - might be a thing we want to look in to in general, as that tells me something isn't properly getting shut down - but it only shows up when you've got a bazillion tests like we do in sdk | |
| 18:50:28 | Shrews | mordred: weird | |
| 19:04:58 | tobiash | mordred: regarding openstack_http_requests I'd even add the response code as a label | |
| 19:06:27 | kmalloc | mordred: so.. about to land some pymemcache awesomeness to oslo.cache | |
| 19:06:32 | kmalloc | mordred: erm dogpile.cache | |
| 19:06:32 | kmalloc | :) | |
| 19:07:03 | openstackgerrit | Merged openstack/python-openstackclient master: Add --name-lookup-one-by-one option to server list https://review.openstack.org/568345 | |
| 19:11:07 | openstackgerrit | Merged openstack/python-openstackclient master: Remove invalid 'unlock-volume' migration arg https://review.openstack.org/558910 | |
| 19:58:18 | mgagne | I'm currently using python-openstackclient and performing "openstack port show <UUID>" on a non-existing port. I found with --debug that if GET /v2.0/ports/<UUID> returns a 404, GET /v2.0/ports is performed instead which can be *very* costly if you happen to have a LOT of ports or are an admin. Is there anyway to improve that? | |
| 20:07:01 | kmalloc | mgagne: it would require a flag or something to not perform a list to "find" a port. this is a behavior for "get name or id" type thing that we typically do | |
| 20:07:17 | kmalloc | mgagne: it's to handle the case of passing a name instead of an id and having it magically work | |
| 20:07:42 | mgagne | kmalloc: yes, if a UUID like name is found, would it be reasonable to not perform a full list? | |
| 20:07:54 | kmalloc | so something like --id <uuid> might need to be implemented so it doesn't do an id then name | |
| 20:07:55 | mgagne | or are people crazy to name their ports with UUID? | |
| 20:07:59 | kmalloc | yes | |
| 20:08:20 | kmalloc | people name everything with uuids because operators often dynamically generate that stuff | |
| 20:08:30 | kmalloc | i see it all the time with projects/users | |
| 20:08:41 | kmalloc | ID is UUID X, name is UUID Y | |
| 20:08:55 | mgagne | so you have port.id != port.name but both are UUIDs? crazy stuff | |
| 20:08:57 | kmalloc | i wouldn't be surprised in ports or servers or anything | |
| 20:09:06 | kmalloc | welcome to insanity | |
| 20:09:16 | kmalloc | it's unfortuantely the norm | |
| 20:09:21 | mgagne | can we have OS_INSANE=0 then? :D | |
| 20:10:05 | kmalloc | and throw a warning "hey, the get_name_or_id functionality is going away" | |
| 20:10:16 | kmalloc | but i don't have a lot of say in that part | |
| 20:10:51 | mgagne | ok, at least I got an explanation | |
| 20:11:40 | kmalloc | that is a guess fwiw | |
| 20:11:43 | kmalloc | i didn't look at the code | |
| 20:11:49 | kmalloc | but it sure sounds like what we do elsewhere | |
| 20:12:56 | mgagne | yea... I'm sure it's nothing like that because it uses find_port which I guess support both id and name at the same time. | |