- openstack-discuss - lists.openstack.org

Instance Unable to connect to Data/Management Network
by Zufar Dhiyaulhaq 18 Dec '18

18 Dec '18

Hi, I have OpenStack cluster with this following network environment. Global Configuration : Data & Management Network : 10.60.60.0/24 External Network: 10.61.61.0/24 - All my endpoint is created in the Data & Management Network - Instance get floating IP from External Network IP Address Allocation : Controller: 10.60.60.10 | 10.61.61.10 Compute0: 10.60.60.20 | 10.61.61.20 Compute1: 10.60.60.30 | 10.61.61.30 Floating IP range : 10.61.61.100 - 10.61.61.200 My problem is the Instance cannot connect (ping, ssh, all connection) into the data/management network. I am running a magnum cluster but the instance needs to communicate with the endpoint. How to allow an Instance to connect to the data/management network? Best Regards, Zufar Dhiyaulhaq

2 1

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 18 Dec '18

18 Dec '18

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[cyborg] IRC meeting for Dec 18th
by Li Liu 17 Dec '18

17 Dec '18

The IRC meeting will be held tomorrow at 0300 UTC, which is 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) /11 am Beijing time (Wednesday) This week's agenda: 1. Try to merge https://review.openstack.org/#/c/615462/ 2. Review https://review.openstack.org/#/c/625630/ from CoCo 3. Review https://review.openstack.org/#/c/596691/ from Zhenghao 4. Track status updates. -- Thank you Regards Li

1 0

[all] Service-specific configuration options
by Stephen Finucane 17 Dec '18

17 Dec '18

I proposed a WIP change for oslo.config [1] last week that would allow us to specify what services (e.g. nova-compute, nova-scheduler, nova- api, etc.) an option applies to. This came about because of comments on another issue where we found no one could say with surety what services needed an option in their configuration option (which in turn brought up questions about why those services needed the option). It was suggested I bring the idea up on the mailing list before we proceeded any further with it so here I am. I'm interested in two things. Firstly, I'd like to know whether generation of per-service configuration files is actually something others find problematic? I'm imagining this is annoying for operators and those working on deployment tooling but I've never got any hard data to back up that assumption. Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing. Stephen [1] https://review.openstack.org/#/c/625011/ PS: I've tagged this [all] as enumerating the projects this actually affected left me with at least a dozen tags before I was even done. Sorry for any possible noise.

3 2

[tosca-parser] Failing to get functions from capabilities
by Michael Still 17 Dec '18

17 Dec '18

Hi, I'm trying to use tosca-parser to parse CSAR files. Its working quite well, until I hit a wall with capabilities today. Specifically I am testing with the single instance wordpress example CSAR, which uses a get_input for the num_cpus argument for host capabilities for the server. Based on how properties work, I would expect to get a function back for anything which requires referencing another value, but in the case of capabilities I either get the hardcoded value (strings, ints etc), or a None for values which would be functions if we were talking about prototypes. Here's a snippet of example code: #!/usr/bin/python import sys from jinja2 import Template import toscaparser.functions from toscaparser.tosca_template import ToscaTemplate tosca = ToscaTemplate(sys.argv[1]) for nodetemplate in tosca.nodetemplates: print print('Processing node template %s'% nodetemplate.name) capabilities = nodetemplate.get_capabilities_objects() for cap in capabilities: propobjs = cap.get_properties_objects() if not propobjs: continue for po in propobjs: print(' %s: %s' %(po.name, po.value)) Which returns this: $ python _capabilities.py csar_wordpress.zip No handlers could be found for logger "tosca.model" Processing node template wordpress network_name: PRIVATE initiator: source protocol: tcp secure: False Processing node template webserver network_name: PRIVATE initiator: source protocol: tcp secure: False secure: True Processing node template mysql_dbms Processing node template mysql_database Processing node template server secure: True min_instances: 1 max_instances: 1 mem_size: 4096 MB num_cpus: None disk_size: 10 GB distribution: Fedora version: 18.0 type: Linux architecture: x86_64 I would expect num_cpus for the "server" node_template to be a GetInput() function based on its definition in the CSAR, but instead I get None. Is there an example somewhere of how to correctly access functions for capabilities? Thanks, Michael

