| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-28 | |||
| 13:32:49 | efried | okay. The deprecated options still work, so it's not crucial. | |
| 13:33:04 | stephenfin | I think doc patches should go back to Pike though. Maybe sdague would have some thoughts on the matter? | |
| 13:33:11 | stephenfin | Oh, so it would actually | |
| 13:33:52 | sdague | stephenfin: which doc patches? | |
| 13:34:03 | stephenfin | sdague: https://review.openstack.org/#/c/498461/1 | |
| 13:34:17 | openstackgerrit | Eric Fried proposed openstack/nova master: [Trivial] docstrings, typos, minor refactoring https://review.openstack.org/493701 | |
| 13:34:47 | efried | stephenfin Rebased ^ on top | |
| 13:35:09 | sdague | yeh, admin guide stuff should go back as it's all published per release | |
| 13:35:38 | stephenfin | efried: Odd. I expected the +2 to disappear. Apparently not | |
| 13:36:15 | efried | stephenfin When gerrit recognizes an auto rebase, it carries code reviews forward. | |
| 13:36:23 | efried | Which is *almost* always okay :) | |
| 13:38:49 | efried | stephenfin sdague https://review.openstack.org/#/c/498463/ is the pike cherry-pick. So should I go make the change in ocata too? | |
| 13:40:06 | sdague | efried: no, the admin guide is not in ocata | |
| 13:40:20 | efried | sdague Okay, that's why I can't find it :) | |
| 13:40:24 | sdague | yep | |
| 13:40:26 | efried | That doc must have existed somewhere? | |
| 13:40:30 | efried | Just in spec form mebbe? | |
| 13:40:34 | sdague | on the openstack manuals side | |
| 13:41:07 | sdague | only in pike did the manuals go in tree for nova | |
| 13:42:12 | efried | sdague Right; so my question is whether I should go find and update that manual wherever it lived in ocata | |
| 13:44:15 | stephenfin | efried: I don't think they versioned the admin guide either, so there's nothing to backport to for Ocata | |
| 13:44:26 | sdague | yeh, I'm not sure I would bother | |
| 13:44:30 | efried | cool cool. | |
| 13:58:47 | mriedem | gmann: i'm not sure https://review.openstack.org/#/c/490722/ warrants a microversion bump | |
| 13:58:56 | mriedem | should probably be discussed in the nova-api meeting this week | |
| 14:00:01 | cdent | mriedem: i rebased your shared providers functional test again. same deal as last time: leaving the failing tests with TODOs. I did make a couple of tweaks to report client in the patch above it to get a few more things passing | |
| 14:01:53 | mriedem | cdent: that was pretty incomplete from what i remember | |
| 14:02:11 | mriedem | i know i need to abandon the wip for the fixes in the report client | |
| 14:02:26 | cdent | It was but there were a couple of simple syntax thingies that move it forward a bit | |
| 14:21:56 | sdague | mriedem: https://review.openstack.org/#/c/496515 is probably worthy of backport | |
| 14:22:31 | sdague | I push for pike, what do you think about ocata as well? | |
| 14:23:27 | kashyap | sdague: Randomly chiming in, it sounds like backport-worthy, given the description | |
| 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. | |