| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-30 | |||
| 22:40:38 | efried | edleafe: Because without it, we *have* to do that re-GET in order to glean the new generation. | |
| 22:40:46 | efried | (again, unless assumptions) | |
| 22:41:00 | edleafe | efried: Oh, you're still pretending that we don't know how generations work | |
| 22:41:04 | efried | Correct. | |
| 22:41:08 | edleafe | The name itself should be a giveaway | |
| 22:41:21 | efried | say wha? | |
| 22:41:33 | efried | Please tell me you're joking | |
| 22:41:40 | edleafe | no, I'm not | |
| 22:42:14 | efried | We're not going to assume API behavior based on the dictionary definition of an ambiguous English word with lots of synonyms. | |
| 22:42:35 | efried | even if any one of those definitions said "and we start at 0, and the next one is +1" - which they don't. | |
| 22:43:19 | edleafe | We adopted generations over other candidates, such as etags, precisely because we *could* make these assumptions | |
| 22:43:36 | edleafe | I understand that we have not documented that behavior well enough for outsiders | |
| 22:43:47 | efried | Or insiders, apparently. I think I qualify. | |
| 22:43:51 | edleafe | But within the placement dev team, it was clear | |
| 22:44:06 | edleafe | were you in the discussions about what to use? | |
| 22:44:32 | efried | Oh, by "outsiders" did you mean whoever wasn't in the design discussion? | |
| 22:44:40 | edleafe | yes | |
| 22:44:51 | efried | I thought you meant people who aren't developers of the placement API. | |
| 22:45:15 | edleafe | well, you have seemed to pick up on the way it works :_ | |
| 22:45:50 | efried | Yes, and I vociferously contend that we have not documented that behavior well enough. | |
| 22:46:04 | edleafe | and I will vociferously agree with that | |
| 22:46:14 | efried | In any case, based on last week's straw poll, I don't think there's consensus even among people who were in the room when it was designed. | |
| 22:46:32 | efried | ...as to whether the behavior should be an explicit, documented part of the API. | |
| 22:46:34 | edleafe | some of us weren't happy with the choice :( | |
| 22:46:38 | mriedem | you guys are talking about a decision made a couple of years ago right? | |
| 22:46:50 | mriedem | in a kind of 'shit or get off the pot' situation? | |
| 22:46:54 | edleafe | mriedem: well, about a year or so I think | |
| 22:47:04 | mriedem | not knowing what we'd be doing with these things several releases later | |
| 22:47:19 | efried | mriedem: We're not even arguing the decision to implement generation a certain way. I don't think anyone has a problem with that. | |
| 22:47:26 | edleafe | there was the opaque marker (etag) proponents, and the deterministic marker (generation) camp | |
| 22:47:28 | mriedem | a year would have been the ATL PTG and it seems older than that, at least BCN | |
| 22:48:07 | mriedem | so next step is....documenting how generations work | |
| 22:48:08 | mriedem | ? | |
| 22:48:29 | efried | mriedem: Yeah - what's at issue is whether that implementation is supposed to be known by consumers of the API, or whether it's supposed to be opaque. | |
| 22:49:13 | mriedem | sorry, i haven't followed this debate the last several times it's come up, but what's the issue? that a client can get a generation that skips increments? | |
| 22:49:21 | mriedem | like t1 i get gen 1, t2 i get gen 3? | |
| 22:50:22 | efried | Not really. The issue is, can the consumer count on a) generation starts at 0 when you create a new provider; and b) generation increments by 1 when you successfully update something associated with a provider. | |
| 22:51:06 | efried | Point being, as currently implemented, yes they can, but do we want that to be explicitly part of the API, or do we want it to be opaque and you shouldn't introspect the generation? | |
| 22:52:14 | edleafe | mriedem: IOW, do we want to require that each call to modify a RP is first preceded by a GET to find the current generation? | |
| 22:52:24 | efried | no, not at all. | |
| 22:52:34 | efried | that would not be necessary at all. | |
| 22:52:59 | mriedem | if the generation the caller passes is in conflict, they get a 409, get the latest generation, merge the request and try again | |
| 22:53:17 | mriedem | why would the caller need to know that the generation increments by 1? | |
| 22:53:29 | edleafe | efried: how can they pass a generation if they can't assume previous+1? | |
| 22:54:01 | mriedem | efried: fwiw i think "can the consumer count on a) generation starts at 0 when you create a new provider; and b) generation increments by 1 when you successfully update something associated with a provider." is fine | |
| 22:54:04 | efried | edleafe: Because the response from any update includes the new generation. Since the update was atomic, you know that the payload in the response corresponds to that generation. | |
| 22:54:41 | efried | And I can keep my cache consistent with that information. | |
| 22:55:38 | efried | And the problem arises any time there's an update from whose response I can't glean the new generation. Like DELETE inventory, allocations, traits (and someday maybe aggregates) | |
| 22:56:08 | efried | mriedem: Duly noted. I think your vote splits us clean down the middle. | |
| 22:56:59 | mriedem | consider it a very limp vote | |
| 22:57:09 | efried | If I'm remembering right, we have mriedem cdent edleafe on one side, and efried dansmith jaypipes on the other. | |
| 22:57:44 | mriedem | well, i also agree that "you shouldn't introspect the generation" | |
| 22:57:48 | edleafe | and IIRC, it was jaypipes advocating for the gen+1 back in the day | |
| 22:58:03 | mriedem | like i said above, as a client, try the request, if it fails, fetch the latest thing, merge the result client side and try again | |
| 22:58:16 | edleafe | for the very reason that you *could* assume those things | |
| 22:58:28 | efried | edleafe: Not to put words in his mouth, but he may have been advocating the monotonic integer implementation without advocating that that implementation be transparent to the API consumer. | |
| 22:58:54 | edleafe | efried: that would have no advantage over something like etag | |
| 22:59:01 | mriedem | i sure hope this is blocking the most important thing that anyone is ever going to be working on...because it sures feels like it | |
| 22:59:09 | edleafe | it was that advantage that was the main argument | |
| 23:00:15 | edleafe | mriedem: it's just that we went through this a while ago, and now it's being dragged up again for the very reason it was chosen in the first place | |
| 23:01:55 | mriedem | fair | |
| 23:01:57 | mriedem | but, | |
| 23:02:02 | mriedem | it's 5:02 and i'm out of here suckas | |
| 23:02:08 | efried | later mriedem | |
| 23:02:15 | openstackgerrit | Merged openstack/nova master: Cleanup redundant want_version assignment. https://review.openstack.org/535801 | |
| 23:02:25 | openstackgerrit | Merged openstack/nova master: Add debug output for selected page size https://review.openstack.org/530662 | |
| 23:02:36 | openstackgerrit | Merged openstack/nova master: api-ref: Fix parameter type in server-migrations.inc https://review.openstack.org/536293 | |
| 23:03:04 | efried | edleafe, if the decision was made definitively after lots of discussion, how is it that there's such contention now, even among folks who were apparently part of the decision? | |
| 23:03:54 | efried | I would have expected those people to grumble about how it wasn't what they would have chosen, but it's what we decided on, and we'd have a path forward. | |
| 23:05:15 | edleafe | efried: that's hard for me to understand. Both cdent and I were arguing for etags, and now we're both saying "well, we got monotonically increasing integers, so let's use 'em!" | |
| 23:05:43 | efried | And the folks who argued for monotonic ints are saying they should be opaque? | |
| 23:06:02 | edleafe | weird, huh? | |
| 23:06:11 | efried | fkinaye | |
| 23:06:39 | openstackgerrit | Merged openstack/nova master: Merge server create schema for availability zone extension https://review.openstack.org/451331 | |
| 23:06:49 | openstackgerrit | Merged openstack/nova master: Merge server create for availability zone extension https://review.openstack.org/502574 | |
| 23:07:02 | openstackgerrit | Merged openstack/nova master: [placement] Add functional tests for resource class API https://review.openstack.org/524506 | |
| #openstack-nova - 2018-01-31 | |||
| 00:29:36 | openstackgerrit | Merged openstack/nova master: [placement] Add sending global request ID in delete (3) https://review.openstack.org/526557 | |
| 00:29:56 | openstackgerrit | Merged openstack/nova master: Avoid suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 00:32:28 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform live_migration_post_dest notification https://review.openstack.org/469784 | |
| 00:36:51 | openstackgerrit | Merged openstack/nova master: Handle TZ change in iso8601 >=0.1.12 https://review.openstack.org/535700 | |
| 00:44:27 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] Separate API schemas (resource_provider) https://review.openstack.org/528629 | |
| 00:45:46 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove unnecessary arguments in notification methods https://review.openstack.org/535599 | |
| 01:03:28 | openstackgerrit | Nakanishi Tomotaka proposed openstack/nova master: Use Placement API to check resource usage https://review.openstack.org/528953 | |
| 01:13:05 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Invalid query parameter could lead to HTTP 500 https://review.openstack.org/539164 | |
| 01:35:49 | mriedem_afk | woot vgpu patch finally merged https://review.openstack.org/#/c/535693/ | |
| 01:37:22 | mriedem_afk | alex_xu: want to hit this release note for versioned notification transformation for queens? https://review.openstack.org/#/c/518018/ | |
| 01:42:45 | Spazmotic | how are you awake even more than me | |
| 01:43:03 | mriedem | it's 7:45 | |
| 01:43:12 | Spazmotic | ..so it is | |
| 01:43:21 | Spazmotic | sorry.. third shift.. sometimes my hours don't make sense | |
| 01:43:25 | mriedem | exercise, vegetables and clean living | |
| 01:44:26 | Spazmotic | That's my lifestyle as well the past year.. I respect it:) | |
| 01:45:20 | Spazmotic | Nowadays I use my Racker picture on my badge as inspiration.. have lost 170lbs. But still.. Third Shift hours and having a fiancee in Korea make my hours ridiculous hehe | |
| 01:46:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288 | |
| 01:46:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532290 | |
| 01:46:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 01:46:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional tests for virt driver get_traits() method https://review.openstack.org/538047 | |
| 01:46:12 | bkero- | That's a crazy schedule. That must have very little overlap. | |
| 01:46:58 | Spazmotic | It could be worse.. The good thing is that Korea daytime and third shift US are pretty lined up, but right now outside of DST the time diff is a little mor difficult. | |
| 01:47:38 | bkero- | gotta get those remote working privs | |