September 2019 - openstack-discuss

[tripleo] Deprecating paunch CLI?
by Emilien Macchi 15 Oct '19

15 Oct '19

With our long-term goal to simplify TripleO and focus on what people actually deploy and how they operate their clouds, it appears that the Paunch CLI hasn't been a critical piece in our project and I propose that we deprecate it; create an Ansible module to call Paunch as a library only. I've been playing with it a little today: https://review.opendev.org/#/c/682093/ https://review.opendev.org/#/c/682094/ Here is how you would call paunch: - name: Start containers for step {{ step }} paunch: config: "/var/lib/tripleo-config/hashed-container-startup-config-step_{{ step }}.json" config_id: "tripleo_step{{ step }}" action: apply container_cli: "{{ container_cli }}" managed_by: "tripleo-{{ tripleo_role_name }}" A few benefits: - Deployment tasks in THT would call the new module instead of a shell command - More Pythonic and clean for Ansible, to interact with the actual task during the run - Removing some code in Paunch, make it easier to maintain for us For now, the Ansible module only covers "paunch apply", we will probably cover "delete" and "cleanup" eventually. Please let me know if you have any questions or concerns, -- Emilien Macchi

9 18

[oslo] New courtesy ping list for Ussuri
by Ben Nemec 14 Oct '19

14 Oct '19

As we discussed at the beginning of the cycle, I'll be clearing the current ping list in the next few weeks. This is to prevent courtesy pinging people who are no longer active on the project. If you wish to continue receiving courtesy pings at the start of the Oslo meeting please add yourself to the new list on the agenda template [0]. Note that the new list is above the template, called "Courtesy ping list for Ussuri". If you add yourself again to the end of the existing list I'll assume you want to be left on though. :-) Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

Port creation times out for some VMs in large group
by Albert Braden 11 Oct '19

11 Oct '19

When I create 100 VMs in our prod cluster: openstack server create --flavor s1.tiny --network it-network --image cirros-0.4.0-x86_64 --min 100 --max 100 alberttest Most of them build successfully in about a minute. 5 or 10 will stay in BUILD status for 5 minutes and then fail with " BuildAbortException: Build of instance <UUID> aborted: Failed to allocate the network(s), not rescheduling." If I build smaller numbers, I see less failures, and no failures if I build one at a time. This does not happen in dev or QA; it appears that we are exhausting a resource in prod. I tried reducing various config values in dev but am not able to duplicate the issue. The neutron servers don't appear to be overloaded during the failure. What config variables should I be looking at? Here are the relevant log entries from the HV: 2019-09-26 10:10:43.001 57008 INFO os_vif [req-dea54d9a-3f3e-4d47-b901-a4f41b1947a8 d28c3871f61e4c8c8f8c7600417f7b14 e9621e3b105245ba8660f434ab21016c - default 4fb72165eee4468e8033cdc7d506ddf0] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:8b:45:07,bridge_name='brq49cbe55d-51',has_traffic_filtering=True,id=18f4e419-b19c-4b62-b6e4-152ec78e72bc,network=Network(49cbe55d-5188-4183-b5ad-e65f9b46f8f2),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap18f4e419-b1') 2019-09-26 10:15:44.029 57008 WARNING nova.virt.libvirt.driver [req-dea54d9a-3f3e-4d47-b901-a4f41b1947a8 d28c3871f61e4c8c8f8c7600417f7b14 e9621e3b105245ba8660f434ab21016c - default 4fb72165eee4468e8033cdc7d506ddf0] [instance: dc58f154-00f9-4c45-8986-94b10821cbc9] Timeout waiting for [('network-vif-plugged', u'18f4e419-b19c-4b62-b6e4-152ec78e72bc')] for instance with vm_state building and task_state spawning.: Timeout: 300 seconds More logs and data: http://paste.openstack.org/show/779524/

4 17

Release Cycle Observations
by Donny Davis 09 Oct '19

09 Oct '19

As many of you know I am fairly new to public participation in Openstack, but I am a long time lurker and operator. This is my first cycle and I wanted to capture an observation on the release cycle of Openstack. *this is only an observation for discussion* Over the last week or so I have watch people just about kill themselves to get features into Openstack for this release. Everyone in this community appears to be giving it their all. And way to go everyone for pushing so hard. Seriously! So this brings me to my observation. Can the release cycle be modified to ease this push at the end? I think what we all want is a smooth and steady stream of features and bug fixes, but a 6 month release cycle seems to do directly the opposite. Also if everyone has gate issues at the end of the cycle, is it the gate or the cycle? The gate seemed to work fine early on... Maybe if we went to a Major / Minor release sort of system we could remove some burden to *get that feature into X release* and we could steady out that flow of features / bug fixes. Maybe something like a 9 month major, one month minor release cycle. It would also probably help with micro api versioning. I am sure the more experienced developers here can highlight pros / cons, etc of all of the release types. Just a thought. Tell me yours. ~/DonnyD

10 19

[all][PTG] Strawman Schedule
by Kendall Nelson 09 Oct '19

09 Oct '19