2 7

Gate fracas (status) update
by Matt Riedemann 17 Dec '18

17 Dec '18

I wanted to follow up from Clark's last gate status update [1]. Lots of work has been going on the last few weeks to try and get the gate under control since it's hard to merge code when you can't merge code. Most of my update is specific to nova, but some of it might be interesting to others as well for general QA/infra FYI. I'll group this into a few categories of issue. Optimize node usage / reduce blast radius ----------------------------------------- * The nova-cells-1 job has been moved to the experimental queue [2] so that we can still test that environment but do it on-demand. This helps us avoid latent cellsv1-specific race failures which might reset the gate. * I'm trying to drop the nova-multiattach job which is partially redundant with tempest-full except it only runs tempest.compute.api tests and it also runs slow tests [3]. What is blocking this is test_volume_swap_with_multiattach in the tempest-slow job intermittently failing during volume cleanup [4]. I have put a lot of debug details into that bug and have a debug logging patch up as well to see if I can recreate the failure and sort out what is going wrong. The main difference between this test in the tempest-slow job and the nova-multiattach job is simply that the tempest-slow job is multinode and nova-multiattach is single node, and the single node aspect might have been hiding some weird race bugs when it came to disconnecting the volume to cleanup if the servers are all on the same host. Help debugging that would be appreciated. Zuul queuing changes -------------------- An infra thread [5] prompted some discussion in IRC which led to changes in how tripleo changes will be queued by zuul [6][7]. The idea here is to isolate tripleo changes into their own queue so failures in tripleo changes don't disrupt (or starve) changes in openstack projects (in general) from getting queued up for test nodes. tl;dr: nova changes should enqueue more like they used to before [5]. Gate bugs --------- * http://status.openstack.org/elastic-recheck/#1807518 A fix for devstack was merged on both master and stable/rocky but we're still seeing this, so it probably needs more investigation. * http://status.openstack.org/elastic-recheck/#1783405 We need another deep dive on tempest tests which aren't marked as slow but which might be slow and contributing to overall job timeouts. * http://status.openstack.org/elastic-recheck/#1808171 This is relatively new. Debug notes are in the launchpad bug. In this test, a server is being created with 7 ports and times out waiting to get the network-vif-plugged event from neutron on the first port only, the other 6 events are received. Regarding the port that doesn't get the event, there are some weird messages in the neutron agent logs so there could be a race there but we likely need help from the neutron team to investigate. I'm not sure what might have prompted this, but maybe the recent change to use Ubuntu Bionic nodes and a new version of OVS is buggy? * http://status.openstack.org/elastic-recheck/#1800472 The fix for this [8] merged a couple of hours ago and we're seeing it drop off the e-r graph. * http://status.openstack.org/elastic-recheck/#1806912 There are a couple of separate nova bugs for this [9][10]. The fixes for both changes are approved and should reduce the amount of time it takes to start nova-api which will help avoid timeouts on slower test nodes. The fix for [10] also fixes a long-standing rolling upgrade issue so we'll be backporting that one. * http://status.openstack.org/elastic-recheck/#1798688 There is a nova fix up for this [11] and has a +2, it's very simple and just needs another nova core (efried would get it but he's out until January). * http://status.openstack.org/elastic-recheck/#1807520 This has been fixed on all grenade branches [12] and was very latent (goes back to pike) but only showed up on slower test nodes. * http://status.openstack.org/elastic-recheck/#1808010 This is a real snowball issue where the cirros filesystem fills up so config drive fails, falling back to use the metadata API to get networking information but the metadata API response is too slow and cloud-init times out. I've got a related fix [13] but we likely need someone to help profile where our other inefficiencies are in responding the metadata API requests. * http://status.openstack.org/elastic-recheck/#1808063 This one is also relatively new and I'm not sure what might be causing it. ---- There are other bugs in the e-r page but the hits are low enough, or they are latent enough, that I won't bother trying to detail them here. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread… [2] https://review.openstack.org/#/c/623538/ [3] https://review.openstack.org/#/q/topic:drop-multiattach-job [4] https://bugs.launchpad.net/tempest/+bug/1807723 [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread… [6] https://review.openstack.org/#/c/623595/ - this is the zuul feature [7] https://review.openstack.org/#/c/624246/ - the tripleo-ci change [8] https://review.openstack.org/#/c/615347/ [9] https://bugs.launchpad.net/nova/+bug/1807219 [10] https://bugs.launchpad.net/nova/+bug/1807044 [11] https://review.openstack.org/#/c/623596 [12] https://review.openstack.org/#/q/I833d79ecc97ddc844bf156ab64477c7c77424f20 [13] https://review.openstack.org/#/c/624778 -- Thanks, Matt

2 1

[sdk] Establishing SDK Validation Baseline
by Melvin Hillsman 17 Dec '18

17 Dec '18

Hi everyone, We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback. Currently the following SDKs are generally considered usable for their respective language; there are others of course: openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP) After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM. I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2] Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. 1. Does this make sense? 1. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? 1. Bi-weekly discussions a good cadence? 1. Who is interested in tackling this together? [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce [1] https://etherpad.openstack.org/p/BER-sdk-certification [2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3V… -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

6 15

[ptl] [user survey] Cinder Superuser Article Addressing User Survey Feedback
by Allison Price 17 Dec '18

17 Dec '18

Hi everyone, I wanted to share a really helpful article [1] that Jay Bryant wrote for Superuser after receiving the Cinder feedback from the 2018 OpenStack User Survey. This is really valuable content for the users that are expressing challenges and feedback in the survey. I would like to encourage any PTLs that have the bandwidth to directly address some of the feedback they received from the user survey to draft something similar. With the publication of this article, we will reach out to users who expressed that they are running Cinder to show how their feedback has had a direct impact on the development of OpenStack. If anyone is interested, please email me directly, and we can get the process started. We have also made the 2019 OpenStack User Survey [2] live. We will be reaching out to all PTLs in the next month to make updates to the project-specific questions. If you have any questions in the meantime, please let me know. Thanks! Allison [1] http://superuser.openstack.org/articles/how-your-feedback-sparked-whats-nex… [2] https://www.openstack.org/user-survey/survey-2019 Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[Oslo] End of year schedule and plans
by Ben Nemec 17 Dec '18

17 Dec '18

Hi Norwegians, As we discussed in the meeting today, there will be no Oslo meetings for the next two weeks due to the holidays. We'll resume Jan. 7. Releases will happen as normal this week, but after that I wouldn't expect any more until 2019. We generally try to avoid releasing when people aren't going to be around to deal with any fallout. Finally, I believe most of the Oslo cores will be unavailable after this week, so expect review activity to slow significantly until the new year too. I will be around for the rest of the week, so if you have any Oslo-related stuff that needs to happen in 2018 let me know. After that all bets are off for my availability. Thanks and Happy New Year in advance! -Ben

1 0

[dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used?
by Akihiro Motoki 17 Dec '18

17 Dec '18

Hi, # I am not sure [tc] and [release] tags are appropriate. Horizon team maintains xstatic-* repositories [1]. We have a question on the need for tox.ini. Can we drop tox.ini completely considering the situation below? These repositories do not depend on 'tox' on testing from their nature of re-packaging JS module in a python way. In addition, there is no document provided. The current PTI mentions only "tox -e docs". # Previously PTI required "venv" tox ini but it is no longer mentioned. [1] http://git.openstack.org/cgit/?q=xstatic- Best Regards, Akihiro Motoki (IRC: amotoki)

4 3