I agree. I think splitting glance into a separate project has actually slowed it down. We should keep network service in trunk for the moment.
Also, there were a couple of networking blueprints that were combined at the last design summit into one presentation. The presentation was given by one racker and one person from nicira, and also included a group from japan. I thought the plan was to implement this with openvswitch. Is this the same team/project? Or did that effort die? Vish On Jan 28, 2011, at 7:40 AM, Andy Smith wrote: > I'd second a bit of what Jay says and toss in that I don't think the code is > ready to be splitting services off: > > - There have already been significant problems dealing with glance, the nasa > people and the rackspace people have effectively completely different code > paths (nasa: ec2, objectstore, libvirt; rackspace: rackspace, glance, xenapi) > and that needs to be aligned a bit more before we can create more separations > if we want everybody to be working towards the same goals. > - Try as we might there is still not a real consensus on high level coding > style, for example the Xen-related code is radically different in shape and > style from the libvirt code as is the rackspace api from the ec2 api, and > having projects split off only worsens the problem as individual developers > have fewer eyes on them. > > My goal and as far as I can tell most of my team's goals are to rectify a lot > of that situation over the course of the next release by: > > - setting up and working through the rackspace side of the code paths (as > mentioned above) enough that we can start generalizing its utility for the > entire project > - actual deprecation of the majority of objectstore > - more thorough code reviews to ensure that code is meeting the overall style > of the project, and probably a document describing the code review process > > After Cactus if the idea makes sense to split off then it can be pursued > then, but at the moment it is much too early to consider it. > > On Fri, Jan 28, 2011 at 7:06 AM, Rick Clark <r...@openstack.org> wrote: > On 01/28/2011 08:55 AM, Jay Pipes wrote: > > On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark <r...@openstack.org> wrote: > > I recognise the desire to do this for Cactus, but I feel that pulling > > out the network controller (and/or volume controller) into their own > > separate OpenStack subprojects is not a good idea for Cactus. Looking > > at the (dozens of) blueprints slated for Cactus, doing this kind of > > major rework will mean that most (if not all) of those blueprints will > > have to be delayed while this pulling out of code occurs. This will > > definitely jeopardise the Cactus release. > > > > My vote is to delay this at a minimum to the Diablo release. > > > > And, for the record, I haven't seen any blueprints for the network as > > a service or volume as a service projects. Can someone point us to > > them? > > > > Thanks! > > jay > > Whew, Jay I thought you were advocating major changes in Cactus. That > would completely mess up my view of the world :) > > https://blueprints.launchpad.net/nova/+spec/bexar-network-service > https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model > https://blueprints.launchpad.net/nova/+spec/bexar-network-service > > > It was discussed at ODS, but I have not seen any code or momentum, to date. > > I think it is worth while to have an open discussion about what if any > of this can be safely done in Cactus. I like you, Jay, feel a bit > conservative. I think we lost focus of the reason we chose time based > releases. It is time to focus on nova being a solid trustworthy > platform. Features land when they are of sufficient quality, releases > contain only the features that passed muster. > > I will be sending an email about the focus and theme of Cactus in a > little while. > > Rick > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
