| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-06 | |||
| 21:09:59 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022 | |
| 21:09:59 | openstackgerrit | Dan Smith proposed openstack/nova master: Enlighten server tags API about cells https://review.openstack.org/440856 | |
| 21:10:00 | openstackgerrit | Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891 | |
| 21:10:00 | openstackgerrit | Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |
| 21:10:01 | openstackgerrit | Dan Smith proposed openstack/nova master: Make consoleauth target the proper cell https://review.openstack.org/441461 | |
| 21:10:02 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025 | |
| 21:10:02 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024 | |
| 21:10:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162 | |
| 21:10:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388 | |
| 21:10:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163 | |
| 21:10:17 | jgriffith | alexandrelevine but you won't be able to support it fully? (ie your comment about resources) | |
| 21:10:28 | alexandrelevine | But to start all over again and to do the cinder backend might not be in our power at the moment. | |
| 21:10:46 | alexandrelevine | We would be able to support fully the ScaleIO code we created. | |
| 21:11:00 | alexandrelevine | But we don't have resources to start over from another angle. | |
| 21:11:24 | alexandrelevine | Also as I said we know the area quite well - I did a POC for the total refactoring as well. | |
| 21:11:35 | alexandrelevine | So there some tricky parts and design problems. | |
| 21:11:47 | mriedem | alexandrelevine: can you explain the issues that you think will be a major issue for the generic cinder driver? | |
| 21:11:49 | alexandrelevine | And the code to work with is far from the ideal state. | |
| 21:12:06 | alexandrelevine | The same as for other ephemeral drivers. Namely: | |
| 21:12:23 | alexandrelevine | 1. Entangled code to introduce changes into. | |
| 21:12:54 | alexandrelevine | 2. Tricky operations like live migration and resizing, pieces of which are evenly spread around two files. | |
| 21:13:17 | alexandrelevine | 3. Specifics of behavior like 8-gb granular disk allocations for ScaleIO. | |
| 21:13:26 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: The ResourceProviderTraits API - Manage traits with ResourceProviders https://review.openstack.org/345138 | |
| 21:13:42 | alexandrelevine | 4. Specifics of implementation like necessity to map/unmap ScaleIO volumes to host unlike for ceph | |
| 21:13:46 | alexandrelevine | And such... | |
| 21:14:06 | jgriffith | alexandrelevine but the Cinder approach would require handling all of those for ALL backends no? | |
| 21:14:08 | mriedem | how do 3 and 4 not get handled by cinder and os-brick? | |
| 21:14:13 | jgriffith | with the exception of #3 | |
| 21:14:50 | alexandrelevine | It would take some design decisions, communications between interested parties, talks, reviews, etc. With the usual round-trips for all of this, realistically, it's 2-3 releases at the best. Of course if it was all in one organization it could've be done in month or two. But that's not the case. | |
| 21:14:55 | mriedem | for #2, wouldn't live migration and resize work the same as for boot from volume? | |
| 21:15:51 | alexandrelevine | jgriffith: Abouth the #4. I'm not sure. It might. But most probably it won't. | |
| 21:16:10 | jgriffith | alexandrelevine well I don't think that's necessarily true, I certainly hope not | |
| 21:16:24 | jgriffith | I'm honestly hoping that this is something that we can somehow pull of in this cycle | |
| 21:16:39 | jgriffith | otherwise I'll go back to pushing my flavor-extra-specs proposal and forget all of it :) | |
| 21:16:43 | jgriffith | alexandrelevine so seriously... | |
| 21:16:57 | jgriffith | alexandrelevine I get where you're coming from and I understand you've already invested a lot perhaps | |
| 21:16:58 | jgriffith | BUT | |
| 21:17:02 | alexandrelevine | jgriffith: There is a number of different disk types in nova - local/root/config/volume - some of which are intermingled with other. So I'm not sure that mapping/unmapping would be enough to be done outside. Probably but not necessarily | |
| 21:17:17 | jgriffith | I think it's fundamentally WRONG to continue doing all these one offs for just one particular vendors interests | |
| 21:17:31 | jgriffith | especially if/when we all have a common interest in achieving the same thing | |
| 21:17:48 | jgriffith | why not utilize your resources and efforts to better the entire project and not just your product? | |
| 21:17:55 | alexandrelevine | jgriffith: They honestly hoped that they'd pull the refactoring in 1 month. It still goes. And that's exactly same area with the same problems. | |
| 21:19:00 | mriedem | alexandrelevine: i don't remember anyone claiming the entire imagebackend refactor what mdbooth was doing in newton would be done in a month | |
| 21:19:02 | alexandrelevine | jgriffith: Our stuff is already done and ready. New thing - is a significantly much more work for us. | |
| 21:19:05 | jgriffith | I've had the same debates in Cinder WRT other things EMC has proposed (VIPER, CPRHD...) so while I sympathize I can say that you're very unlikely to change my opinion on this | |
| 21:19:13 | alexandrelevine | mriedem: I remember | |
| 21:19:14 | jgriffith | others have tried for years :) | |
| 21:19:28 | alexandrelevine | mriedem: We were told that it'll be done by June and then we'll add our code. | |
| 21:20:45 | mriedem | anyway, that effort derailed and we talked about it in BCN, and it's not being worked now i don't think, | |
| 21:21:00 | alexandrelevine | jgriffith: At the moment people which added ploop as I know proceed with changing the code. I'd suggest to let ScaleIO in along with starting the work on cinder backend. This way people would get the only really competing to ceph storage backend soon. Otherwise - time is indefinite. | |
| 21:21:09 | jgriffith | alexandrelevine lucky for you I carry no weight on the Nova team, but honestly I think it'd be irresponsible to move forward with a one-off solution as opposed to workign on a generalized approach | |
| 21:21:16 | mriedem | and what i'm hearing is, adding a generic cinder driver is going to be hard because the code is a hot mess, and because the scaleio work has been going on for over a year, you've dealt with that mess | |
| 21:21:59 | alexandrelevine | mriedem: Yes. And as I said I dealt even more with that mess when I proposed the POC for that same refactoring so I think I correctly estimate the picture. | |
| 21:22:00 | mriedem | so rather than start over on the hard thing that everyone wants, add another special backend and all of the conditionals that go along with in the libvirt driver code | |
| 21:22:06 | sdague | cburgess: just for you - http://docs-draft.openstack.org/03/441203/8/check/gate-keystone-specs-docs-ubuntu-xenial/923ac60//doc/build/html/specs/keystone/backlog/hierarchical-quota-scenarios.html#make-chet-sad-model | |
| 21:22:35 | mriedem | alexandrelevine: i also don't really see what motivation your team has for maintaining this once it's in tree unless you're getting paid to maintain it | |
| 21:23:14 | alexandrelevine | mriedem: Me neither. But we're doing it right now. Maybe we just don't like to drop what we're responsible for. | |
| 21:23:48 | alexandrelevine | mriedem: And part-time participation is not such a big load on us comparing to, say, a full month work. | |
| 21:23:50 | mriedem | alexandrelevine: i can see that, i worked on getting db2 support into nova for 2 years, and then we ripped it out about 6 months later because ibm stopped supporting it upstream | |
| 21:24:18 | mriedem | however, i'm not trying to get db2 back into nova | |
| 21:24:28 | alexandrelevine | mriedem: Don't mind if we rip ScaleIO out in favor of ready cinder backend even a week after. It just has to work. | |
| 21:24:50 | jgriffith | alexandrelevine honestly I would've thought based on your statements you'd prefer the general cinder driver approach. | |
| 21:24:56 | mriedem | alexandrelevine: removing things is harder than just adding them in and letting them rot | |
| 21:25:05 | alexandrelevine | mriedem: I just fill sort of responsible for the unfinished solution and we don't have much resources to keep patching it aside - it's even more work. | |
| 21:25:07 | jgriffith | alexandrelevine you already stated you don't have resources to work on / maintain the effort | |
| 21:25:12 | mriedem | jgriffith: i'm sure they do, but they don't favor the investment in doing the new thing, or waiting for it | |
| 21:25:26 | jgriffith | alexandrelevine you know as well as anybody that this code isn't static | |
| 21:25:38 | mriedem | alexandrelevine: if EMC cares about it, then xing-yang's team would own rebasing it shouldn't they? | |
| 21:26:00 | jgriffith | mriedem ahh... well; I don't favor this option either, but I'm willing to try it to do something that better satisfies everyone involved | |
| 21:26:12 | alexandrelevine | jgriffith: Architecturally - absolutely. We even discussed when we designed the solution. But knowing the problems we decided to go for smaller, more safe thing. Thinking that it'll be much less time, especially after verbal confirmations. | |
| 21:26:28 | mriedem | jgriffith: which option? add the scaleio driver in until the generic driver shows up and then remove the scaleio driver? | |
| 21:26:37 | alexandrelevine | mriedem: exactly | |
| 21:26:43 | jgriffith | mriedem flavor :). Just ignore that | |
| 21:27:12 | alexandrelevine | mriedem: They don't have sufficient expertise to start new thing at the moment but to help support ours - it's possible. | |
| 21:28:50 | mriedem | but again, you no longer work for EMC and while it's nice you say you'd support it anyway, i don't see that happening in 6 months just from a purely motivational aspect, which is why i'd think that if EMC cares about this they'd have people backfilling your team to support this | |
| 21:29:06 | jgriffith | alexandrelevine wait... you're saying Xing's team doesn't have the expertise? I'd argue strongly against that statement | |
| 21:29:18 | alexandrelevine | jgriffith: By the way - this code is quite static, by the way :) Any attempts in refactoring have failed as I understand. | |
| 21:29:39 | alexandrelevine | mriedem: They do. | |
| 21:30:23 | jgriffith | alexandrelevine here's the thing... I want this feature as per customer requests for SolidFire | |
| 21:30:24 | alexandrelevine | mriedem: They care about this direction. But I said that we'll finish because any new guys would take time to get into the code and the nova procedures and processes so again 2-3 more releases at the best. | |
| 21:30:54 | jgriffith | alexandrelevine so if you go this route, then that means I go this route... then Pure does the same, then <insert-1-of-100-cinder-backends-here> go this route | |
| 21:30:56 | jgriffith | that's stupid | |
| 21:31:17 | jgriffith | Sure, it'd be easier for me to do it this way too, but that doesn't mean it's a good idea | |
| 21:31:19 | alexandrelevine | jgriffith: You can call it stupid, but that's reality. | |
| 21:31:41 | alexandrelevine | jgriffith: I wouldn't recommend to go the same way again now that everybody is pro universal backend. | |
| 21:31:43 | jgriffith | alexandrelevine wait.. to be clear, I'm saying if we had 100 backends image drivers in Nova that would be stupid | |
| 21:31:47 | jgriffith | not what you're doing is stupid | |
| 21:32:09 | alexandrelevine | jgriffith: I'd suggested to start with it. It's about the same amount of work. No need to create SolidFire specific piece. | |
| 21:32:21 | jgriffith | LOL | |
| 21:32:32 | alexandrelevine | :) | |
| 21:32:34 | jgriffith | so it's no good for you, but good for everyone else :) | |
| 21:32:38 | mriedem | to be clear, i'm not going to support 100 cinder drivers in nova | |
| 21:32:47 | jgriffith | mriedem no? Damn! | |
| 21:32:51 | mriedem | which is why we want to stop doing this | |
| 21:32:56 | jgriffith | mriedem +1 | |
| 21:33:06 | jgriffith | mriedem and that's why I never even bothered trying to go down that path | |
| 21:33:09 | mriedem | because i'm sure veritas is wanting the same thing | |
| 21:33:23 | mriedem | veritas has been pushing specs for the same stuff | |
| 21:33:34 | alexandrelevine | Guys I totally agree with stopping doing it. I'm just saying that if you stop BEFORE Scaleio is in it means that it'll be out for 2-3 more releases. | |
| 21:34:16 | alexandrelevine | I tell you what. We can even consider doing or helping doing the cinder driver in nova. | |