| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-11-08 | |||
| 14:36:52 | samueldmq | mordred: but that's what refstack does, correct? | |
| 14:37:22 | samueldmq | you mean optimistic because I am putting so much of the glory in sdk I guess | |
| 14:50:35 | mordred | samueldmq: no - I mean optimistic about RefStack :) | |
| 14:50:49 | samueldmq | mordred: oh | |
| 14:51:35 | mordred | samueldmq: but I think what you're saying is the intent - and my pessimistic side just sees the bugs | |
| 14:51:37 | samueldmq | what does it do in practice? just run tempest tests against clouds and reports results? | |
| 14:52:00 | samueldmq | mordred: bugs.. for example? I need to know more downsides of it | |
| 14:52:12 | mordred | samueldmq: so you could say all of the above, but then also that sdk's abstraciton layer does what you say it does - and also works around bugs/holes in the interoperability that refstack aims to provide | |
| 14:52:47 | mordred | samueldmq: well - places where refstack doesn't have a story for something yet - or where people can't agree that a given feature should be covered by refstack certification | |
| 14:53:30 | mordred | samueldmq: at the sdk level we can provide a consistency quickly - while aligning different operating clouds might take a bit longer | |
| 14:54:04 | samueldmq | hmmm | |
| 14:54:12 | samueldmq | so refstack's intent was to standardize? | |
| 14:54:15 | samueldmq | is* | |
| 14:55:49 | samueldmq | mordred: that's very interesting... standardizing things that are already alive don't work well. literature and experience shows that | |
| 14:56:07 | samueldmq | also - standards translates into cutting some use cases, and flexibility :-) | |
| 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 | |