Hello Everyone! In the attached picture or link [0] you will find the proposed schedule for the various tracks at the Shanghai PTG in November. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts especially when the event is three-ish days long and we have over 40 teams meeting. If there are critical conflicts we missed or other issues, please let us know, by October 6th at 7:00 UTC! -Kendall (diablo_rojo) [0] https://usercontent.irccloud-cdn.com/file/00mZ3Q3M/pvg_ptg_schedule.png

9 20

[dev][taskflow] Accepting any decision
by Jiří Rája 08 Oct '19

08 Oct '19

Hi, I wrote the code in the attachment and I would like to ask if it's possible to execute next task (step3) even if one decider returns True (link from step 1 to step 3) and one returns False (link from step 2 to step 3). If it is possible could someone alter the code? Or is there any other way to do it? And if the task wouldn't have to wait for all of the links, it would be great. Thank you! All the best, Rája

2 1

[oslo][nova] Revert of oslo.messaging JSON serialization change
by Ben Nemec 04 Oct '19

04 Oct '19

Hi, I've just proposed https://review.opendev.org/#/c/685724/ which reverts a change that recently went in to make the fake driver in oslo.messaging use jsonutils for message serialization instead of json.dumps. As explained in the commit message on the revert, this is problematic because the rabbit driver uses kombu's default serialization method, which is json.dumps. By changing the fake driver to use jsonutils we've made it more lenient than the most used real driver which opens us up to merging broken changes in consumers of oslo.messaging. We did have some discussion of whether we should try to override the kombu default and tell it to use jsonutils too, as a number of other drivers do. The concern with this was that the jsonutils handler for things like datetime objects is not tz-aware, which means if you send a datetime object over RPC and don't explicitly handle it you could lose important information. I'm open to being persuaded otherwise, but at the moment I'm leaning toward less magic happening at the RPC layer and requiring projects to explicitly handle types that aren't serializable by the standard library json module. If you have a different preference, please share it here. Thanks. -Ben

4 5

[nova][kolla] questions on cells
by Mark Goddard 03 Oct '19

03 Oct '19

Hi, I'm currently working (with dougsz) on adding support for nova cells v2 in Kolla Ansible. I have a few questions, and things that I'd like confirming. 1. Is there any benefit to not having a superconductor? Presumably it's a little more efficient in the single cell case? Also IIUC it only requires a single message queue so is a little simpler? 2. Do console proxies need to live in the cells? This is what devstack does in superconductor mode. I did some digging through nova code, and it looks that way. Testing with novncproxy agrees. This suggests we need to expose a unique proxy endpoint for each cell, and configure all computes to use the right one via e.g. novncproxy_base_url, correct? 3. Should I upgrade the superconductor or conductor service first? 4. Does the cell conductor need access to the API DB? 5. What DB configuration should be used in nova.conf when running online data migrations? I can see some migrations that seem to need the API DB, and others that need a cell DB. If I just give it the API DB, will it use the cell mappings to get to each cell DB, or do I need to run it once for each cell? 6. After an upgrade, when can we restart services to unpin the compute RPC version? Looking at the compute RPC API, it looks like the super conductor will remain pinned until all computes have been upgraded. For a cell conductor, it looks like I could restart it to unpin after upgrading all computes in that cell, correct? 7. Which services require policy.{yml,json}? I can see policy referenced in API, conductor and compute. I'm trying to design it such that it's possible to deploy a new cell in an existing environment, and upgrade one cell at a time. Getting the ordering right for this is fiddly, and I expect I'll be back to get some eyes on my plan. Cheers, Mark

6 16

[i18n] Request to be added as Vietnamese translation group coordinators
by Trinh Nguyen 03 Oct '19

03 Oct '19

Hi i18n team, Dai and I would like to volunteer as the coordinators of the Vietnamese translation group. If you find us qualified, please let us know. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

5 7

[all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org
by Alexandra Settle 03 Oct '19

03 Oct '19

Hi all, Quick recap: The documentation team is set to disband as an official project, and make the leap to becoming a SIG (Special Interest Group). This decision is not one we have made lightly, but with the changes of direction since Pike (project documentation belonging with the projects, etc) the need for a centralised documentation team as an official project is no longer integral to producing the software. The transition of the docs team to a SIG has already begun [1] and [2]. The openstackdocstheme, openstack-doc-tools, os-api-ref and whereto have been placed within the remit of the Oslo team and approved. The remaining individuals working on the docs team are sorting through what's left and where it is best placed. In [1], Doug has rightfully pointed out that whilst the documentation team as it stands today is no longer "integral", the docs.openstack.org web site is. An owner is required. The suggestion is for the Release Management team is the "least worst" (thanks, tonyb) place for the website manaagement to land. As Tony points out, this requires learning new tools and processes but the individuals working on the docs team currently have no intention to leave, and are around to help manage this from the SIG. Open to discussion and suggestions, but to summarise the proposal here: docs.openstack.org ownership is to transition to be the responsibility of the Release Management team officially provided there are no strong objections. Thanks, Alex IRC: asettle [1] https://review.opendev.org/#/c/657142/ [2] https://review.opendev.org/#/c/657141/

5 11