| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-06 | |||
| 18:44:51 | mriedem | jgriffith: well, the assertions made in the scaleio spec are kind of scary and i assume you would disagree with at least part of them | |
| 18:45:15 | mriedem | jgriffith: so just bringing that to your attention, but yeah at some point sooner than later we'll want to start looking at a spec | |
| 18:45:17 | jgriffith | mriedem yeah, I'm going through it now | |
| 18:45:23 | jgriffith | mriedem thanks for raising it | |
| 18:45:26 | mriedem | https://review.openstack.org/#/c/91321/ was also an old spec, | |
| 18:45:30 | mriedem | but apparently lacking a lot of details | |
| 18:45:50 | jgriffith | mriedem best kind of spec is the spec with no details | |
| 18:45:51 | jgriffith | then you can't be held accountable :) | |
| 18:45:51 | mriedem | probably not even worth getting distracted by it | |
| 18:50:10 | mriedem | that reminds me, i need to hedge in my searchlight spec about the fact you won't be able to list deleted instances if nova is using searchlight | |
| 18:50:17 | mriedem | dansmith: ^ did you read my email on that? | |
| 18:50:43 | mriedem | i probably need that in the cells meeting agenda | |
| 18:51:11 | edmondsw | mriedem, tx for the ping. It's a good question. I will talk to some folks here to figure out how important log translations are. My current understanding is that yes, we need those | |
| 18:51:45 | mriedem | edmondsw: you'll have to pony up some translators probably :) | |
| 18:52:02 | edmondsw | mriedem I've actually been trying to make that case... | |
| 19:21:35 | openstackgerrit | Logan V proposed openstack/nova master: Add LVM thin pool support https://review.openstack.org/442126 | |
| 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: implement get_inventory() for Ironic https://review.openstack.org/441544 | |
| 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: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: Enlighten server tags API about cells https://review.openstack.org/440856 | |
| 21:09:59 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022 | |
| 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: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: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: Add cell field to Destination object https://review.openstack.org/438024 | |
| 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:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388 | |
| 21:10:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162 | |
| 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 | |