| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-28 | |||
| 14:24:20 | mriedem | seems pretty low probability | |
| 14:24:46 | mriedem | wouldn't this be someone creating 2 instances with the same name on separate requests ~the same time? | |
| 14:24:56 | sdague | mriedem: no | |
| 14:25:11 | sdague | there is no name uniqueness requirement | |
| 14:25:24 | sdague | or, it's behind a config option, off by default | |
| 14:25:41 | sdague | so, it is 2 different requests, but they can be at any time | |
| 14:26:26 | mriedem | as long as you didn't delete the other first? | |
| 14:26:58 | sdague | yes | |
| 14:27:05 | sdague | but it could be made by a different tenant | |
| 14:27:43 | mriedem | this is fine to backport. it's unfortunate that a 2 line code fix requires 100+ LOC change for tests | |
| 14:27:57 | sdague | well, they tried to be comprehensive there | |
| 14:27:58 | mriedem | i assume that's just because of how tightly coupled this all ways to the driver when it was moved out of the driver and into the host module | |
| 14:28:01 | sdague | yeh | |
| 14:28:24 | kashyap | Yeah, the tests seem to be trying to be a bit more comprehensive | |
| 14:28:40 | sdague | mriedem: before I approve this change of yours, you want to put in newlines to the output for readability - https://review.openstack.org/#/c/486660 ? | |
| 14:34:23 | openstackgerrit | Alex Szarka proposed openstack/nova master: Reduce code complexity - instance.py https://review.openstack.org/359878 | |
| 14:41:14 | openstackgerrit | Elod Illes proposed openstack/nova master: Functional test: evacuate with no compute https://review.openstack.org/498482 | |
| 14:47:21 | mriedem | sdague: it's going to be a bit | |
| 14:49:56 | mriedem | sdague: please redo those cherry picks using the -x option | |
| 14:59:41 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: SPICE native client support https://review.openstack.org/442040 | |
| 15:00:55 | dansmith | cdent: it's still totes possible and should be on the radar for sure, but we've got a giant mess at the moment, and a bunch of unfinished bits that are way higher priority, IMHO | |
| 15:00:56 | mriedem | cdent: i don't really see any reason why placement couldn't be split out, we're doing everything over the microversions onw | |
| 15:00:57 | mriedem | *now | |
| 15:01:21 | mriedem | right, was going to say, the only thing/reason to not focus on the split right now is the existing amount of stuff we have to do | |
| 15:01:36 | dansmith | especially since it's its own catalog entry, I don't think it's noticeably a nova thing to any other project other than where the code lives | |
| 15:01:46 | dansmith | yeah | |
| 15:02:15 | edleafe | dansmith: one concern was the choice to shove everything in resource_providers.py | |
| 15:02:21 | edleafe | until the split | |
| 15:02:40 | cdent | dansmith: yeah, your response points to a more detailed question: if those unfinished things are going to take a while and starting on moving things will disrupt them, there’s little point to start the extraction process soonish | |
| 15:02:41 | mriedem | was that a conscious choice? | |
| 15:03:03 | dansmith | I'm not sure what the single file has to do with anything, | |
| 15:03:13 | dansmith | and I've complained along the way that that file is too fat already | |
| 15:03:23 | mriedem | if you want to create nova/objects/alternative_hosts.py that's fine | |
| 15:03:28 | dansmith | if splitting things out of there is helpful, then | |
| 15:03:30 | dansmith | right | |
| 15:04:02 | edleafe | mriedem: yes, because having placement in Nova was always supposed to be a temporary thing, and single file would make separation easier | |
| 15:04:29 | openstackgerrit | Elod Illes proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280 | |
| 15:05:44 | mriedem | i don't see how it makes it really any easier | |
| 15:06:12 | mriedem | like, if we have 1 objects module or 10, that's not going to be the pain in the split | |
| 15:06:14 | cdent | assuming it is contained (down collabortion without adding up collaboration) | |
| 15:06:21 | edleafe | mriedem: I think the idea was it would keep us from scattering placement code throughout nova | |
| 15:06:29 | mriedem | sure that's fair | |
| 15:06:29 | cdent | jinxish | |
| 15:06:42 | mriedem | but that's not going to be the painful part | |
| 15:06:47 | dansmith | not at all | |
| 15:06:59 | mriedem | i imagine the db will be the hardest | |
| 15:07:01 | cdent | collabortion is my neologism of the day. I’ll have to figure out what it means. | |
| 15:07:20 | edleafe | mriedem: sure, it's just not adding to that pain | |
| 15:07:21 | cdent | db doesn’t have to be hardest. | |
| 15:07:25 | cfriesen_ | it's when you have too many people working on something and they mess it up. :) | |
| 15:07:36 | cdent | a) we have code for it already, b) we don’t need to use a different db | |
| 15:07:56 | mriedem | cdent: you don't think at some point people will want to use a placement db without the nova_api db schema? | |
| 15:08:00 | mriedem | like build_requests and instance_mappings? | |
| 15:08:03 | cdent | cfriesen_: works, thanks! | |
| 15:08:22 | mriedem | and have a placement user that can access that db rather than the nova user? | |
| 15:08:50 | cdent | we have _some_ of that already | |
| 15:08:57 | mriedem | i'd think you could do something during transition where reads start in the placement db and if not found, fallback to the nova_api db, and eventually you drop that transition code | |
| 15:09:03 | mriedem | like when we move things from the nova db to the nova_api db | |
| 15:09:24 | dansmith | or | |
| 15:09:31 | cdent | but really why not just keep using the nova api db? | |
| 15:09:45 | cdent | (that’s a question not a suggestion) | |
| 15:09:45 | dansmith | make the first post-split db migration drop the non-placement tables and just require people to do a snapshot/move of their api db to get placement isolated | |
| 15:09:51 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: config drive https://review.openstack.org/409404 | |
| 15:10:27 | mriedem | well, why not just keep placement in nova then? :) | |
| 15:10:36 | mriedem | if we're going to split it out, we should split it out | |
| 15:10:44 | cdent | for sake of memory: https://review.openstack.org/#/c/362766/ https://github.com/cdent/placement | |
| 15:10:49 | edleafe | cdent: sure it could, but if I wanted to just run placement, why do I need nova-api stuff? | |
| 15:11:26 | cdent | edleafe: thank you. that leads to a useful answer: so I can run placement without nova having to exist. | |
| 15:11:29 | mriedem | right, ironic and cinder will write to placement for k8s stuff (in some future world) | |
| 15:12:43 | cdent | dansmith: a snapshot followed by a drop migration is a good idea | |
| 15:13:18 | cdent | would it be easier to do that in tooling instead of in placement itself? | |
| 15:14:34 | mriedem | we'd expect that in deployment tooling, not placement | |
| 15:14:50 | mriedem | e.g. grenade | |
| 15:15:18 | dansmith | the snapshot yeah | |
| 15:15:21 | dansmith | but not the drop, IMHO | |
| 15:15:28 | cdent | I meant the drop too | |
| 15:15:31 | dansmith | but again, I think this is a distraction to even condsider | |
| 15:15:33 | mriedem | the drop of instance_mappings, build_requests, etc is fine in placement itself | |
| 15:15:53 | dansmith | (at the moment) | |
| 15:16:12 | mriedem | i'm ok if cdent wants to tease out the ideas if he wants to anyway, | |
| 15:16:18 | mriedem | but i don't consider it a project priority atm | |
| 15:16:44 | dansmith | no, I demand cdent not even think about it! | |
| 15:16:49 | cdent | dansmith: yeah, that’s what I’m trying to find out. If everyone agrees with you, cool. mriedem: I’d personally prefer placement’s db handling to be clean slate, no migrations etc | |
| 15:16:58 | dansmith | of course, I just don't want to get into a long discussion about it at this stage, is all | |
| 15:17:13 | cdent | dansmith: I’ll stop thinking if you promise to do my thinking for me henceforth. I could do with the break. | |
| 15:17:34 | mriedem | i'm not sure what i *think* about that | |
| 15:17:42 | mriedem | i'll be here all week | |
| 15:18:12 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640 | |
| 15:18:15 | dansmith | mriedem: so for this migration spec, do you want the spec to be for "use uuid to hold allocations during a migration" or just "migrations should have uuids because uuids are great" ? | |
| 15:18:38 | mriedem | the former | |
| 15:18:47 | dansmith | yeah okay | |
| 15:19:03 | mriedem | the problem statement is really related to the issues we found with move operations in pike with ocata computes overwriting n stuff | |
| 15:20:10 | mriedem | also have to think about at what point is the allocation dropped from the source node, and the migration consumer allocation 'transferred' to the instance consumer | |
| 15:20:33 | mriedem | maybe that's just a single PUT /resource_providers/uuid/allocations call? | |
| 15:21:13 | dansmith | um, say what? you mean on a revert? | |
| 15:23:11 | sdague | mriedem: yeh, can do, I guess that is done automatically after it's a landed patch? | |
| 15:23:18 | sdague | I was just using the gerrit ui | |
| 15:27:21 | mriedem | sdague: yeah for gerrit ui to do it the original has to be merged | |
| 15:27:40 | sdague | gotcha, yeh, I'll redo after the master merge. My bad | |
| 15:27:47 | mriedem | dansmith: doesn't the allocation on the dest node at some point have to transfer from the migration object to the instance object? | |