On 04/18/2014 12:03 AM, Scott Devoid wrote: > So I have had a chance to look over the whole review history again. I > agree with Sean Dague and Dean Troyer's concerns that the current patch > affects code outside of lib/storage and extras.d. We should make the > Devstack extension system more flexible to allow for more extensions. > Although I am not sure if this responsibility falls completely in the > lap of those wishing to integrate Ceph.
Where should it fall? This has been pretty common with trying to bring in anything major, the general plumbing needs to come from that same effort. It's also a pretty sane litmus test on whether this is a drive by contribution that will get no support in the future (and thus just expect Dean and I to go fix things), or something which will have someone actively contributing to keep things working in the future. > What is more concerning though is the argument that /even when the Ceph > patch meets these standards/ /it will still have to be pulled in from > some external source. /Devstack is a central part of OpenStack's test > and development system. Core projects depend upon it to develop and test > drivers. As an operator, I use it to understand how changes might affect > my production system. Documentation. Bug Triage. Outreach. Each of these > tasks and efforts benefit from having a curated and maintained set > extras in the mainline codebase. Particularly extras that are already > represented by mainline drivers in other projects. My concern is that there is a lot of code in devstack. And every time I play with a different set of options we don't enable in the gate, things get brittle. For instance, Fedora support gets broken all the time, because it's not tested in the gate. Something as big as using ceph for storage back end across a range of services is big. And while there have been patches, I've yet to see anyone volunteer 3rd party testing here to help us keep it working. Or the long term commitment of being part of the devstack community reviewing patches and fixing other bugs, so there is some confidence that if people try to use this it works. Some of the late reverts in nova for icehouse hit this same kind of issue, where once certain rbd paths were lit in the code base within 24hrs we had user reports coming back of things exploding. That makes me feel like there are a lot of daemons lurking here, and if this is going to be a devstack mode, and that people are going to use a lot, then it needs to be something that's tested. If the user is pulling the devstack plugin from a 3rd party location, then it's clear where the support needs to come from. If it's coming from devstack, people are going to be private message pinging me on IRC when it doesn't work (which happens all the time). That being said, there are 2 devstack sessions available at design summit. So proposing something around addressing the ceph situation might be a good one. It's a big and interesting problem. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev