| *** efried has quit IRC | 00:38 | |
| *** efried has joined #openstack-placement | 00:38 | |
| *** tetsuro has joined #openstack-placement | 01:44 | |
| *** tetsuro has quit IRC | 04:03 | |
| *** rubasov has joined #openstack-placement | 05:45 | |
| *** takashin has quit IRC | 07:07 | |
| *** takashin has joined #openstack-placement | 07:15 | |
| *** helenafm has joined #openstack-placement | 07:26 | |
| *** tssurya has joined #openstack-placement | 08:11 | |
| *** giblet is now known as gibi | 08:19 | |
| *** finucannot is now known as stephenfin | 08:43 | |
| *** ttsiouts has joined #openstack-placement | 08:55 | |
| *** ttsiouts has quit IRC | 08:56 | |
| *** ttsiouts has joined #openstack-placement | 08:56 | |
| *** e0ne has joined #openstack-placement | 08:59 | |
| openstackgerrit | Theodoros Tsioutsias proposed openstack/nova-specs master: Add PENDING vm state https://review.openstack.org/554212 | 09:13 |
|---|---|---|
| *** alex_xu has quit IRC | 09:38 | |
| *** alex_xu has joined #openstack-placement | 09:40 | |
| *** tetsuro has joined #openstack-placement | 09:52 | |
| *** ttsiouts has quit IRC | 10:28 | |
| *** ttsiouts has joined #openstack-placement | 11:04 | |
| openstackgerrit | Theodoros Tsioutsias proposed openstack/nova-specs master: Enable rebuild for instances in cell0 https://review.openstack.org/554218 | 11:11 |
| openstackgerrit | Theodoros Tsioutsias proposed openstack/nova-specs master: Add PENDING vm state https://review.openstack.org/554212 | 11:15 |
| *** tetsuro has quit IRC | 11:30 | |
| *** e0ne has quit IRC | 12:01 | |
| *** e0ne has joined #openstack-placement | 12:08 | |
| *** ttsiouts has quit IRC | 12:26 | |
| *** ttsiouts has joined #openstack-placement | 12:30 | |
| *** jroll has quit IRC | 12:54 | |
| *** jroll has joined #openstack-placement | 12:55 | |
| openstackgerrit | Chris Dent proposed openstack/placement master: DNM: Experimenting with integration gabbits https://review.openstack.org/601614 | 13:06 |
| openstackgerrit | Chris Dent proposed openstack/placement master: WIP: Add placeload to integration test https://review.openstack.org/602484 | 13:06 |
| *** ttsiouts has quit IRC | 13:21 | |
| *** ttsiouts has joined #openstack-placement | 13:27 | |
| *** cdent has joined #openstack-placement | 13:28 | |
| cdent | o/ | 13:28 |
| openstackgerrit | Chris Dent proposed openstack/placement master: WIP: Add placeload to integration test https://review.openstack.org/602484 | 13:45 |
| efried | n-sch/placement meeting in 7 minutes in #openstack-meeting-alt | 13:53 |
| *** tetsuro has joined #openstack-placement | 13:55 | |
| *** leakypipes is now known as jaypipes | 14:15 | |
| *** ttsiouts has quit IRC | 14:28 | |
| *** zaneb has joined #openstack-placement | 14:28 | |
| *** ttsiouts has joined #openstack-placement | 14:28 | |
| *** tetsuro has quit IRC | 14:42 | |
| *** takashin has left #openstack-placement | 15:01 | |
| *** ttsiouts has quit IRC | 15:02 | |
| *** mriedem has joined #openstack-placement | 15:07 | |
| openstackgerrit | Chris Dent proposed openstack/placement master: DNM: Experimenting with integration gabbits https://review.openstack.org/601614 | 15:12 |
| openstackgerrit | Chris Dent proposed openstack/placement master: WIP: Add placeload to integration test https://review.openstack.org/602484 | 15:12 |
| mriedem | cdent: not sure if you noticed yet, but your devstack patch to start extracted placement, which depends on my grenade patch, is failing to start up the placement service on the new side after the upgrade, | 15:20 |
| mriedem | http://logs.openstack.org/62/600162/5/check/neutron-grenade/13bde35/logs/screen-placement-api.txt.gz | 15:20 |
| mriedem | i can't figure out why it's actually failing to start though | 15:21 |
| cdent | mriedem: i hadn't noticed yet, no | 15:21 |
| mriedem | it looks like it might not be starting with placement.conf? | 15:21 |
| cdent | I started late today so still getting situated | 15:21 |
| * cdent looks | 15:21 | |
| cdent | mriedem: it's using nova-placement-api as it's wsgi script, not placement-api | 15:22 |
| cdent | it's looking at /etc/nova/placement-uwsgi.ini | 15:22 |
| cdent | which is the wrong thing | 15:22 |
| cdent | so presumably part of the upgrade process is to change the system unit file (or just create a new one via lib/placement) | 15:23 |
| cdent | nova-placement-api (from the nova code) continues to look at /etc/nova/nova.conf. | 15:24 |
| mriedem | "new one via lib/placement" after your devstack change? | 15:25 |
| mriedem | because we can't do that right now - the devstack change depends on the grenade change | 15:25 |
| cdent | then sed-ing the existing one ought to be doable but a couple of caveats: | 15:28 |
| cdent | actually if you give me a minut to turn on a devstack vm, I can't speak a bit more clearly about this, one sec... | 15:28 |
| mriedem | sure, no rush, i just got online | 15:29 |
| jaypipes | cdent: whatcha currently waiting on to remove the WIP on the placeload thingie? | 15:35 |
| cdent | jaypipes: its parent doesn't work quite right yet | 15:35 |
| jaypipes | ah, k. | 15:35 |
| cdent | trying to make it "modern zuul" opened up many works | 15:36 |
| cdent | worms | 15:36 |
| jaypipes | ack | 15:36 |
| jaypipes | cdent: be grateful. you could instead be having to develop a Screwdriver pipeline for it... :( | 15:36 |
| cdent | https://www.youtube.com/watch?v=ZdJ5e70Q8mw | 15:37 |
| jaypipes | heh | 15:37 |
| jroll | jaypipes: the open source version of screwdriver (v4) is pretty awesome, tbh | 15:47 |
| cdent | okay mriedem I'm spooled up now. Basically we've got three separate placements where placement been started on some variation of the "nova-placement" theme: | 15:52 |
| cdent | /etc/systemd/system/devstack@placement-api.service refers to /etc/nova/placement-uwsgi.ini refers to /var/run/uwsgi/nova-placement-api.socket and /usr/local/bin/nova-placement-api | 15:55 |
| cdent | the *.socket file is mentioned in /etc/apache2/sites-enabled/nova-placement-api.conf | 15:55 |
| *** ttsiouts has joined #openstack-placement | 15:56 | |
| *** ttsiouts has quit IRC | 15:56 | |
| *** ttsiouts has joined #openstack-placement | 15:56 | |
| cdent | the bare minimum change to change /et/cnova/placement-uwsgi.ini to replace "nova-placement-api" with "placement-api" | 15:56 |
| cdent | the rest of it is just names | 15:57 |
| mriedem | cdent: ok can you -1 my grenade change with those details? | 15:57 |
| cdent | yeah, will do, but before I head off there: are we after a bare minimum change here or a more correct change? Or is it cool to iterate to absolute perfection? | 15:58 |
| *** e0ne has quit IRC | 15:58 | |
| jaypipes | jroll: I respectfully disagree :) | 16:00 |
| mriedem | cdent: as in are we ok to merge the grenade change now? | 16:01 |
| mriedem | cdent: it's not really useful at this point since we can't start placement on the new side | 16:01 |
| *** ttsiouts has quit IRC | 16:01 | |
| cdent | mriedem: no, I mean we can get placement to start correctly by doing the bare minimum thing I just described above | 16:01 |
| mriedem | if all i'm lacking is a 1 line sed, then i think we can wait | 16:01 |
| mriedem | oh | 16:01 |
| cdent | but that leave's some files with bad names | 16:02 |
| cdent | (sigh, I don't want to ever type again) | 16:02 |
| jaypipes | hehe | 16:02 |
| mriedem | i.e. should we recreate from scratch /etc/placement/placement-uwsgi.ini | 16:02 |
| cdent | /etc/nova/*uwsgi* will still, but it's in the "wrong" place | 16:02 |
| cdent | what I'm wondering is: do the bare min, get things to merge, then tune it up with more robust file fixes | 16:03 |
| mriedem | i think the grenade change should do whatever we expect/want real deployment tools to do for the placement extraction upgrade | 16:03 |
| mriedem | so we can just point people at the single grenade patch | 16:03 |
| * cdent thinks on that | 16:03 | |
| mriedem | this is already going to be confusing for a bunch of people, so i don't want to add to that confusion by saying, "here is a series of changes to make extracted placement upgrade work, you figure out what you need" | 16:04 |
| mriedem | going back to your question, since we said we shouldn't just copy/rename nova.conf to placement.conf in grenade, i suppose we shouldn't just do that for the wsgi config either | 16:05 |
| mriedem | maybe i need a patch to devstack to provide override paths/names for setting up the placement uwsgi config | 16:06 |
| mriedem | that would make the grenade patch simpler | 16:06 |
| cdent | mriedem: lemme finish writing up the bits on the review and then we can see what we think | 16:08 |
| *** helenafm has quit IRC | 16:12 | |
| cdent | mriedem: done. It's basically 4 fairly simple actions that need to happen | 16:19 |
| mriedem | ok, thanks | 16:24 |
| cdent | mriedem: another option is a time machine, if you got one spare | 16:26 |
| openstackgerrit | Chris Dent proposed openstack/placement master: DNM: Experimenting with integration gabbits https://review.openstack.org/601614 | 16:45 |
| openstackgerrit | Chris Dent proposed openstack/placement master: WIP: Add placeload to integration test https://review.openstack.org/602484 | 16:45 |
| mriedem | i don't | 16:46 |
| *** tssurya has quit IRC | 16:54 | |
| *** mriedem has quit IRC | 17:04 | |
| edleafe | This trip is some serious $$. Around £200/night per room, and with our 19-yo daughter, we can't always fit her in our room, so many nights it's closer to £400 | 17:22 |
| *** e0ne has joined #openstack-placement | 17:24 | |
| * edleafe types in wrong window | 17:24 | |
| jaypipes | efried: was I present for the discussion of https://review.openstack.org/#/c/602160/? I must be losing my mind in old age. I have no recollection of that topic whatsoever :( | 17:30 |
| efried | I don't remember who was in the room. But it was in the room, wasn't like a hallway or dinner discussion or whatever. | 17:31 |
| jaypipes | edleafe: cdent probably can rent a room for less than 200 quid a night :P | 17:31 |
| jaypipes | efried: cyborg room or nova room? | 17:31 |
| efried | nova | 17:31 |
| edleafe | jaypipes: sure, but who wants to be out in the boonies? | 17:32 |
| jaypipes | heh | 17:32 |
| efried | jaypipes: https://etherpad.openstack.org/p/nova-ptg-stein L166 | 17:32 |
| * cdent has the international openstackers hostel, cornwall edition | 17:33 | |
| efried | edleafe: you too, fyi ---^ | 17:33 |
| edleafe | efried: that was something agreed for Nova, not placement | 17:37 |
| *** e0ne has quit IRC | 17:37 | |
| efried | eh? | 17:37 |
| efried | It was agreed to use a standard trait (i.e. os-traits) to indicate the service owner of a provider (so not just nova, which is the whole point) | 17:37 |
| efried | no changes in the placement API | 17:38 |
| efried | unless you're counting os-traits. | 17:38 |
| efried | which I guess counts | 17:38 |
| edleafe | it counts for me | 17:38 |
| efried | because it affects whan you get back from /traits out of the box | 17:38 |
| efried | anyway, it's pretty unambiguous as it was discussed in the room and as it's written down in the etherpad (by melwitt I think, based on the color). | 17:39 |
| jaypipes | efried: not sure how a standard os-trait would ever indicate >1 bit of information in the trait string? i.e. you'd need to have "standard" traits that look like OWNER_NOVA, OWNER_NEUTRON, OWNER_CYBORG, etc... is that what you want? | 17:39 |
| efried | yes, precisely, look at the review. | 17:39 |
| efried | though to say it's what "I" want isn't really a good way to say it. It's the way *we* (the nova room) agreed to solve the problem at hand. | 17:40 |
| *** e0ne has joined #openstack-placement | 17:40 | |
| efried | I'm just proposing the patch that will implement what we agreed upon. | 17:41 |
| *** e0ne has quit IRC | 17:41 | |
| jaypipes | efried: sorry, I definitely didn't agree on that and don't remember that one line of the etherpad. | 17:41 |
| jaypipes | efried: if we're already putting a "partition" or "shard" key into the providers table (for multi-nova use case), why not add owner field in there at the same time? | 17:42 |
| jaypipes | efried: my thought is that an owner is a conceptually significant attribute for a provider and as such should be a real attribute on the provider model, not tucked away as a trait string. | 17:43 |
| edleafe | I would prefer a db change to messing with traits like this | 17:43 |
| jaypipes | (I also thought this about the sharing thing, but that ship has sailed) | 17:43 |
| efried | partition/shard sounds only vaguely familiar. But if it's an option to start putting explicit keys onto the provider object, shrug, wfm. | 17:43 |
| jaypipes | efried: partition/shard is the consumer type thingie | 17:43 |
| efried | I think I wasn't paying attention for that discussion :( | 17:44 |
| jaypipes | efried: line 126 in that etherpad... | 17:44 |
| jaypipes | efried: no worries :) | 17:44 |
| cdent | did we get into the implementation side of shards? We noodled some ideas, but I had the impression we liked the concept but hadn't nailed down the details. Also: I thought that we had shard and consumer type as something different | 17:45 |
| cdent | shard was effecftively supporting N>1 openstack-like-things from one placement | 17:45 |
| jaypipes | yep | 17:45 |
| cdent | but consumer type "this is an instance" | 17:45 |
| jaypipes | cdent: yeah, two different things. one being on the provider, the other being on the consumer, you're right. | 17:46 |
| cdent | presumably one option (of several) for shard would something like an "auto-aggregate" | 17:46 |
| cdent | because conceptually that's what it is | 17:46 |
| cdent | (a group of providers) | 17:47 |
| jaypipes | cdent: the provider one was originally referred to as "consumer type" because it was like "which nova is the thing that is consuming" but then we started referring to that as like a "consumer source" or something like that, and then we just referred to it as a provider shard/partition | 17:47 |
| efried | okay, so again we've got a big and complicated patch (including db migrations, a new schema/microversion for payloads on the /resource_providers/* routes, etc.) which is going to take a while to come to fruition. So if we need to solve the ownership issue in the meantime... can we use CUSTOM_OWNER_* as a temporary measure? | 17:47 |
| jaypipes | efried: and delay the big mess to being a giant data migration. | 17:47 |
| efried | yeah, fair point. | 17:48 |
| efried | rock, hard place | 17:48 |
| jaypipes | ack | 17:48 |
| cdent | no data migration strictly required. new stuff could do the new way. old way continues to work because traits aren't going to stop working. | 17:49 |
| cdent | (not saying we should do it, just thinking that perhaps the cost isn't _that_ dire) | 17:49 |
| efried | not sure I see a way to avoid *some* kind of data migration. | 17:49 |
| efried | If we have no way at all to indicate ownership in the interim | 17:49 |
| cdent | no, I meant: do CUSTOM_OWNER_* | 17:49 |
| jaypipes | right. it's just about where you encode the tribal knowledge and for how long. | 17:49 |
| cdent | but also have options for the future | 17:50 |
| efried | yeah, if we're not indicating ownership explicitly, we have to encode/hardcode an implicit owner. | 17:50 |
| efried | ...and only one of those | 17:50 |
| efried | meaning we can't actually let cyborg own device providers | 17:50 |
| efried | or | 17:50 |
| efried | we can't put devices in placement until cyborg is ready. | 17:51 |
| efried | and once the provider owner prop is ready, we're still "migrating" in a sense, it's just a little bit easier because we know any provider with ownership unset belongs to nova. | 17:51 |
| cdent | question: why does placement care who an owner is? | 17:51 |
| cdent | is it just the clients that do? | 17:52 |
| efried | afaict yes | 17:52 |
| efried | The advantage to having it as a provider prop is that it's enforced as unary. | 17:52 |
| efried | CUSTOM_OWNER_CYBORG and CUSTOM_OWNER_NOVA could coexist and placement wouldn't be the wiser. | 17:53 |
| efried | But that's all over the place, | 17:53 |
| efried | . | 17:53 |
| cdent | and presumably placement continues to not care | 17:53 |
| efried | yup. | 17:53 |
| efried | But I don't really forsee needing to make a scheduling decision based on ownership | 17:53 |
| efried | which is kind of what traits are limited to atm. | 17:54 |
| cdent | if ownership doesn't drive "placement" why put the info in placement? | 17:54 |
| efried | rather, this is a marker that would be used by a service to determine whether it owns a provider and thus has the authority to muck with it. | 17:54 |
| efried | oh, because ^ | 17:54 |
| cdent | presumably a service already know is owns something because it has its own database: this uuid is in me | 17:54 |
| cdent | s/is owns/it owns/ | 17:55 |
| efried | I... guess? | 17:55 |
| efried | Do we not have to be able to survive data loss? | 17:55 |
| cdent | so once again: ownership is a bit like an aggregate: a group of uuids which the client database "owns" | 17:55 |
| jaypipes | cdent: it's primarily for quota usage context. | 17:56 |
| cdent | efried: which we do you mean? | 17:56 |
| jaypipes | cdent: at least, that's what I understand. | 17:56 |
| cdent | jaypipes: I though consumer (allocation uuid) type was the crux of quota ownership, not resource provider ownership? | 17:57 |
| jaypipes | cdent: i.e. cyborg wants to use placement usage records to satisfy quota constraint logic. but if, say, nova owns a device AND cyborg owns a device, there's no way to differentiate it. | 17:57 |
| jaypipes | or that's my recollection of the use case.. | 17:57 |
| jaypipes | cdent: yes, sorry, I thought you were asking/referring about consumer type? | 17:57 |
| jaypipes | sorry I misread you. | 17:57 |
| cdent | no, we're talking about CONSUMER_OWNER_CY* | 17:58 |
| efried | My understanding (of provider ownership) was simply that the service gets to twiddle inventory of providers it owns, and not of providers it doesn't own. | 17:58 |
| cdent | sorry s/CONSUMER/CUSTOM/ | 17:58 |
| cdent | (it's all melting together) | 17:58 |
| jaypipes | like a giant melted Crunchie bar. | 17:58 |
| efried | If cyborg and nova both think they own a provider, they thrash updating details and the top wobbles off the table. | 17:58 |
| cdent | efried: why would that ever happy? | 17:58 |
| cdent | happen | 17:58 |
| cdent | (jesus, it just keeps getting worse) | 17:59 |
| efried | which, both thinking they own a provider, or both trying to update the inventory? | 17:59 |
| cdent | (the typing) | 17:59 |
| efried | (find a happen place, cdent) | 17:59 |
| cdent | both thinking they own a provider (and thus trying to update inventory) | 17:59 |
| efried | If both of them have a charter like, "I own devices". | 18:00 |
| cdent | I (perhaps naively) think that both nova and cyborg should only take action on resource providers that they can identify (by looking in _their own databases_) are theirs | 18:00 |
| cdent | nova knows it can writing on a compute node rp because it has a local record | 18:01 |
| efried | let's follow that. | 18:01 |
| cdent | nested gets harder, but nested _always_ gets harder | 18:01 |
| efried | When nova owns a device, discovery is done by...? | 18:01 |
| efried | The virt driver. | 18:01 |
| cdent | right | 18:01 |
| efried | So the virt driver looks on the system and discovers a device | 18:01 |
| efried | Then it looks in the provider tree to see whether a provider for that device already exists. | 18:02 |
| efried | And what if it does? Was it created by me on the last iteration? Or was it created by cyborg and I should leave it alone? | 18:02 |
| efried | What database am I looking at to figure that out? | 18:02 |
| jaypipes | I agree fully with cdent on the above statements. | 18:03 |
| efried | Remembering that, without some mind shift, the virt driver method has a pretty restricted view of the universe. In particular, lack of access to the database. | 18:03 |
| jaypipes | (I'm in meeting mode now, so responses will be delayed) | 18:03 |
| cdent | Right, efried, that's the bug. We don't want virt drivers to be dumb and restricted. | 18:03 |
| cdent | that constraint is causing many of the hurdles we are trying to get over | 18:04 |
| cdent | Mind you: I actually have no problem with a trait that says "cyborg is managing this rp" | 18:05 |
| efried | Okay, okay, but now you're talking about breaking down the virt driver walls, which is philosophically even huger than implementing a key/value primitive in placement. | 18:05 |
| cdent | I came along this path because I was trying to figure out why placement should care and why some kind of control and enforcement is required _in placement_. | 18:05 |
| efried | "required" is a strong word | 18:06 |
| cdent | let's gets something out of the way so that we don't have to belabor it: | 18:06 |
| edleafe | cdent: one problem with a trait that says "cyborg owns this" is that you could also add a trait that says "nova owns this". | 18:08 |
| efried | edleafe: Mentioned above, that problem exists everywhere in the API | 18:08 |
| efried | because we have rp generations, we can avoid races as long as consumers are well-behaved in terms of "claiming ownership". | 18:09 |
| cdent | in my head, except for the need for things like enforcing unary control, there is no fundamental difference (TO ME) between a sequence of bytes that we label a trait and see as "HAS_RAID_5" and a sequence of bytes that we label a key value pair and means "RAID=5", when we assert that placement has no awareness of the meanings. | 18:09 |
| edleafe | efried: yeah, but cdent just said he has no problem with that. | 18:09 |
| cdent | I recognize that this is an unrealistic flaw on my part, but that's the level of abstraction my brain is operating at about 50% of the time when we have these discussions | 18:09 |
| cdent | somebody says "key value pair" and somebody else says "a string" and I'm all "okay some ordered bytes, whatev" | 18:09 |
| efried | It's just that, once again, we find ourselves discussing these universe-bending shifts in entrenched principles, with changes that will take multiple cycles to implement, and have implications for years/ever, when it would be fully effective and immediately usable to add a handful of OWNER_* traits and use them. | 18:10 |
| cdent | I realized this is a problem, and I'm trying to fix it, and it is why I keep asking questions about what people are actually trying to do | 18:10 |
| cdent | because it is the _constraints_ that people are trying to enforce that really matter in all this, not so much what they want to enable | 18:11 |
| cdent | we can able lots and lots of things with what amounts to faceted tags | 18:11 |
| efried | yes | 18:11 |
| cdent | and if there is agreement amongst the parties involved it will "just work" | 18:11 |
| efried | easily | 18:11 |
| efried | yes | 18:12 |
| efried | whereas doing things a different way is (usually) hard | 18:12 |
| cdent | so one of the concerns that some people seem to have unary control, right? Can we make a reasonable case that allows us to dispense with that concern? If we can, what's another concern? | 18:13 |
| efried | IMO we can dispense with unary control. Generations and well-behaved consumers. If we can't count on that, the whole thing melts. | 18:13 |
| efried | dispense with unary control as a problem, that is. | 18:13 |
| cdent | I agree. We operate in an "any admin can do anything, so we rely on well behaved consumers for the whole deal" | 18:14 |
| *** e0ne has joined #openstack-placement | 18:14 | |
| efried | That's the thing. The only other concern I (still) am able to see is "architectural purity". | 18:14 |
| efried | I have a really hard time accepting that the tradeoff is worth it nearly as much of the time as we end up going that way. | 18:14 |
| *** e0ne has quit IRC | 18:14 | |
| efried | and by "that way" I mean half the time we engage in these super awkward workarounds, and half the time we simply go nowhere at all because there *isn't* a workaround. | 18:15 |
| cdent | on unary good behavior: does that mean that clients are expected to get all the traits of a resource provider, look for ONWER_* traits and wave off if found? | 18:15 |
| efried | cdent: That would be one way. | 18:15 |
| cdent | if so, that will be considered architecturally impure by some, presumably, but I agree that it is a small cosst | 18:16 |
| efried | If it freaks us out to be parsing the string, could also just look for all the values in os-traits under the owner. namespace. | 18:16 |
| efried | not sure if we run into problems with os-traits lib version there. | 18:16 |
| efried | but if we manage versions carefully, that shouldn't be a problem. | 18:16 |
| efried | Like, make sure lower-constraint is always maxed if we add an owner trait or something. | 18:17 |
| jaypipes | I don't know what you mean by "unary control" | 18:17 |
| efried | jaypipes: Can "owner" have multiple values at once? | 18:17 |
| cdent | brb | 18:17 |
| jaypipes | efried: oh... no, I don't think I know of a use case for that. | 18:17 |
| efried | Right, we don't want that to happen | 18:17 |
| efried | jaypipes: With traits (custom or standard) it can, theoretically, but with well-behaved consumers using generations properly, it's a non-issue. | 18:18 |
| efried | with an explicit provider property or (some variants of) key/value primitive, you can enforce that 'owner' only have one value. | 18:18 |
| jaypipes | efried: sorry, you lost me on that... you mean if we have an owner field on consumer, right? and consumers don't have traits decorating them... | 18:19 |
| efried | We're talking about owners on providers, still. | 18:19 |
| jaypipes | oh... | 18:19 |
| *** mriedem has joined #openstack-placement | 18:20 | |
| cdent | efried: for sake of mind shaking about and noodling what about [t 1sHq] | 18:33 |
| purplerbot | <cdent> so once again: ownership is a bit like an aggregate: a group of uuids which the client database "owns" [2018-10-01 17:55:42.087707] [n 1sHq] | 18:33 |
| efried | Predicated on having access to said database | 18:33 |
| efried | Also assuming something like hot unplug doesn't leave you with no database entry, but a stale provider that *someone* has to get rid of. Theoretically the same entity removing the db entry would be responsible for removing the provider - but again, if nova (non-virt) manages the db and virt manages the providers (well, non-virt does the actual updates, but without introspecting what the virt driver twiddled) then we h | 18:37 |
| *** e0ne has joined #openstack-placement | 18:37 | |
| cdent | fair point | 18:38 |
| openstackgerrit | Chris Dent proposed openstack/placement master: DNM: Experimenting with integration gabbits https://review.openstack.org/601614 | 20:35 |
| openstackgerrit | Chris Dent proposed openstack/placement master: WIP: Add placeload to integration test https://review.openstack.org/602484 | 20:35 |
| *** mriedem has quit IRC | 20:42 | |
| *** e0ne_ has joined #openstack-placement | 20:54 | |
| *** e0ne has quit IRC | 20:54 | |
| jroll | efried: I like the general idea of these config blobs being able to affect scheduling like that | 21:41 |
| efried | jroll: Yeah, I like the idea as well. What I don't like is that it's going to take like three person-cycles to get it implemented. | 21:42 |
| jroll | efried: well, hopefully we can agree the end goal and make smaller steps to get there | 21:42 |
| efried | jroll: I, for one, would love to see the first step be, "use what we've got, acking that it's temporary until we get the real thing in place" | 21:43 |
| efried | because that we can get done in three weeks. | 21:43 |
| cdent | which idea is the "config blobs" one? | 21:43 |
| efried | cdent: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135319.html | 21:44 |
| jroll | efried: right, but without the end goal, we won't know if the temporary thing is a step forward on that path, ya know? | 21:44 |
| cdent | thanks efried | 21:44 |
| jroll | cdent: I was referring to jay's suggestion, but eric builds on it | 21:44 |
| efried | cdent: actually, here is where jaypipes introduced the idea: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135300.html | 21:44 |
| efried | jroll: I dig it. | 21:45 |
| efried | I'm guessing this is the spec jaypipes is working on, which he alluded to in the "intended purpose" thread. | 21:46 |
| jroll | indeed | 21:46 |
| efried | oh, yeah, he says so at the bottom. | 21:46 |
| cdent | so that would be a chance of some kind to the compute api, yes? | 21:47 |
| cdent | (along with other things) | 21:47 |
| jroll | cdent: yes | 21:48 |
| * cdent goes to bed | 21:51 | |
| cdent | g'night all | 21:51 |
| *** cdent has quit IRC | 21:51 | |
| *** e0ne_ has quit IRC | 22:04 | |
| *** e0ne has joined #openstack-placement | 22:05 | |
| *** e0ne has quit IRC | 22:06 | |
| *** mriedem has joined #openstack-placement | 22:36 | |
| *** efried has quit IRC | 22:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!