On Sep 5, 2014, at 4:12 AM, Sean Dague <s...@dague.net> wrote: > On 09/05/2014 06:40 AM, Nikola Đipanov wrote: >> >> >> Just some things to think about with regards to the whole idea, by no >> means exhaustive. > > So maybe the better question is: what are the top sources of technical > debt in Nova that we need to address? And if we did, everyone would be > more sane, and feel less burnt. > > Maybe the drivers are the worst debt, and jettisoning them makes them > someone else's problem, so that helps some. I'm not entirely convinced > right now. > > I think Cells represents a lot of debt right now. It doesn't fully work > with the rest of Nova, and produces a ton of extra code paths special > cased for the cells path. > > The Scheduler has a ton of debt as has been pointed out by the efforts > in and around Gannt. The focus has been on the split, but realistically > I'm with Jay is that we should focus on the debt, and exposing a REST > interface in Nova. > > What about the Nova objects transition? That continues to be slow > because it's basically Dan (with a few other helpers from time to time). > Would it be helpful if we did an all hands on deck transition of the > rest of Nova for K1 and just get it done? Would be nice to have the bulk > of Nova core working on one thing like this and actually be in shared > context with everyone else for a while.
In my mind, spliting helps with all of these things. A lot of the cleanup related work is completely delayed because the review queue starts to seem like an insurmountable hurdle. There are various cleanups needed in the drivers as well but they are not progressing due to the glacier pace we are moving right now. Some examples: Vmware spawn refactor, Hyper-v bug fixes, Libvirt resize/migrate (this is still using ssh to copy data!) People need smaller areas of work. And they need a sense of pride and ownership of the things that they work on. In my mind that is the best way to ensure success. Vish
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev