openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

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
> <vishvananda@xxxxxxxxx> 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 <rick@xxxxxxxxxxxxx> wrote:
>>> 
>>> On 01/28/2011 08:55 AM, Jay Pipes wrote:
>>>> On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark <rick@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>>