*** e0ne has joined #openstack-placement | 07:19 | |
*** tssurya has joined #openstack-placement | 07:38 | |
*** ttsiouts has joined #openstack-placement | 07:57 | |
*** tssurya has quit IRC | 08:34 | |
*** cdent has joined #openstack-placement | 08:44 | |
*** gibi is now known as gibi_off | 08:58 | |
*** ttsiouts has quit IRC | 09:09 | |
*** ttsiouts has joined #openstack-placement | 09:09 | |
*** cdent_ has joined #openstack-placement | 09:10 | |
*** cdent has quit IRC | 09:12 | |
*** cdent_ is now known as cdent | 09:12 | |
*** ttsiouts has quit IRC | 10:20 | |
*** ttsiouts has joined #openstack-placement | 10:21 | |
*** ttsiouts has quit IRC | 10:26 | |
*** ttsiouts has joined #openstack-placement | 10:53 | |
*** ttsiouts has quit IRC | 10:58 | |
*** ttsiouts has joined #openstack-placement | 11:25 | |
*** ttsiouts has quit IRC | 11:26 | |
*** ttsiouts has joined #openstack-placement | 11:26 | |
*** mriedem has joined #openstack-placement | 13:15 | |
*** bauzas has quit IRC | 13:21 | |
*** bauzas has joined #openstack-placement | 13:29 | |
*** tssurya has joined #openstack-placement | 14:07 | |
*** bauzas has left #openstack-placement | 14:14 | |
*** bauzas has joined #openstack-placement | 14:14 | |
*** openstackgerrit has joined #openstack-placement | 14:29 | |
openstackgerrit | Matt Riedemann proposed openstack/placement master: api-ref: note GET /resource_providers?resources amount constraints https://review.opendev.org/688943 | 14:29 |
---|---|---|
*** spatel has joined #openstack-placement | 14:30 | |
cdent | huzzah: https://pypi.org/project/openstack-placement/ | 14:35 |
*** spatel has quit IRC | 14:45 | |
efried | cdent: if you hadn't seen: https://www.zdnet.com/article/the-openstack-train-keeps-chugging-on/ (placement mention at the bottom) | 15:12 |
mriedem | it's in several of the release articles | 15:16 |
mriedem | https://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 |
mriedem | i saw that too, laughed | 15:20 |
efried | performance numbers as absolutes, with zero context or qualification. | 15:20 |
cdent | and ""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 |
cdent | not sure who that is quoted from because the foundation asked me for some quotes, and that's not one of them... | 15:21 |
* cdent shrugs | 15:21 | |
mriedem | the gang == cdent | 15:21 |
mriedem | clearly | 15:21 |
mriedem | and scoobs | 15:21 |
cdent | i would have done it if it weren't for you kids | 15:21 |
cdent | or something | 15:21 |
efried | we've talked in the past about having a "having resource class" query, haven't we? | 15:23 |
efried | like GET /resource_providers?MEMORY_MB (without an amount) | 15:24 |
efried | so it works even if all consumed | 15:24 |
efried | this is pursuant to mriedem's/bauzas's quest for "how do I detect the RP that represents the compute node?" | 15:24 |
mriedem | i'm not sure i'd call it a quest... | 15:25 |
efried | IMO it wouldn't be the worst idea to mark the compute RP with a trait | 15:25 |
cdent | i wrote a spec for 'having' at some point | 15:27 |
cdent | it's not quite the same semantic as a HYPERVISOR trait (or whatever it would be) | 15:28 |
efried | Again IMO, if you're trying to detect compute node-ness, ?having=$RC is a hack no matter what $RC you choose. | 15:29 |
mriedem | there are compute-specific traits that most node providers share i think | 15:29 |
mriedem | but ironic is usually the oddball | 15:29 |
cdent | he's the spec: https://review.opendev.org/#/c/600016/ | 15:29 |
cdent | yes, having is a hack for identifying a compute node | 15:29 |
cdent | but it _might_ be generically useful | 15:30 |
efried | but yagni | 15:30 |
mriedem | COMPUTE_IMAGE_TYPE_RAW would work *except* for vcenter... | 15:30 |
cdent | yes | 15:30 |
efried | whereas a trait would be... not a hack. That seems like a thing traits were made to do. | 15:30 |
cdent | is there resistance to a trait? I would assume that any resistance to that went away when jay did? | 15:31 |
efried | mriedem: that's also a hack. But I guess you're looking for a way that still works with legacy computes? | 15:31 |
mriedem | the image type stuff is recent so it wouldn't work on older computes anyway and yes it's a hack | 15:31 |
mriedem | i don't think there is general resistence to a trait, we already have them for these driver capabilities | 15:31 |
mriedem | but i also don't think it's a priority | 15:32 |
efried | Certainly 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 |
mriedem | i.e. would be best to identify in what scenarios things would gain from having that trait for optimizing their filtering | 15:32 |
efried | hum, come to think of it... | 15:33 |
efried | if we're looking from a nova perspective, is there any situation where {root+!MISC_SHARES} wouldn't work? | 15:33 |
mriedem | watcher 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 |
efried | even in the misty future? | 15:33 |
efried | course, that's *also* a hack. | 15:33 |
* efried <== brb | 15:34 | |
cdent | I'm not parsing " {root+!MISC_SHARES}" | 15:34 |
cdent | i was simply assuming the nova-compute would restart and set its own trait on its own root, done | 15:35 |
mriedem | it's a compute node if it's root and not a misc shares agg provider is i think eric's thinking | 15:35 |
mriedem | cdent: yes that's the non-hack way to do that | 15:35 |
mriedem | i would rather not imply traits | 15:35 |
mriedem | based on how things currently work | 15:35 |
mriedem | especially when it's so easy to do it explicitly | 15:35 |
cdent | if your interpretation of efried is correct, that's not safe in a heterogenous env | 15:36 |
mriedem | https://www.youtube.com/watch?v=FMbl1ntpIXQ | 15:36 |
mriedem | axl with teased up hair is probably worst axl | 15:36 |
mriedem | except maybe cornrows axl | 15:37 |
cdent | anything post facework is the worst axl | 15:37 |
*** ttsiouts has quit IRC | 15:39 | |
*** ttsiouts has joined #openstack-placement | 15:40 | |
*** tssurya has quit IRC | 15:43 | |
*** ttsiouts has quit IRC | 15:44 | |
efried | Yes, 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 |
cdent | I don't think we can see into the hearts of placement servers everywhere... | 16:01 |
cdent | On 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 |
cdent | if they don't, don't get new stuff (min service version checks are a thing, yes?) | 16:03 |
mriedem | yes | 16:03 |
efried | guess it depends what we want to use this thing for. | 16:04 |
efried | current use case is "placement audit command"? | 16:04 |
efried | https://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@2921 | 16:04 |
efried | my point being that we support n-1 computes | 16:05 |
efried | so if you run this command and we're assuming the trait, you'll only cover your n computes. | 16:05 |
efried | if that's an acceptable caveat, then fine. | 16:05 |
efried | But I do think we ought to start marking compute node RPs with a "This is a compute node" trait ASAP. | 16:06 |
efried | What do we want to call that? | 16:06 |
efried | Any reason it couldn't be COMPUTE_NODE ? | 16:09 |
cdent | i don't have any objections to that, but naming has never been my strong suit | 16:11 |
efried | say, do ironic nodes even have MEMORY_MB inventory anymore? | 16:18 |
efried | so like, that's a nonstarter anyway, nah? | 16:18 |
cdent | i think matt already said that somewhere, not sure where | 16:18 |
efried | k | 16:18 |
cdent | storyboard maybe? | 16:19 |
openstackgerrit | Eric Fried proposed openstack/os-traits master: Add COMPUTE_NODE trait https://review.opendev.org/688969 | 16:22 |
efried | cdent, mriedem: ^ | 16:22 |
efried | bauzas: | 16:22 |
bauzas | efried: I'm about to quit for the day, but I'll open the tab for tomorrow's coffee usage | 16:22 |
efried | bauzas: ack. Pretty simple tho | 16:22 |
bauzas | (and I'm happy to be pinged for a placement change) | 16:23 |
bauzas | hah, os-traits, dammit | 16:23 |
melwitt | cdent: is it ok if I update the consumer types patch to address my comments on the tests? or are you working on it | 16:23 |
bauzas | yet a claim then : if folks wanna me to put my fat fingers on placement stuffy, you know my name | 16:23 |
cdent | melwitt: go for it. Unfortunately I'm not going to be able to do anything with that any time soon | 16:24 |
melwitt | ok, thanks | 16:24 |
cdent | efried: do you remember can_host? | 16:26 |
cdent | melwitt: no, thank _you_ | 16:26 |
efried | cdent: rings a bell, but really faintly. Could just be tinnitus. | 16:26 |
cdent | it is very old and very dead. it was an attribute on a resource provider which might have meant what we're talking about here | 16:27 |
cdent | however, it was a bad idea then and now. trait is much better choice (since it is not "speical") | 16:27 |
cdent | or even special | 16:27 |
efried | oh, can_host was like a totally separate boolean field on a provider or something? | 16:27 |
efried | yeah, I vaguely remember that being discussed and loudly shouted down. | 16:28 |
cdent | yeah, it was in the database and everything | 16:28 |
efried | Say, COMPUTE_NODE might make root_required/root_member_of redundant. | 16:29 |
cdent | in some cases, but not all cases? | 16:29 |
efried | ...for nova use cases | 16:29 |
efried | yeah | 16:29 |
efried | hey, did we decide to do a major release of os-traits since we privatized those methods? | 16:30 |
bauzas | cdent: efried: IIRC, we already discuss on the COMPUTE_NODE trait | 16:31 |
efried | I think stephenfin suggested it, but I don't think we did it. | 16:31 |
bauzas | at PTG or somewhere else | 16:31 |
bauzas | and we nacked the idea and we preferred having consumer types | 16:31 |
efried | bauzas: Yeah, but Jay is gone now :P | 16:31 |
bauzas | but I miss remembrance | 16:31 |
cdent | consumer type is for instances | 16:31 |
cdent | not hypervisors/nodes | 16:31 |
bauzas | efried: yeah but his arguments could still be valid | 16:31 |
efried | bauzas: Was there any reason for the nack other than "that's not a *capability* <whine whine>"? | 16:32 |
bauzas | efried: that's the purpose of the above : I don't recall the arguments | 16:32 |
efried | I've never held with that stricture, clearly. | 16:32 |
cdent | efried: 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 |
cdent | sigh: methods! | 16:32 |
efried | meh, imo the normalize_name makes plenty of sense. | 16:33 |
efried | I would have loved there not to be the modular hierarchy business. | 16:33 |
cdent | we will continue to disagree on that until the end times | 16:33 |
cdent | (normalize_name, not hierarchy) | 16:34 |
cdent | the hierarchy was supposed to support a particular style of use that never really came to pass | 16:34 |
efried | k, I'll go ahead and propose the release, might as well, no harm no foul. | 16:34 |
efried | and we can hold the COMPUTE_NODE trait until that's in. | 16:34 |
cdent | hell, I still have vague feelings of not-sure about there being an os-traits at all | 16:35 |
cdent | but we are in the world we are in | 16:35 |
cdent | not that other one where I eat unicorn pooh all day | 16:35 |
efried | stephenfin, cdent: https://review.opendev.org/688974 | 16:43 |
stephenfin | efried: 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 |
stephenfin | if that doesn't make sense, I'll check tomorrow :) | 17:00 |
stephenfin | but rn I need to head | 17:01 |
efried | stephenfin: yeah, that's greek to me | 17:01 |
efried | if it's not something that needs to be done in that patch, yeah, hmu tomorrow. | 17:01 |
efried | Thanks! | 17:01 |
*** e0ne has quit IRC | 17:01 | |
efried | mriedem, cdent, bauzas: https://review.opendev.org/688979 (will fail until we get that release) | 17:02 |
bauzas | efried: ta, I'm done with the day, but I'll look at it tomorrow | 17:08 |
efried | bauzas: ack, no hurry. | 17:08 |
*** cdent has quit IRC | 17:30 | |
*** dklyle has quit IRC | 18:00 | |
*** david-lyle has joined #openstack-placement | 18:00 | |
*** e0ne has joined #openstack-placement | 18:18 | |
openstackgerrit | Eric Fried proposed openstack/placement master: Clarify GET /allocations/$c for nonexistent $c https://review.opendev.org/689004 | 18:42 |
efried | mriedem: ^ | 18:43 |
*** e0ne has quit IRC | 18:57 | |
openstackgerrit | Merged openstack/placement master: api-ref: note GET /resource_providers?resources amount constraints https://review.opendev.org/688943 | 19:13 |
mriedem | efried: question in there | 19:59 |
efried | mriedem: responded | 20:11 |
*** efried is now known as efried_afk | 20:16 | |
mriedem | replied to the reply and yielded | 20:24 |
mriedem | mostly because the response param optional weirdness hasn't made it's way into placement yet | 20:24 |
openstackgerrit | melanie witt proposed openstack/placement master: Add consumer_types migration, database and object changes https://review.opendev.org/669170 | 20:42 |
openstackgerrit | melanie witt proposed openstack/placement master: Microversion 1.37: API support for consumer types https://review.opendev.org/679441 | 20:42 |
openstackgerrit | melanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache https://review.opendev.org/679486 | 20:42 |
efried_afk | mriedem: 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 efried | 21:19 | |
efried | especially if there's text saying when it does or doesn't appear. | 21:19 |
*** mriedem is now known as mriedem_afk | 21:46 | |
*** takashin has joined #openstack-placement | 21:51 | |
*** david-lyle has quit IRC | 22:34 | |
*** dklyle has joined #openstack-placement | 22:43 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!