On 08/04/15 22:07, Michael Still wrote:
priorities and specs
===============
I think the current spec process is starting to work well for us, and
that priorities was a success. We should continue with specs, but with
an attempt to analyse why so many approved specs don’t land [...]
nova-net
=======
OMG, this is still a thing. We need to actually work out what we’re
doing here, and then do it. [...]
conclusion
========
I make no claim that my list is exhaustive. What else do you think we
should be tackling in Liberty?
Something kind of related to two of the strands above, from the point of
view of someone who had an approved networking-related Nova spec that
failed to land for Kilo...
Basically, should Nova try harder to get out of the networking business?
Currently the situation is that OpenStack networking experimentation
is mostly in Neutron (as I assume it should be) but also often requires
changes to the VIF type code in Nova. Should we try to close off that
situation, I would guess through some structural solution that puts all
the required code changes firmly into Neutron's domain?
I don't want to prejudge what the solution might be. My point here is
to suggest discussing and deciding whether this could be a worthwhile
priority. If it sounds of interest, I could add something to the
etherpad for Nova design session ideas.
(I appreciate that the nova-net question is way bigger and more
practically important overall than my specific point about the VIF type
code. However it is possible that the VIF type code contributes to a
continuing lack of clarity about where networking function lies in
OpenStack.)
Regards,
Neil
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
