Re: [openstack-dev] [Neutron] ImportError: cannot import name access
Ran in this same situation a week or two ago. I updated to the latest code from the icehouse-eol branch and then pinned the client libraries to an earlier release level. After that, tox ran fine. The version levels that I pinned are: python-neutronclient==2.3.4 python-keystoneclient==0.9.0 python-novaclient==2.17.0 Other versions would probably have also worked, but those versions matched what we were already using for icehouse. John On 09/22/2015 01:53 PM, Wojciech Dec wrote: > Hi Folks, > > I'm trying to run using tox some unit tests on the latest Neutron > stable/icehouse, and things pretty much grind to a halt with a series > of errors arounf "cannot import name access: > > File > "/Users/wdec/Downloads/openstack/neutron/.tox/py27/lib/python2.7/site-packages/keystoneclient/__init__.py", > line 27, in > from keystoneclient import access > ImportError: cannot import name access > > Any suggestions on a possible fix? > > Thanks, > Wojciech. > > > __ > 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 -- John Kasperski __ 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
Re: [openstack-dev] [neutron] dns-nameservers order not honored
Hi Paul, There is an old bug on this issue: https://bugs.launchpad.net/neutron/+bug/1218629 If I remember correctly, the root of the problem was the database definition for the DNS values. On 06/23/2015 01:48 PM, Paul Ward wrote: > I haven't dug into the code yet, but from testing via CLI and REST > API, it appears neutron does not honor the order in which users > specify their dns-nameservers. For example, no matter what order I > specify 10.0.0.1 and 10.0.0.2 for dns-nameservers, they are always > ordered with the numerically lowest IP first when doing a subnet-show > (ie, 10.0.0.1 will be first, even if I specified 10.0.0.2 first). As > stated above, CLI and REST API behave the same. > > I believe this is a problem because these are passed to activation on > a deployed VM in the order neutron lists them in the subnet. A user > may have a reason they want the numerically higher DNS IP listed > first, say if they are trying to load balance their DNS servers. By > always ordering them numerically, we give them no way to do this. > > So my question is... is this by design or an oversight? If it's an > oversight, I'll dig into the code and propose a patch. > > > __ > > 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 > -- John Kasperski __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management
rent specs process as I'm sure people have > heard me complain about this in > #openstack-neutron plenty of times before. Instead, I'd like > to suggest a system that would perhaps > get us to implement specs that are currently not being > proposed, and give an additional form of > input that would make sure that the development community is > spending it's time in the right places. > > While 'super users' have been given more exposure, and > operators summits give operators > an additional tool to provide feedback, from a developer's > point of view, the input is > non-empiric and scattered. I also have a hunch that operators > still feel their voice is not being heard. > > I propose an upvote/downvote system (Think Reddit), where > everyone (Operators especially) would upload > paragraph long explanations of what they think is missing in > Neutron. The proposals have to be actionable > (So 'Neutron sucks', while of great humorous value, isn't > something I can do anything about), > and I suspect the downvote system will help self-regulate that > anyway. The proposals are not specs, but are > like product RFEs, so for example there would not be a > 'testing' section, as these proposals will not > replace the specs process anyway but augment it as an > additional form of input. Proposals can range > from new features (Role based access control for Neutron > resources, dynamic routing, > Neutron availability zones, QoS, ...) to quality of life > improvements (Missing logs, too many > DEBUG level logs, poor trouble shooting areas with an > explanation of what could be improved, ...) > to long standing bugs, Nova network parity issues, and > whatever else may be irking the operators community. > The proposals would have to be moderated (Closing duplicates, > low quality submissions and implemented proposals > for example) and if that is a concern then I volunteer to do so. > > This system will also give drivers a 'way out': The last cycle > we spent time refactoring this and that, > and developers love doing that so it's easy to get behind. I > think that as in the next cycles we move back to features, > friction will rise and the process will reveal its flaws. > > Something to consider: Maybe the top proposal takes a day to > implement. Maybe some low priority bug is actually > the second highest proposal. Maybe all of the currently marked > 'critical' bugs don't even appear on the list. > Maybe we aren't spending our time where we should be. > > And now a word from our legal team: In order for this to be > viable, the system would have to be a > *non binding*, *additional* form of input. The top proposal > *could* be declined for the same reasons > that specs are currently being declined. It would not replace > any of our current systems or processes. > > > Assaf Muller, Cloud Networking Engineer > Red Hat > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > <mailto:openstack-operat...@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > -- > Kevin Benton > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __ > 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 -- John Kasperski __ 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
Re: [openstack-dev] [Neutron][Nova][DHCP] Use case of enable_dhcp option when creating a network
When enable_dhcp is False, Config drive or metadata service can be used to assign static IP addresses to the deployed VM if the image has cloud_init or something equivalent. On 12/17/2014 2:15 AM, Padmanabhan Krishnan wrote: Hello, I have a question regarding the enable_dhcp option when creating a network. When a VM is attached to a network where enable_dhcp is False, I understand that the DHCP namespace is not created for the network and the VM does not get any IP address after it boots up and sends a DHCP Discover. But, I also see that the Neutron port is filled with the fixed IP value from the network pool even though there's no DHCP associated with the subnet. So, for such VM's, does one need to statically configure the IP address with whatever Neutron has allocated from the pool? What exactly is the use case of the above? I do understand that for providing public network access to VM's, an external network is generally created with enable-dhcp option set to False. Is it only for this purpose? I was thinking of a case of external/provider DHCP servers from where VM's can get their IP addresses and when one does not want to use L3 agent/DVR. In such cases, one may want to disable DHCP when creating networks. Isn't this a use-case? Appreciate any response or corrections with my above understanding. Thanks, Paddu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- John Kasperski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
