| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-30 | |||
| 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 | |
| 01:47:43 | bkero- | then korea | |
| 01:48:07 | mriedem | efried: looks like the nrp series has a merge conflict starting here now https://review.openstack.org/#/c/521098/30 | |
| 01:48:35 | Spazmotic | Haha I tried.. something about not having a presence in South Korea so they cannot have a remote worker there or something | |
| 01:48:50 | bkero- | Yeah, it's hard to ask for permission | |
| 01:49:04 | mriedem | australia | |
| 01:49:07 | mriedem | rax is there | |
| 01:49:12 | mriedem | then at least the tz is closer | |
| 01:49:17 | Spazmotic | Well also HKG | |
| 01:49:21 | Spazmotic | But we are settling for bringing her here | |
| 01:49:24 | Spazmotic | Just waiting on VISA stuff | |
| 01:49:28 | mriedem | don't tell trump | |
| 01:49:30 | Spazmotic | dunno why i thought that was an anagram | |
| 01:49:31 | Spazmotic | it's early | |
| 01:49:43 | Spazmotic | Yeah it's totes hush hush, just letting you openstack fellows know.. DON'T TELL TRUMP | |
| 01:50:14 | mriedem | he'd actually be in bed eating by now if it weren't for some speech he has to give tonight | |
| 01:51:17 | Spazmotic | I'd imagine he's still doing that thing | |
| 01:51:25 | Spazmotic | Just speech from bed with giant slippers | |
| 01:51:33 | Spazmotic | Glow of his own TV show shining on his face or something, and some chicken in a bucket. | |
| 01:51:48 | Spazmotic | Swinging a drumstick around | |
| 01:56:36 | mriedem | alex_xu: looks like your allocation candidates + traits gabbi tests are intermittently failing http://logs.openstack.org/10/539310/1/check/nova-tox-functional/a6ba562/job-output.txt.gz#_2018-01-30_21_02_40_414709 | |
| 02:00:22 | mriedem | https://bugs.launchpad.net/nova/+bug/1746388 | |
| 02:00:23 | openstack | Launchpad bug 1746388 in OpenStack Compute (nova) "allocation candidates with invalid traits negative functional tests are intermittently failing" [High,Confirmed] | |
| 02:01:15 | mriedem | alex_xu: ah nevermind efried found the issue https://review.openstack.org/#/c/537351/3/nova/api/openstack/placement/util.py | |
| 02:50:12 | openstackgerrit | Hironori Shiina proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487 | |
| 02:58:30 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add unit tests for EmulatorThreadsTestCase https://review.openstack.org/538699 | |
| 02:58:31 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Not use thread alloc policy for emulator thread https://review.openstack.org/538700 | |