- openstack-discuss - lists.openstack.org

Router not allowing traffic in reverse
by John Carew 01 Mar '19

01 Mar '19

I have setup OpenStack with OVS. I have a single Hyper-V server running the controller and three CentOS instances(10.0.0.x) on a private subnet. I created a router in OpenStack with SNAT disabled, as I only want it to route traffic between the private subnet(10.0.0.x) and the external subnet(172.16.1.x)/internet. All of the instances can ping each other along with the external network(172.16.1.x). From the external network, I can ping the interface of the ovs router on the external network. I can not though ping inside the private network. A trace route stops at the IP of the OVS router. With wireshark, I do not see anything coming from the external pc’s IP. If I trace route it, I see packets making all the way to the OVS router and then stop. Since I can ping one way, and not the other; I believe there is something in the router/OVS that is stopping the packets to route into the private subnet. What do I need to look at? (I have disabled all firewalls on all OSes involved.) Here is a sudo design of the setup. Does respond to ping VM OVS Router priv int OVS Router ext int External PC 10.0.0.14 -> 10.0.0.1 -> 172.16.1.1 -> 172.16.1.10 Does not respond to ping External PC OVS Router ext int OVS Router priv int VM 172.16.1.10 -> 172.16.1.1 -> 10.0.0.1 -> 10.0.0.14

1 0

devstack doc for using the nova fake virt driver
by Matt Riedemann 28 Feb '19

28 Feb '19

I realize some people might not be aware of this capability in devstack so I wrote a docs patch [1] after someone was asking about it in the nova channel, hopefully it's useful to others. [1] https://review.openstack.org/#/c/640205/ -- Thanks, Matt

1 0

NDSU Capstone Introduction!
by Urbano Moreno, Eduardo 28 Feb '19

28 Feb '19

Hello OpenStack community, I just wanted to go ahead and introduce myself, as I am a part of the NDSU Capstone group! My name is Eduardo Urbano and I am a Jr/Senior at NDSU. I am currently majoring in Computer Science, with no minor although that could change towards graduation. I am currently an intern at an electrical supply company here in Fargo, North Dakota known as Border States. I am an information security intern and I am enjoying it so far. I have learned many interesting security things and have also became a little paranoid of how easily someone can get hacked haha. Anyways, I am so excited to be on board and be working with OpenStack for this semester. So far I have learned many new things and I can't wait to continue on learning. Thank you! -Eduardo

6 6

[neutron] Issue in neutron-tempest-iptables_hybrid gate job
by Slawomir Kaplonski 28 Feb '19

28 Feb '19

Hi Neutrinos, Just FYI, we have bug in os-vif [1] which cause failures of (at least) neutron-tempest-iptables_hybrid. So if Zuul is failing on Your patch because of this job, please don’t recheck it until patch [2] will be merged and new os-vif will be released. [1] https://bugs.launchpad.net/os-vif/+bug/1817919 [2] https://review.openstack.org/#/c/639702/ — Slawek Kaplonski Senior software engineer Red Hat

3 4

[ops] [nova] Wrong reported memory hypervisor usage
by Massimo Sgaravatto 28 Feb '19

28 Feb '19

In the dashboard of my OpenStack Ocata cloud I see that the reported memory usage is wrong for the hypervisors. As far as I understand that information should correspond to the "used_now" field of the "nova host-describe" command. And indeed considering an hypervisor: # nova host-describe cld-blu-01.cloud.pd.infn.it +-----------------------------+----------------------------------+-----+-----------+---------+ | HOST | PROJECT | cpu | memory_mb | disk_gb | +-----------------------------+----------------------------------+-----+-----------+---------+ | cld-blu-01.cloud.pd.infn.it | (total) | 8 | 32722 | 241 | | cld-blu-01.cloud.pd.infn.it | (used_now) | 19 | 16259 | 23 | | cld-blu-01.cloud.pd.infn.it | (used_max) | 19 | 38912 | 95 | | cld-blu-01.cloud.pd.infn.it | b08eede75d5e4be4b0fe21e68fa9c688 | 1 | 2048 | 20 | | cld-blu-01.cloud.pd.infn.it | 7890b3e262264529a19f9743cf2f14bc | 16 | 32768 | 50 | | cld-blu-01.cloud.pd.infn.it | 4d8187cffa6a4085ad4a357b8a5afc03 | 2 | 4096 | 25 | +-----------------------------+----------------------------------+-----+-----------+---------+ So for the memory it reports 16259 for used_now, while as far as far I understand it should be 38912 + the memory used by the hypervisor Am I missing something ? Thanks, Massimo

