Wednesday, 2019-10-16

*** e0ne has joined #openstack-placement07:19
*** tssurya has joined #openstack-placement07:38
*** ttsiouts has joined #openstack-placement07:57
*** tssurya has quit IRC08:34
*** cdent has joined #openstack-placement08:44
*** gibi is now known as gibi_off08:58
*** ttsiouts has quit IRC09:09
*** ttsiouts has joined #openstack-placement09:09
*** cdent_ has joined #openstack-placement09:10
*** cdent has quit IRC09:12
*** cdent_ is now known as cdent09:12
*** ttsiouts has quit IRC10:20
*** ttsiouts has joined #openstack-placement10:21
*** ttsiouts has quit IRC10:26
*** ttsiouts has joined #openstack-placement10:53
*** ttsiouts has quit IRC10:58
*** ttsiouts has joined #openstack-placement11:25
*** ttsiouts has quit IRC11:26
*** ttsiouts has joined #openstack-placement11:26
*** mriedem has joined #openstack-placement13:15
*** bauzas has quit IRC13:21
*** bauzas has joined #openstack-placement13:29
*** tssurya has joined #openstack-placement14:07
*** bauzas has left #openstack-placement14:14
*** bauzas has joined #openstack-placement14:14
*** openstackgerrit has joined #openstack-placement14:29
openstackgerritMatt Riedemann proposed openstack/placement master: api-ref: note GET /resource_providers?resources amount constraints  https://review.opendev.org/68894314:29
*** spatel has joined #openstack-placement14:30
cdenthuzzah: https://pypi.org/project/openstack-placement/14:35
*** spatel has quit IRC14:45
efriedcdent: if you hadn't seen: https://www.zdnet.com/article/the-openstack-train-keeps-chugging-on/ (placement mention at the bottom)15:12
mriedemit's in several of the release articles15:16
mriedemhttps://www.theregister.co.uk/2019/10/15/openstack_train/15:16
cdent"This enables you to launch Apache, nginx or other Web Server Gateway Interface-capable web servers faster."15:19
mriedemi saw that too, laughed15:20
efriedperformance numbers as absolutes, with zero context or qualification.15:20
cdentand ""When the team decoupled it [Placement] from Nova," explained the gang, "they focused very specifically on that one step: 'Let's place a resource.' And they realised they can optimise that by simplifying some of the code paths and changing the data model. And then in Train, they took it a little further and did more code profiling to find where to eke out even more...""15:20
cdentnot sure who that is quoted from because the foundation asked me for some quotes, and that's not one of them...15:21
* cdent shrugs15:21
mriedemthe gang == cdent15:21
mriedemclearly15:21
mriedemand scoobs15:21
cdenti would have done it if it weren't for you kids15:21
cdentor something15:21
efriedwe've talked in the past about having a "having resource class" query, haven't we?15:23
efriedlike GET /resource_providers?MEMORY_MB (without an amount)15:24
efriedso it works even if all consumed15:24
efriedthis is pursuant to mriedem's/bauzas's quest for "how do I detect the RP that represents the compute node?"15:24
mriedemi'm not sure i'd call it a quest...15:25
efriedIMO it wouldn't be the worst idea to mark the compute RP with a trait15:25
cdenti wrote a spec for 'having' at some point15:27
cdentit's not quite the same semantic as a HYPERVISOR trait (or whatever it would be)15:28
efriedAgain IMO, if you're trying to detect compute node-ness, ?having=$RC is a hack no matter what $RC you choose.15:29
mriedemthere are compute-specific traits that most node providers share i think15:29
mriedembut ironic is usually the oddball15:29
cdenthe's the spec: https://review.opendev.org/#/c/600016/15:29
cdentyes, having is a hack for identifying a compute node15:29
cdentbut it _might_ be generically useful15:30
efriedbut yagni15:30
mriedemCOMPUTE_IMAGE_TYPE_RAW would work *except* for vcenter...15:30
cdentyes15:30
efriedwhereas a trait would be... not a hack. That seems like a thing traits were made to do.15:30
cdentis there resistance to a trait? I would assume that any resistance to that went away when jay did?15:31
efriedmriedem: that's also a hack. But I guess you're looking for a way that still works with legacy computes?15:31
mriedemthe image type stuff is recent so it wouldn't work on older computes anyway and yes it's a hack15:31
mriedemi don't think there is general resistence to a trait, we already have them for these driver capabilities15:31
mriedembut i also don't think it's a priority15:32
efriedCertainly no resistance from me. I think it's something we're going to need very quickly as we get more nesting/sharing. If we do it now, we can retrofit the trait based on {root+!MISC_SHARES}.15:32
mriedemi.e. would be best to identify in what scenarios things would gain from having that trait for optimizing their filtering15:32
efriedhum, come to think of it...15:33
efriedif we're looking from a nova perspective, is there any situation where {root+!MISC_SHARES} wouldn't work?15:33
mriedemwatcher might be keen since they added placement support to filter on only compute nodes (i wouldn't be surprised if watcher naively assumes all providers are compute nodes)15:33
efriedeven in the misty future?15:33
efriedcourse, that's *also* a hack.15:33
* efried <== brb15:34
cdentI'm not parsing " {root+!MISC_SHARES}"15:34
cdenti was simply assuming the nova-compute would restart and set its own trait on its own root, done15:35
mriedemit's a compute node if it's root and not a misc shares agg provider is i think eric's thinking15:35
mriedemcdent: yes that's the non-hack way to do that15:35
mriedemi would rather not imply traits15:35
mriedembased on how things currently work15:35
mriedemespecially when it's so easy to do it explicitly15:35
cdentif your interpretation of efried is correct, that's not safe in a heterogenous env15:36
mriedemhttps://www.youtube.com/watch?v=FMbl1ntpIXQ15:36
mriedemaxl with teased up hair is probably worst axl15:36
mriedemexcept maybe cornrows axl15:37
cdentanything post facework is the worst axl15:37
*** ttsiouts has quit IRC15:39
*** ttsiouts has joined #openstack-placement15:40
*** tssurya has quit IRC15:43
*** ttsiouts has quit IRC15:44
efriedYes, we should have the computes mark the RP. I was saying if we want to retrofit this to work on N-1 computes, we could conceivably assume {root+!MISC_SHARES} is a compute node. But as cdent says, "heterogeneous" -- though I'm not sure that's anything beyond theoretical at this stage?16:00
cdentI don't think we can see into the hearts of placement servers everywhere...16:01
cdentOn N-1; I've never been sympathetic to that line of thinking. If people want new stuff, they should upgrade, all of it.16:01
cdentif they don't, don't get new stuff (min service version checks are a thing, yes?)16:03
mriedemyes16:03
efriedguess it depends what we want to use this thing for.16:04
efriedcurrent use case is "placement audit command"?16:04
efriedhttps://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@292116:04
efriedmy point being that we support n-1 computes16:05
efriedso if you run this command and we're assuming the trait, you'll only cover your n computes.16:05
efriedif that's an acceptable caveat, then fine.16:05
efriedBut I do think we ought to start marking compute node RPs with a "This is a compute node" trait ASAP.16:06
efriedWhat do we want to call that?16:06
efriedAny reason it couldn't be COMPUTE_NODE ?16:09
cdenti don't have any objections to that, but naming has never been my strong suit16:11
efriedsay, do ironic nodes even have MEMORY_MB inventory anymore?16:18
efriedso like, that's a nonstarter anyway, nah?16:18
cdenti think matt already said that somewhere, not sure where16:18
efriedk16:18
cdentstoryboard maybe?16:19
openstackgerritEric Fried proposed openstack/os-traits master: Add COMPUTE_NODE trait  https://review.opendev.org/68896916:22
efriedcdent, mriedem: ^16:22
efriedbauzas:16:22
bauzasefried: I'm about to quit for the day, but I'll open the tab for tomorrow's coffee usage16:22
efriedbauzas: ack. Pretty simple tho16:22
bauzas(and I'm happy to be pinged for a placement change)16:23
bauzashah, os-traits, dammit16:23
melwittcdent: is it ok if I update the consumer types patch to address my comments on the tests? or are you working on it16:23
bauzasyet a claim then : if folks wanna me to put my fat fingers on placement stuffy, you know my name16:23
cdentmelwitt: go for it. Unfortunately I'm not going to be able to do anything with that any time soon16:24
melwittok, thanks16:24
cdentefried: do you remember can_host?16:26
cdentmelwitt: no, thank _you_16:26
efriedcdent: rings a bell, but really faintly. Could just be tinnitus.16:26
cdentit is very old and very dead. it was an attribute on a resource provider which might have meant what we're talking about here16:27
cdenthowever, it was a bad idea then and now. trait is much better choice (since it is not "speical")16:27
cdentor even special16:27
efriedoh, can_host was like a totally separate boolean field on a provider or something?16:27
efriedyeah, I vaguely remember that being discussed and loudly shouted down.16:28
cdentyeah, it was in the database and everything16:28
efriedSay, COMPUTE_NODE might make root_required/root_member_of redundant.16:29
cdentin some cases, but not all cases?16:29
efried...for nova use cases16:29
efriedyeah16:29
efriedhey, did we decide to do a major release of os-traits since we privatized those methods?16:30
bauzascdent: efried: IIRC, we already discuss on the COMPUTE_NODE trait16:31
efriedI think stephenfin suggested it, but I don't think we did it.16:31
bauzasat PTG or somewhere else16:31
bauzasand we nacked the idea and we preferred having consumer types16:31
efriedbauzas: Yeah, but Jay is gone now :P16:31
bauzasbut I miss remembrance16:31
cdentconsumer type is for instances16:31
cdentnot hypervisors/nodes16:31
bauzasefried: yeah but his arguments could still be valid16:31
efriedbauzas: Was there any reason for the nack other than "that's not a *capability* <whine whine>"?16:32
bauzasefried: that's the purpose of the above : I don't recall the arguments16:32
efriedI've never held with that stricture, clearly.16:32
cdentefried: i had no position on os-traits major release, was happy to follow. I'm still grumpy about os-traits having _any_ messages :)16:32
cdentsigh: methods!16:32
efriedmeh, imo the normalize_name makes plenty of sense.16:33
efriedI would have loved there not to be the modular hierarchy business.16:33
cdentwe will continue to disagree on that until the end times16:33
cdent(normalize_name, not hierarchy)16:34
cdentthe hierarchy was supposed to support a particular style of use that never really came to pass16:34
efriedk, I'll go ahead and propose the release, might as well, no harm no foul.16:34
efriedand we can hold the COMPUTE_NODE trait until that's in.16:34
cdenthell, I still have vague feelings of not-sure about there being an os-traits at all16:35
cdentbut we are in the world we are in16:35
cdentnot that other one where I eat unicorn pooh all day16:35
efriedstephenfin, cdent: https://review.opendev.org/68897416:43
stephenfinefried: haven't checked yet (I need to run) but since we're going to 1.0 you probably want to mark the os-traits package as "5 - Stable" in the trove classifiers in 'setup.cfg'17:00
stephenfinif that doesn't make sense, I'll check tomorrow :)17:00
stephenfinbut rn I need to head17:01
efriedstephenfin: yeah, that's greek to me17:01
efriedif it's not something that needs to be done in that patch, yeah, hmu tomorrow.17:01
efriedThanks!17:01
*** e0ne has quit IRC17:01
efriedmriedem, cdent, bauzas: https://review.opendev.org/688979 (will fail until we get that release)17:02
bauzasefried: ta, I'm done with the day, but I'll look at it tomorrow17:08
efriedbauzas: ack, no hurry.17:08
*** cdent has quit IRC17:30
*** dklyle has quit IRC18:00
*** david-lyle has joined #openstack-placement18:00
*** e0ne has joined #openstack-placement18:18
openstackgerritEric Fried proposed openstack/placement master: Clarify GET /allocations/$c for nonexistent $c  https://review.opendev.org/68900418:42
efriedmriedem: ^18:43
*** e0ne has quit IRC18:57
openstackgerritMerged openstack/placement master: api-ref: note GET /resource_providers?resources amount constraints  https://review.opendev.org/68894319:13
mriedemefried: question in there19:59
efriedmriedem: responded20:11
*** efried is now known as efried_afk20:16
mriedemreplied to the reply and yielded20:24
mriedemmostly because the response param optional weirdness hasn't made it's way into placement yet20:24
openstackgerritmelanie witt proposed openstack/placement master: Add consumer_types migration, database and object changes  https://review.opendev.org/66917020:42
openstackgerritmelanie witt proposed openstack/placement master: Microversion 1.37: API support for consumer types  https://review.opendev.org/67944120:42
openstackgerritmelanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache  https://review.opendev.org/67948620:42
efried_afkmriedem: imo the important thing is how it appears to the reader, and "(Optional)" doesn't make sense in a response. Better to omit it.21:19
*** efried_afk is now known as efried21:19
efriedespecially if there's text saying when it does or doesn't appear.21:19
*** mriedem is now known as mriedem_afk21:46
*** takashin has joined #openstack-placement21:51
*** david-lyle has quit IRC22:34
*** dklyle has joined #openstack-placement22:43

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