Integration is the issue. It only works with osapi/xen at this point which isn't even the default hypervisor setting in the packaging. A large number of people involved in Nova haven't even looked at it. The changes to make it support the ec2_api properly will need to be done in two separate projects and require that the projects move forward in lock-step for versioning. The blueprints and design decisions are essentially being managed separately. I believe that most of this could have been avoided if we kept glance in nova initially and moved it out if necessary at a later date.
Vish On Jan 28, 2011, at 9:45 AM, Jay Pipes wrote: > On Fri, Jan 28, 2011 at 11:37 AM, Vishvananda Ishaya > <[email protected]> wrote: >> I agree. I think splitting glance into a separate project has actually >> slowed it down. > > Massively disagree here. The only slowdown integrating Glance/Nova > was around packaging issues, and those have now been resolved. What > other slowdowns are you referring to? Glance is going at light-speed > compared to other projects IMHO. > > Glance blueprints and milestones are all online and mailing list > discussion has already occurred on many of them. If there are further > integration issues between Nova and Glance, please do file bugs and > blueprints for them and we'll get to them quickly. I can't fix stuff > I don't know about. > > -jay > >> 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 <[email protected]> wrote: >>> >>> On 01/28/2011 08:55 AM, Jay Pipes wrote: >>>> On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark <[email protected]> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
