| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-28 | |||
| 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 | cdent | jinxish | |
| 15:06:29 | mriedem | sure that's fair | |
| 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 | 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:45 | cdent | (that’s a question not a suggestion) | |
| 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? | |
| 15:28:05 | mriedem | especially if we ever count usage using placement for quota stuff | |
| 15:28:35 | dansmith | mriedem: well I was going to do it the other way: | |
| 15:29:17 | dansmith | mriedem: replace the source allocation with one for the migration, then allocate for the instance on the destination, assuming that's the expected end state | |
| 15:29:55 | mriedem | and once the move is done, drop the migration allocation from the source node | |
| 15:29:57 | mriedem | that works too | |
| 15:30:01 | dansmith | right | |
| 15:30:30 | dansmith | there is a gotcha in there in that we need space on the source to claim again for the size of the instance, but we could fix that with another operation against placement letting us do an atomic swap | |
| 15:44:07 | openstackgerrit | Merged openstack/nova master: Don't warn on expected network-vif-unplugged events https://review.openstack.org/465794 | |