Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-06
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.
21:34:31 alexandrelevine Because it's interesting and we're quite into it.
21:35:10 alexandrelevine But not as a replacement for now-ready ScaleIO. In more relaxed schedule and if Randy approves because we still work with him.
21:35:24 jgriffith Randy?
21:35:29 alexandrelevine Randy Bias.
21:35:57 alexandrelevine Basically almost all of our efforts in OpenStack are his ideas.
21:36:03 dansmith lol
21:36:27 alexandrelevine He might approve by the way if he sees that it's really needed.
21:38:05 jgriffith alexandrelevine ok, so look from my perspective; it's the wrong direction.
21:38:21 jgriffith alexandrelevine I feel for ya in terms of investment etc but my vote is generalized solution
21:38:28 jgriffith alexandrelevine I'm sorry about that
21:38:54 mriedem alexandrelevine: jgriffith: i was mostly looking for input on the specific issues that are going to delay the cinder backend,
21:38:59 alexandrelevine jgriffith: generalized solution with "no" for the specific one for now?
21:39:03 mriedem alexandrelevine: i'm not asking your team to write that code,
21:39:04 jgriffith but it's the right thing to do in terms of the overall project and it's the "fair" thing to do in terms of vendors and MOST OF ALL it's the right thing to do in terms of cloud deployers
21:39:21 jgriffith alexandrelevine correct, no specific drivers
21:39:23 mriedem but we obviously need to start with a spec and detailing the issues that are going to be hit with this will help give a better idea of how long and risky that's going to be
21:39:53 jgriffith alexandrelevine I sincerely would hope you and your team would help in the effort given you have vast experience and interest
21:40:02 alexandrelevine mriedem: You did that with imagebackend refactoring. Did it help you to predict 1.5 years and failure in the end?
21:40:18 jgriffith but if you can't/don't then that's ok too; doesn't change my opinion
21:40:49 alexandrelevine mriedem: What if you spend 2 months on the spec and find it risky and difficult or just difficult and taking 2-3 more releases?
21:40:52 mriedem i don't have enough info to make a judgement call on whether or not we should take on the technical debt for the backend that may or may not be supported, unless i have a better understanding of how hard it's going to be to get the cinder driver done
21:42:00 alexandrelevine mriedem: What I'm saying is that the question is - when did you get clear and correct specs of that complexity in this area? I'm again referring to the refactoring spec/specs.
21:42:20 alexandrelevine Ours is good because we have the code which works for 1.5 year already.
21:42:55 alexandrelevine mriedem: Who'll right such a spec? Who has a thorough enough expertise?
21:43:00 mriedem alexandrelevine: the imagebackend refactor failed for different reasons
21:43:13 alexandrelevine "write"
21:44:26 alexandrelevine I just want to remind that in order to provide my design ideas for refactoring I had to develop the whole solution and make it pass all of the existing tests. Then I was sure that my ideas would work and I was ready to write a spec.
21:49:59 alexandrelevine mriedem: Please let me know when the conversation is finished and you made up your mind with some verdict because it's 0:49 am here and unless we keep talking I can go and get some sleep.
21:51:28 mriedem alexandrelevine: i think i'm done right now. i'm not ready to add the scaleio specific driver without having a better idea of how the generic driver would happen (or not happen).
21:52:41 alexandrelevine mriedem: Ok, thank you. Do we abandon our spec or just leave it be?
21:52:56 mriedem alexandrelevine: i'd leave it for now
21:53:12 alexandrelevine Ok. Bye.
22:29:16 mriedem jgriffith: dumped my recap notes on the talk with alex in https://review.openstack.org/#/c/304715/
22:41:44 mriedem dansmith: i moved your nova meeting stuff on the forum planning into the reminders section since it's something that will probably continue to come up as we get closer
22:41:51 mriedem like for the ptg planning
22:41:52 dansmith mriedem: cool
22:51:45 ildikov mriedem: hi, are you around for a quick question?
22:52:34 mriedem ildikov: i am
22:52:42 ildikov mriedem: tnx
22:52:52 ildikov mriedem: so I always confuse myself with the release notes
22:53:12 ildikov mriedem: I'm cleaning up the patch to move Nova to Cinder v3, the base 3.0
22:53:37 ildikov mriedem: and was wondering whether it's 'other' or 'upgrade' category?
22:54:22 mriedem ildikov: depends on the change
22:54:29 ildikov mriedem: and how much we want to go into if anyone wants v2 as they might have a that old Cinder but they love it they can modify the 'catalog_info' in the config?
22:54:31 mriedem supporting cinder v3 would probably be a feature
22:54:42 mriedem are you also changing the default?
22:55:17 mriedem changing the default on a config option means a reno in the upgrade section
22:55:29 ildikov mriedem: if changing the default equals to set the catalog_info to v3, then I'm changing the default
22:55:36 mriedem yeah
22:55:40 mriedem so upgrade section
22:56:08 ildikov mriedem: as we agreed to change the default in case I need to do more than that please point me to that too :)
22:57:08 ildikov mriedem: cool, I will add an upgrade section then, just wanted to be sure
22:57:12 ildikov mriedem: tnx!
22:57:24 mriedem yw
23:09:49 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
23:09:50 openstackgerrit Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163
23:09:50 openstackgerrit Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162
23:09:51 openstackgerrit Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891
23:09:51 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023
23:09:52 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
23:09:52 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
23:09:53 openstackgerrit Dan Smith proposed openstack/nova master: Teach os-aggregates about cells https://review.openstack.org/442200
23:14:54 tonygunk Wondering if someone can point me in the right direction in error I'm getting with Ocata and Xen Hypervisor
23:15:07 tonygunk http://paste.openstack.org/raw/601670/
23:15:58 tonygunk Getting the following: TypeError: Argument must be bytes or unicode, got 'NoneType'
23:17:12 tonygunk All other hypervisors are running KVM and no issues of course - just trying Xen on one node
23:22:49 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: DELETE all inventories for a resource provider https://review.openstack.org/415885
23:23:39 mriedem tonygunk: libvirt + xen or xenapi?
23:23:46 mriedem because this looks like it's hitting libvirt code
23:23:59 tonygunk libvirt + xen
23:24:06 mriedem anthonyper: ^
23:24:54 mriedem https://github.com/openstack/nova/blob/15.0.0/nova/virt/libvirt/config.py#L1665
23:28:16 mriedem tonygunk: gotta be something wrong down this path https://github.com/openstack/nova/blob/15.0.0/nova/virt/libvirt/driver.py#L4415
23:29:07 mriedem https://github.com/openstack/nova/blob/15.0.0/nova/virt/libvirt/driver.py#L4435
23:29:22 mriedem https://github.com/openstack/nova/blob/15.0.0/nova/virt/libvirt/driver.py#L4489
23:29:25 mriedem log_path would be None there
23:29:30 mriedem for xen
23:30:21 mriedem tonygunk: do you have these minimum versions for libvirt/qemu? https://github.com/openstack/nova/blob/15.0.0/nova/virt/libvirt/driver.py#L275
23:32:01 mriedem looks like the libvirt+xen CI running against nova is testing against an older libvirt
23:32:03 mriedem 1.3.1
23:32:08 mriedem so that CI wouldn't have caught this
23:33:02 mriedem but yeah that's the bug
23:33:43 mriedem tonygunk: looks like you could set [serial_console]/enabled=True in nova.conf to workaround this for now
23:37:59 tonygunk mriedem: I just tried the workaround and it works
23:38:40 tonygunk mriedem: I sincerely appreciate you looking at this. My python fu is not equivalent
23:39:10 mriedem sure, yw
23:39:14 openstack Launchpad bug 1670522 in OpenStack Compute (nova) "TypeError booting instance with libvirt+xen in _create_pty_device with libvirt>=1.3.3" [High,Triaged]
23:39:14 mriedem also https://bugs.launchpad.net/nova/+bug/1670522
23:39:21 mriedem anthonyper: ^
23:40:11 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Use Cinder API v3 as default https://review.openstack.org/420201

Earlier   Later