| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-06 | |||
| 19:32:25 | mriedem | cfriesen: is that from your team? ^ | |
| 19:33:30 | dansmith | mriedem: I didn't, but I saw it and thought "I should read that" | |
| 19:33:48 | mriedem | dansmith: ok, i'm just about to push the updated spec mentioning the issue, along with some other issues | |
| 19:33:52 | dansmith | cool | |
| 19:37:20 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: List instances using Searchlight (spec) https://review.openstack.org/441692 | |
| 19:37:28 | mriedem | cdent: gibi: ^ comments addressed, thanks for the review on that | |
| 19:40:27 | logan- | mriedem: (re: 442126) not from cfriesen's team, just me. hopefully I didn't miss any steps in the docs before pushing that. first patch in nova. | |
| 19:41:04 | mriedem | logan-: ok, cfriesen and the windriver team have something similar i'm told, and we talked about it at the ptg so figured it was his team pushing that up | |
| 19:41:11 | mriedem | since there is general interest | |
| 19:42:02 | mriedem | logan-: this is small enough that we probably don't need a spec, but you should probably mention the blueprint during the weekly nova meeting durin the 'open discussion' section | |
| 19:42:16 | mriedem | http://eavesdrop.openstack.org/#Nova_Team_Meeting | |
| 19:42:26 | logan- | sounds good. I wasn't sure if it was specless or not, so I figured i'd just push it and see. will make sure to be at the meeting this week. | |
| 19:42:46 | logan- | thanks | |
| 19:42:52 | mriedem | yw | |
| 19:49:37 | openstackgerrit | Sarafraj Singh proposed openstack/nova master: conf: remove console_driver opt https://review.openstack.org/441485 | |
| 20:01:09 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova-specs master: Stop using Neutron admin token https://review.openstack.org/439890 | |
| 21:02:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: virt: add get_inventory() virt driver API method https://review.openstack.org/441543 | |
| 21:02:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: virt: implement get_inventory() for Ironic https://review.openstack.org/441544 | |
| 21:02:17 | jaypipes | mriedem: ^^ addressed your concerns | |
| 21:03:28 | mriedem | jgriffith: do you have time to talk with alexandrelevine about the scaleio ephemeral driver for nova? | |
| 21:04:13 | alexandrelevine | jgriffith: hi | |
| 21:04:33 | jgriffith | alexandrelevine hi | |
| 21:04:44 | jgriffith | mriedem alexandrelevine can you give me about a 1/2 hour? | |
| 21:04:52 | jgriffith | maybe less? | |
| 21:05:05 | alexandrelevine | jgriffith: Ok. | |
| 21:06:11 | jgriffith | alexandrelevine never mind, I'm available (you forget to include a dial in for a meeting invite you're out of luck) | |
| 21:06:24 | alexandrelevine | :) | |
| 21:06:40 | jgriffith | alexandrelevine :) | |
| 21:06:49 | jgriffith | soon they won't invite me at all :) | |
| 21:06:54 | alexandrelevine | So there is a problem with the ScaleIO ephemeral driver. And it's mostly historical and resource-wise. I'll explain. | |
| 21:07:00 | jgriffith | alexandrelevine sure | |
| 21:07:29 | alexandrelevine | We started doing it 1.5 years ago when we worked for EMC. And we were postponed because at the time a refactoring started in the same area - imagebackend.py | |
| 21:08:03 | alexandrelevine | We were told that it'll go fast and well but as often it didn't. So we were postponed once. And then twice because of communicational and organizational reasons. | |
| 21:08:10 | alexandrelevine | And now seems to be the third time. | |
| 21:08:29 | alexandrelevine | All this time we had to support patches for new versions of nova and ScaleIO aside from the main code. | |
| 21:08:49 | jgriffith | alexandrelevine so to be clear I have the luxury of being able to claim "not being involved" in any past efforts :) | |
| 21:08:51 | alexandrelevine | Now we've left EMC and we don't have enough resources to keep doing this cumbersome tasks. | |
| 21:09:05 | jgriffith | so while I feel for ya, I don't necessarily have anything to say about that | |
| 21:09:10 | jgriffith | alexandrelevine Ahh! | |
| 21:09:22 | jgriffith | Well so you just made a case for my number one argument :) | |
| 21:09:23 | alexandrelevine | But because of what we did we know the area quite well. | |
| 21:09:46 | jgriffith | alexandrelevine if you don't have enough resources, why wouldn't you want to make life easier and get it for free from a community based Cinder driver? | |
| 21:09:53 | alexandrelevine | jgriffith: we're willing to finish the work we started and to support it in the future though, don't be mistaken :) | |
| 21:09:58 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Get instance availability_zone without hitting the api db https://review.openstack.org/439754 | |
| 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 | |