← Back to team overview

openstack team mailing list archive

Re: Network Service for L2/L3 Network Infrastructure blueprint


On 01/28/2011 11: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.

For historical accuracy:

Glance is in great shape now, but did flounder for the first couple
months of the Austin release cycle.  The problem was that separating it
took the work off of the radar of most of the Nova devs.  That was
primarily a communication issue.  Once Jay became involved and fixed
that, things have progressed very well.

So regardless of if and when we decide to split out other functionality,
we need to ensure that there is enough communication back to the core
project's development team.

> 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
>>> ______

Attachment: signature.asc
Description: OpenPGP digital signature