If any Neutron service is disabled, running the corresponding neutron CLI returns 404

And what do you expect with the service disabled?.. I believe it's correct behaviour.

As the behavior of neutron-server, it is the expected behavior.
As client side, it is one option to hide or disable sub-commands if corresponding services (i.e., extensions at now).
We need to query extension list to do this.
If we want to hide such sub-commands in the help message, we need to refactor the code structure. I explored a way in the past but IIRC it is not a small refactoring.

I would like to know what you expect too.

The long term solution I believe will be to move the VPNaaS commands out of the client tree and add them to the neutron-vpnaas repo as client extensions. That way they will only be available when the service is installed.

@Akihiro Motoki :
Currently an exception in thrown out directly from python-neutronclient's shell.py to the STDOUT which causes this message to display on screen.
My proposal is ( keeping @Henry Gessau 's proposal in mind) to modify the exception statement so that till the time a long term solution is not released, the client wont get a 404 Not Found error.
Note: I found this to be true with FWaaS as well.So this is not limited to VPNaaS but in fact all the extensions.

My concern is a 404 error seems a bit odd, a bit incomplete in demonstration to the user.
If I am a user/tester, I would not like to see "404 Not Found" on the screen ( :) ), thats why I logged the bug.

OK, so the bug is to provide nice message on 404 from the server; or alternatively, not show the commands that are not available from the server (but that may be problematic since users may want to see all of them in --help message for reference, no matter whether they have actual environment set).

@Ihar Hrachyshka:
I think user should be displayed all the CLI commands, because it would tell him there is some service which he is not using, but can be enabled by setting up some attributes etc.
Besides, modifying help file based on the enabled services is more complicated, as stated by you above.
So from my perspective, fixing the message would be a better option.

Dear @Ihar Hrachyshka, @Henry Gessau, @Akihiro Motoki:
The scope of this bug just got a bit bigger.
This problem is coming in several CLIs.Following CLIs are affected : ( Note I have enabled only fwaas for now)
--
address-scope-list
--
cisco-credential-list
--
cisco-network-profile-list
--
cisco-policy-profile-list
--
gateway-device-list
--
ipsec-site-connection-list
--
lbaas-healthmonitor-list
--
lbaas-listener-list
--
lbaas-loadbalancer-list
--
lbaas-pool-list
--
meter-label-list
--
meter-label-rule-list
--
net-gateway-list
--
nuage-netpartition-list
--
qos-available-rule-types
--
qos-policy-list
--
queue-list
--
vpn-ikepolicy-list
--
vpn-ipsecpolicy-list
--
vpn-service-list
--
Whenever a proper information is not being returned, ¨404 Not found ¨ is displayed.
Error message can be improved as ¨No information found.Please verify if the settings are correct.¨

Fix proposed to branch: master
Review: https://review.openstack.org/225062

Similar bug:
https://bugs.launchpad.net/python-neutronclient/+bug/1440285

404 error can be returned in usual cases.
From the discussion in the above proposed review, it is suggested to check the extension list to know which features are available.

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/225062
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Change abandoned by Doug Wiegley (<email address hidden>) on branch: master
Review: https://review.openstack.org/225062
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

It's always been like this, it's confusing, but it's an explicit design decision to obfuscate the server internals.

@Armando,@Doug:
A bug which handles similar work is mentioned below:
 https://bugs.launchpad.net/python-neutronclient/+bug/1094713

It would be ideal if it is known which extension is currently active , and accordingly provide the Help/Error message.
As per my understanding , the following two issues can be combined together to create a single solution.
Would like to know your view related to the same

neutronclient development is frozen in favor of OSC.

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/225062