Thursday, 2018-10-04

openstackgerritSundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification.  https://review.openstack.org/60395500:46
*** tetsuro has joined #openstack-placement01:05
*** tetsuro has quit IRC01:41
*** tetsuro has joined #openstack-placement01:41
*** tetsuro has quit IRC01:51
*** takashin has quit IRC01:52
*** tetsuro has joined #openstack-placement01:55
*** tetsuro has quit IRC02:01
*** tetsuro has joined #openstack-placement02:03
*** takashin has joined #openstack-placement02:36
openstackgerritSundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification.  https://review.openstack.org/60395503:09
*** takashin has quit IRC03:30
*** takashin has joined #openstack-placement03:55
*** tetsuro has quit IRC04:06
*** tetsuro has joined #openstack-placement05:14
*** ttsiouts has joined #openstack-placement06:59
*** ttsiouts has quit IRC07:16
*** helenafm has joined #openstack-placement07:26
*** ttsiouts has joined #openstack-placement08:00
*** tssurya has joined #openstack-placement08:03
*** e0ne has joined #openstack-placement08:42
*** ttsiouts has quit IRC08:49
*** ttsiouts has joined #openstack-placement08:59
*** ttsiouts has quit IRC09:04
*** ttsiouts has joined #openstack-placement09:08
*** s10 has joined #openstack-placement09:26
*** ttsiouts has quit IRC10:21
*** ttsiouts has joined #openstack-placement10:31
*** cdent has joined #openstack-placement11:14
*** ttsiouts has quit IRC11:32
*** tetsuro has quit IRC12:04
*** ttsiouts has joined #openstack-placement12:07
jaypipescdent: quick question on this: <<: *cn1_zero12:14
jaypipescdent: can that go in the first line of a YAML node?12:14
cdentjaypipes: aye aye?12:14
jaypipescdent: that makes the node inherit from an anchor, right?12:14
cdentyeah, i've changed it in the latest version12:15
jaypipescdent: ah, yes, I see you have.12:15
jaypipescdent: question answered then :)12:15
jaypipescdent: back to your regularly scheduled programming :)12:16
cdenthigh latency grenade development12:16
*** tetsuro has joined #openstack-placement13:25
cdentone more bug, one more tweak, one more wait13:44
efriedgibi (and jaypipes): Consumer generations aren't returned in GET /a_c, right? Because how could they be?13:53
gibiefried: right13:53
efriedWhich means that in the scheduler flow, we actually have to *add* a consumer generation field to the allocation request we pull out of the GET /a_c return13:54
cdentyes13:54
efriedWhich means we're no longer in the happy place where that payload is opaque13:54
cdentwe were already there13:54
cdentbecause we also add a project id and user id13:54
efriedLike, we knew we had to introspect for weighers and late filters13:54
efriedoh, that wasn't there before either, yeah that makes sense.13:55
efriedThough I guess if we ever implement quotas we'll probably send proj/user in the GET /a_c request and it could be returned...13:55
gibifor the scheduler perspective every claim is a new consumer (except non-forced evacuate :/)13:55
efriedOkay, so I guess the line has moved, but we're still able to say that the "allocations" member of the allocation request is opaque13:56
gibiefried: yes, that is not touched (except evacuate)13:56
efriedYeah, gibi, so to that point, I assume we're eventually going to move toward evacuate also using migration UUID?13:57
gibiefried: I have a todo from the PTG to do that move13:57
efriedAnd we haven't yet because, what, it was too hairy of a problem to deal with when we did live migrations?13:57
efriedSo at that point, *every* PUT /allocations/{c} coming from a GET /a_c response ought to have consumer_generation=None?13:57
gibiefried: let me double-check13:58
gibiefried: if you mean claim_resources instead of PUT allocations/{c} then I think it is true13:58
efriedso like, I'm wondering if it makes sense for GET /a_c to include "consumer_generation": null in the response.13:59
efriedAnd as soon as I say it, I realize the answer is no13:59
efriedbut13:59
efriedif we had an actual consumer endpoint13:59
efriedthen we would have an operation PUT /allocations where the consumer (with proj/user IDs and generation, I think) was part of the payload, not a UUID in the URI.14:00
efriedThis may be what jaypipes has been getting at.14:00
efriedand then the GET /a_c response unit *could* be truly opaque.14:01
efried(except for some cases of weighers and late filters, maybe, not sure)14:01
gibiefried: but we have https://developer.openstack.org/api-ref/placement/#manage-allocations14:01
gibiefried: there the consumer is in the payload14:01
efriedgibi: Yeah, I think I'm saying that would be kind of restructured14:02
cdentI kind of prefer it that a GET /a_c is not "user" aware14:02
cdentat least until it is absolutely necessary for it to be so14:02
efriedYes. But a PUT is14:02
efriedSo you GET /a_c and it returns allocations only14:02
efriedthen you take that dict, blindly, and stuff it *next to* a dict describing the consumer to do your PUT /allocations (or a new version of POST as gibi says)14:03
jaypipesefried, cdent: it was always about the structure/format of the allocation_request part of the GET /a_c response. That is what we care about versioning which is why the version supplied to claim_resources() is called allocation_request_version.14:06
*** s10_ has joined #openstack-placement14:28
*** s10 has quit IRC14:30
*** cdent has quit IRC14:53
*** e0ne has quit IRC14:58
*** takashin has left #openstack-placement15:01
*** cdent has joined #openstack-placement15:03
*** s10_ has quit IRC15:09
*** ttsiouts has quit IRC15:11
*** e0ne has joined #openstack-placement15:13
openstackgerritEric Fried proposed openstack/nova-specs master: WIP: High Precision Event Timer (HPET) on x86 guests  https://review.openstack.org/60798915:24
*** e0ne has quit IRC15:47
*** helenafm has quit IRC16:03
edleafecdent: ok, I blew away my failing devstack VM and created a fresh one. It's working, except that it didn't install placement. Is https://review.openstack.org/#/c/600162 the only patch I need?16:20
cdentedleafe: yes16:20
edleafecdent: ty16:21
*** tssurya has quit IRC17:48
jaypipesgibi: rock on. consumer gen merged.18:29
jaypipesgibi: so what was your expectation with regards to getting through the remaining patches in this series? today?18:30
cdentpraise be18:30
jaypipeslord have mercy18:30
*** e0ne has joined #openstack-placement18:31
cdentI _think_ i'm 1, maybe 2, iterations from having the grenade stuff working18:31
cdentat which point I'll feel happy about taking next week off18:32
*** e0ne has quit IRC18:33
jaypipescdent: nice work on that.18:33
cdentmriedem laid in most of the ground work, and then I found all little niggly bits18:34
*** s10 has joined #openstack-placement18:34
*** mriedem has joined #openstack-placement18:34
cdenti'll try to write a reasonable summary in tomorrow pupdate so there's no state up in the air18:34
cdentspeak of the devil18:34
*** cdent has quit IRC18:39
efriedjaypipes: FYI I'm working my way up the stack, working through https://review.openstack.org/#/c/605785 atm19:08
efried(regarding gibi's series)19:08
*** mriedem has quit IRC19:15
*** s10 has quit IRC19:17
jaypipesefried: k, I'm still chugging through em as well.19:19
*** cdent has joined #openstack-placement19:23
*** mriedem has joined #openstack-placement19:24
*** s10 has joined #openstack-placement19:24
*** cdent has quit IRC19:54
*** e0ne has joined #openstack-placement20:08
*** e0ne has quit IRC20:14
*** s10 has quit IRC20:16
*** s10 has joined #openstack-placement20:16
*** s10 has quit IRC20:16
*** s10 has joined #openstack-placement20:17
*** s10 has quit IRC20:17
*** s10 has joined #openstack-placement20:18
*** s10 has quit IRC20:18
*** s10 has joined #openstack-placement20:18
*** s10 has quit IRC20:19
*** s10 has joined #openstack-placement20:19
*** s10 has quit IRC20:20
*** e0ne has joined #openstack-placement20:30
*** e0ne has quit IRC21:00
*** mriedem has quit IRC21:05
*** edleafe has quit IRC23:39
*** takashin has joined #openstack-placement23:48
*** tetsuro_ has joined #openstack-placement23:57

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!