Open Stack

On 03/13/2015 08:04 AM, Tom Fifield wrote:
> Hi,
> 
> Just writing this up in case anyone else was confused by this comment.
> 
> On 13/03/15 08:19, Thomas Goirand wrote:
>> That is correct. And nova-network is deprecated upstream, and it's been
>> YEARS like this. How come the install-guide still talks about it? IMO
>> that's a problem that the doc team should work on, not me as a Debian
>> package maintainer. I don't plan *ever* to re-add nova-network which has
>> been said to be deprecated for like 2 years.
> 
> nova-network is not marked as deprecated, and is open for code merge.
> There were some improvements added in Juno. nova-network continues to
> have significant usage, and serves "simple" use cases particularly well.
> 
> Both the nova and neutron teams are currently trying to get to a state
> where it can be deprecated, but that is unlikely to occur until Liberty
> or later, with a potential removal in M-release or later.
> 
> Regards,
> 
> Tom

Tom,

You can discuss the color of the bike shed forever, however it doesn't
change the fact that our users should be learning Neutron, not
nova-network, and I'm sure you know it.

Now a bit of background: I removed nova-network, because the Debian FTP
masters were concerned that Nova was generating a way too many binary
packages, and they asked me to reduce that number. So I removed the
nova-api-* packages, and used only nova-api, with a Debconf screen to
select the activated APIs, I did the same for the nova-consoleproxy
package (there's now a single package in Debian for SPICE, NoVNC and the
Xen console), then removed the nova-objectstore and nova-network
packages which IMO were of very low use. To this date, nobody complained
about it, except here in the doc team, now, just because "Debian is
different".

Though it is right that we shouldn't talk about nova-network in the case
of Debian, so I've tried to commit a patch, which is now opened for review:

https://review.openstack.org/164242

This helps closing #1417212 I believe. But it's hard to close bugs,
because every bug Matt reported contains multiple issues.

Again, I'd be happy to do the work (I in fact already started some of
it), and do more documentation things. However, bug reports needs to be
filled properly. That is:
- 1 issue per bug
- 1 bug per issue
- constructive work
- actionable bugs

That's currently not at all the case if you browse the debian tagged
bugs here:
https://bugs.launchpad.net/openstack-manuals/+bugs?field.searchtext=installation+guide+debian&field.tag=install-guide+

so it is also hard for me to reply to the bug reports. Some of the
content of the bugs is correct, some is simply wrong, some can be
ignored (warnings, etc.). So it's also impossible to triage in the
current form.

Cheers,

Thomas Goirand (zigo)