3 4

[release] Release countdown for week R-5, March 4-8
by Sean McGinnis 28 Feb '19

28 Feb '19

We are getting close to the end of the cycle. Please review some important deadlines and information as we approach feature freeze and the cycle ending activities. Development Focus ----------------- Teams should be focused on implementing planned work. Work should be wrapping up on client libraries to meet the client lib deadline Thursday, the 7th. This is also Feature Freeze, so please review anything to determine if should still be targeted for Stein or will need to be deferred to Train. General Information ------------------- The final client library release is on Thursday the 7th. Releases will only be allowed for critical fixes in libraries after this point as we stabilize requirements and give time for any unforeseen impacts from lib changes to trickle through. If release critical library or client library releases are needed for Stein past the freeze dates, you must request a Feature Freeze Exception (FFE) from the requirements team before we can do a new release to avoid having something released in Rocky that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] FFE requested for $PROJECT_LIB Include justification/reasoning for why a FFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. Including a link to the FFE in the release request is not required, but would be helpful in making sure we are clear to do a new release. When requesting these library releases, you should also include the stable branching request with the review (as an example, see the "branches" section here: http://git.openstack.org/cgit/openstack/releases/tree/deliverables/pike/os-…) Cycle-trailing projects are reminded that all reviews to the requirements project will have a procedural -2 unless it recieves a FFE until stable/stein is branched. This is a good point to start to think about communicating your project's updates for Stein. There are two venues for this that should be kept in mind: 1. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Stein changes can be added there to make sure the consumers of your release notes see them. 2. Through the releases repo, teams should be adding cycle-highlights to their deliverables. This is the direct input into marketing that helps shape what is communicated in press releases and other release activity at the end of the cycle. These are not per-deliverable, but rolled up per-team. So any significant work your team has done that would be good for marketing, please include these by the RC1 deadline. Upcoming Deadlines & Dates -------------------------- Stein-3 milestone: March 7 RC1 deadline: March 21 -- Sean McGinnis (smcginnis)

1 0

Re: [placement][tripleo][infra] zuul job dependencies for greater good?
by Bogdan Dobrelya 28 Feb '19

28 Feb '19

> On Mon, 2019-02-25 at 19:42 -0500, Clark Boylan wrote: >> On Mon, Feb 25, 2019, at 12:51 PM, Ben Nemec wrote: >> > > snip > >> That said, I wouldn't push too hard in either direction until someone >> crunched the numbers and figured out how much time it would have saved >> to not run long tests on patch sets with failing unit tests. I feel like >> it's probably possible to figure that out, and if so then we should do >> it before making any big decisions on this. > > For numbers the elastic-recheck tool [0] gives us fairly accurate tracking of which issues in the system cause tests to fail. You can use this as a starting point to potentially figure out how expensive indentation errors caught by the pep8 jobs ends up being or how often unittests fail. You probably need to tweak the queries there to get that specific though. > > Periodically I also dump node resource utilization by project, repo, and job [1]. I haven't automated this because Tobiash has written a much better thing that has Zuul inject this into graphite and we should be able to set up a grafana dashboard for that in the future instead. > > These numbers won't tell a whole story, but should paint a fairly accurate high level picture of the types of things we should look at to be more node efficient and "time in gate" efficient. Looking at these two really quickly myself it seems that job timeouts are a big cost (anyone looking into why our jobs timeout?). > > [0] http://status.openstack.org/elastic-recheck/index.html > [1] http://paste.openstack.org/show/746083/ > > Hope this helps, > Clark Here is some numbers [0] extracted via elastic-recheck console queries. It shows 6% of wasted failures because of tox issues in general, and 3% for tripleo projects in particular. My final take is, given some middle-ground solution, like I illustrated earlier this sub-thread, it might be worth it, and the effort for boosting up the total throughput of openstack CI system by a 6% is not so bad idea. [0] http://paste.openstack.org/show/746503/ -- Best regards, Bogdan Dobrelya, Irc #bogdando

3 5

[nova] stein-rc-potential tag and etherpad
by Matt Riedemann 28 Feb '19

28 Feb '19

There is one week to feature freeze and a lot going on, so I created an etherpad to help track things that we don't want to forget about before RC1 on March 21: https://etherpad.openstack.org/p/nova-stein-rc-potential I also created the official "stein-rc-potential" tag for nova in launchpad so you can tag bugs with it if you think they are install/upgrade/major regressions that need to be sorted out prior to releasing Stein. -- Thanks, Matt

1 0

[all] [forum] Forum Submissions are open!
by Jimmy McArthur 28 Feb '19

28 Feb '19

Hi Everyone - A quick reminder that we are accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Denver [2]. Please submit your ideas through the Summit CFP tool [3] through March 8th. Don't forget to put your brainstorming etherpad up on the Denver Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/denver-2019/ [3] https://www.openstack.org/summit/denver-2019/call-for-presentations [4] https://wiki.openstack.org/wiki/Forum/Denver2019 ___________________________________________

8 16

[dev][oslo] oslo.cache and dogpile 0.7.0+ cache errors
by Herve Beraud 28 Feb '19

28 Feb '19

Hi, Just a heads up that the latest version of dogpile (0.7.0 onwards) have become incompatible with oslo.cache. This is causing a few issues for jobs. It's a little complex due to functional code and many decorated functions. The error you will see is: *oslo_cache.**tests.test_**cache.CacheRegi**onTest.**test_function_* *key_generator_* *with_kwargs -------**-------**-------**-------**-------**-------**-------* *-------**-------**-------**-------**------* *Captured traceback: ~~~~~~~~~~~~~~~~~~~ b'Traceback (most recent call last):' b' File "/tmp/oslo.**cache/oslo_**cache/tests/**test_cache.**py", line 324, in test_function_**key_generator_* *with_kwargs' b' value=self.**test_value)* *' b' File "/tmp/oslo.**cache/.**tox/py37/**lib/python3.**7/site-* *packages/**testtools/**testcase.* *py", line 485, in assertRaises' b' self.assertThat* *(our_callable, matcher)' b' File "/tmp/oslo.**cache/.**tox/py37/* *lib/python3.**7/site-**packages/**testtools/**testcase.* *py", line 498, in assertThat' b' raise mismatch_error' b'testtools* *.matchers.**_impl.MismatchE**rror: <function CacheRegionTest* *._get_cacheable**_function.**<locals>**.cacheable_**function at 0x7fec3f795400> returned <oslo_cache.**tests.test_**cache.TestProxy**Value object at 0x7fec3f792550>'* The problem appear since we uncap dogpile.cache on oslo.cache: https://github.com/openstack/oslo.cache/commit/62b53099861134859482656dc92d… The following unit test fail since we uncap dogpile => https://github.com/openstack/oslo.cache/blob/master/oslo_cache/tests/test_c… The problem was introduced by: https://gerrit.sqlalchemy.org/#/c/sqlalchemy/dogpile.cache/+/996/ Your main issue on oslo.cache side is that keyword arguments are tranformed in positionnal arguments when we use dogpile.cache.region.cache_on_arguments. I've try to revert the changes introduced by the previous dogpile.cache change and everything works fine on the oslo.cache side when changes was reverted (reverted to revision https://github.com/sqlalchemy/dogpile.cache/blob/2762ada1f5e43075494d91c512… ). The expected behavior is that dogpile.cache.util.function_key_generator raise a ValueError if **kwargs founds, but our kwargs is empty and our `value=self.test_value was` is recognized as a positionnal argument. Our unit test looking for an assertRaise(ValueError) on cachable decorated function when we pass kwargs but it doesn't happen due to empty kwargs. For these reasons we guess that is an dogpile.cache issue and not an oslo.cache issue due to the changes introduced by `decorator` module. The following are related: - https://github.com/openstack/oslo.cache/blob/master/oslo_cache/tests/test_c… : unit test where the problem occure - https://review.openstack.org/#/c/638788/ : possible fix but we don't think that is the right way - https://review.openstack.org/#/c/638732/ : possible remove of the unit test who fail The issue is being tracked in: https://bugs.launchpad.net/oslo.cache/+bug/1817032 If some dogpile expert can take a look and send feedback on this thread you are welcome. Thanks, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 6