- openstack-discuss - lists.openstack.org

Re: Fwd: openstack queens magnum error
by Feilong Wang 13 Dec '18

13 Dec '18

Seems your master node can't talk to your keystone, can you confirm that? On 13/12/18 11:08 AM, Ignazio Cassano wrote: > Hello Feilong, this forwarding contains logs. > Thanks > > ---------- Forwarded message --------- > From: *Ignazio Cassano* <ignaziocassano(a)gmail.com > <mailto:ignaziocassano@gmail.com>> > Date: Mer 12 Dic 2018 10:06 > Subject: openstack queens magnum error > To: OpenStack Operators <openstack-operators(a)lists.openstack.org > <mailto:openstack-operators@lists.openstack.org>> > > > Hello Everyone, > > I installed queens on centos with magnum and I am trying to create a > swarm cluster with one muster and one node. The image I used is > fedora-atomic 27 update 04 > > The stack generated end with an error and magnum conductor reports: > ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key api_address > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_masters > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_nodes > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key discovery_url > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.317 17964 ERROR magnum.drivers.heat.driver > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, > stack status: CREATE_FAILED, stack_id: > 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: > WaitConditionFailure: > resources.swarm_nodes.resources[0].resources.node_wait_condition: > swarm-agent service failed to start. > > > > I connected to the master node for verifyng if swarm agent is running. > In the cloud init log I found: > requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries > exceeded with url: /v3//auth/tokens (Caused by > NewConnectionError('<urllib3.connection.HTTPConnection object at > 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 > 08:45:31 +0000. Up 55.54 seconds. > 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-005 [1] > /var/lib/cloud/instance/scripts/part-006: line 13: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 26: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 38: > /etc/etcd/etcd.conf: No such file or directory > 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-006 [1] > Configuring docker network ... > Configuring docker network service ... > Removed > /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. > New size given (1280 extents) not larger than existing size (4863 > extents) > ERROR: There is not enough free space in volume group atomicos to > create data volume of size MIN_DATA_SIZE=2G. > 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-010 [1] > + systemctl stop docker > + echo 'starting services' > starting services > + systemctl daemon-reload > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service etcd' > activating service etcd > + systemctl enable etcd > Failed to enable unit: Unit file etcd.service does not exist. > + systemctl --no-block start etcd > Failed to start etcd.service: Unit etcd.service not found. > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service docker.socket' > activating service docker.socket > + systemctl enable docker.socket > > > 1) Seems etcd service is not installed , > > 2) the instance required to contact controller on port 5000 (is it > correct ?) > > > Please help me. > > Regards > Ignazio > > -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

3 5

Queens magnum external network
by Ignazio Cassano 13 Dec '18

13 Dec '18

Hi All, I am testing magnum on Centos openstack queens. I saw magnum external network must speak with some controller services ....for example 5000 for keystone and 8004 for heat . Are there any other port to open for external network? Regards Ignazio

1 0

[cyborg][ResMgmt]Cyborg Ecosystem Building Planning For 2019
by Zhipeng Huang 13 Dec '18

13 Dec '18

Hi team, After the wrapping up of KubeCon this week, I have some initial thoughts on eco building for next year 1. Kubernetes We will be working on a proposal for heterogeneous resource support in k8s. This is not a new idea and we have been floating the idea around for almost a year, and based upon the discussion we had through the week, it seems a good time to do it now. Detailed proposal will come out early next year I hope for public review and discussion. To have k8s integration out is on the direction of having more form of compute with acceleration support. We will also kickstart the resource management sig activity which has been earlier this year (via email mostly) 2. RISC-V I would propose we start to talk and work with the FireSIM team to try out how could we better support RISC-V arch from a cloud perspective. 3. Edge I'm interested in have raspberry pi support with our driver gathering info from libgpio and other interfaces. It would be great to have ARM embedded devs to join the discussion :) Look forward to feedbacks.

1 0

NTP failed on deploy
by Lior Fellus 13 Dec '18

13 Dec '18

I'm doing a fresh deploy of OpenStack using Fuel, with 3 controllers and 4 compute nodes. Network verification passes without issues, but during the OpenStack installation phase on the new compute I am trying to add I get this message: *Failed to deploy node '...': Task sync_time failed on node * I can ping the NTP servers (fuel server) from the node so connectivity shouldn't be an issue. we are using Mirantis Mitaka. Thanks,

1 0

Neutron performance Ocata
by Matteo Dacrema 13 Dec '18

13 Dec '18

Hi all, I’ve recently upgraded Openstack from Mitaka to Ocata and now I’m facing an increased latency in instance creation. Before the upgrade I was able to launch sequentially 400 VMs in 5 minutes and now I need at least 15 minutes. Attached the script I use to measure timings. Here you can find the comparison between Mitaka and Ocata. I also noticed that in Ocata DHCP agent is slower and sometimes when I launch more than 30 VMs sequentially some of them doesn’t took an address. Time of instance creation increase with the number of ports in the network. https://docs.google.com/spreadsheets/d/1eHjRxkw_5BmJ2p0rBJg9suGKmu_1YrSY05f… <https://docs.google.com/spreadsheets/d/1eHjRxkw_5BmJ2p0rBJg9suGKmu_1YrSY05f…> I’ve enabled the osprofiler inside nova and neutron api and attached you can see that the most of the time is spent on wsgi component of neutron. The time is spent on getting port list. I’ve also verified with cli listing only ports and I can confirm is a port list related issue. I’m trying to profile the neutron-server with cProfile but I’ve some problems with multi-threading tracing. Does anyone have faced this issue? Thank you! Regards Matteo -------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 1

[TripleO] - Blueprint - tripleo-routed-networks-templates
by Harald Jensås 13 Dec '18

13 Dec '18

Hello TripleO Team, I have been working on the tripleo-routed-networks-templates blueprint for some time. There is a number of patches in need of reviews. Link # https://review.openstack.org/#/q/topic:bp/tripleo-routed-networks-templates… ) Most of the patches are based on top of eachoter starting with: - https://review.openstack.org/582180 One of the hurdles with all this is having an environment with a network infrastructure to run tests, routers, dhcp-relay server etc. For some time I have been collaborating with Ben Nemec on routed- networks support in OVB. And it is working really well! \o/ If anyone wants to try this out, I have set up a github repository[1] with some scripts to set up the OVB environment in rdocloud. The ansible playbook in that repo will Deploy the undercloud (including all the THT patches), build images and import the baremetal nodes. Overcloud environment files, templates and a deploy script is there in the repo as well. For the overcloud there are two set's of templates and accompanying deploy command in the git repo. The deploy command and templates with suffix '_pre_update' will deploy 1 Controller and 1 Compute node without subnets, a single leaf. By deploying using these first, and then deploying the using the templates and deploy command without suffix we can verify that the existing non-*neutron routed networks* is migrated to *neutron routed networks* with multiple subnets with network segment association during stack update. The commands to run Tempest is also in the Readme. Today's `tempest run --smoke` results: ====== Totals ====== Ran: 99 tests in 486.0000 sec. - Passed: 90 - Skipped: 9 - Expected Fail: 0 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 1028.2578 sec. I hope that we can merge these changes soon, so that they are available in early for downstream QA. Thank you! -- Cheers, Harald [1] https://github.com/hjensas/ooo-bp-tripleo-routed-networks-templates-testing

1 0

[cinder] [tempest] Ideas for test cases
by Sofia Enriquez 13 Dec '18

13 Dec '18

Hello cinder guys, I'm working on increasing the coverage of Cinder Tempest [1]. Since I'm relatively new using cinder retype+migrate functionality, I'm looking for possible ideas of test cases. Thanks, Sofi [1]: https://review.openstack.org/#/c/614022/ -- Sofia Enriquez Associate Software Engineer <https://red.ht/sig>

2 2

[senlin] Senlin Monthly(ish) Newsletter Nov/Dec 2018
by Duc Truong 13 Dec '18

13 Dec '18

HTML: https://dkt26111.wordpress.com/2018/12/13/senlin-monthlyish-newsletter-nove… This is the November/December edition of the Senlin monthly(ish) newsletter. The goal of the newsletter is to highlight happenings in the Senlin project. If you have any feedback or questions regarding the contents, please feel free to reach out to me in the #senlin IRC channel. News ---- * The Senlin Project update video and slides from the Berlin summit have been posted: https://www.openstack.org/videos/summits/berlin-2018/senlin-project-update-1 * Autoscaling forum was held at the Berlin Summit. Notes have been captured here: https://etherpad.openstack.org/p/autoscaling-integration-and-feedback * A new autoscaling SIG has been proposed: http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284… * The weekly meeting was changed to have alternating times for even and odd weeks to allow for participation from developers in US / Europe: http://eavesdrop.openstack.org/#Senlin_Team_Meeting * This week is an even numbered week, so the meeting will be held on Friday at 530 UTC. Blueprint Status ---------------- * Fail fast locked resource - https://blueprints.launchpad.net/senlin/+spec/fail-fast-locked-resource - Working on documentation and release notes. * Multiple detection modes - https://blueprints.launchpad.net/senlin/+spec/multiple-detection-modes - Working on documentation and release notes. * Fail-fast on cooldown for scaling operations - https://blueprints.launchpad.net/senlin/+spec/scaling-action-acceptance - Completed * Action update - https://blueprints.launchpad.net/senlin/+spec/action-update - Basic functionality has been merged. - Currently working on force action update. Community Goal Status --------------------- * Python 3 - All patches by Python 3 goal champions for zuul migration, documentation and unit test changes have been merged. * Upgrade Checkers - The basic framework for the senlin-status upgrade check has been merged (thanks to rajathere and mriedem). It only has a placeholder check for now. If you like to help out with this task and implement the Senlin specific checks, please let me know. Reviews Needed -------------- * Health policy tempest tests: https://review.openstack.org/#/c/620716/ * Convert requests response from byte to string: https://review.openstack.org/#/c/624248/ * Fix senlin client to work with latest openstacksdk: https://review.openstack.org/#/c/624528/ * Force action update: https://review.openstack.org/#/c/624534/ * Fix senlin-dashboard bug when creating openstacksdk connection (Needs https://review.openstack.org/#/c/624528/ to merge first): https://review.openstack.org/#/c/620767/ * Update health manager to not spawn multiple tasks: https://review.openstack.org/#/c/621504/

1 0

[all]Forum summary: Expose SIGs and WGs
by Rico Lin 13 Dec '18

13 Dec '18

Dear all Here is the summary for forum `Expose SIGs and WGs` (etherpad [1] ). This concept still under development, so this is an open discussion and we need more feedbacks. Here are some general agreements on actions or ideas that we think it's worth to find the answer. *Set up guidelines for SIGs/WGs/Teams for interaction specific to this around tracking cross-project work* We tend to agree that we kind of lack for a guideline or a sample for SIGs/WGs, since all SIGs/WGs formed for different interest, we won't try to unify tools (unless that's what everyone agrees on) or rules for all groups. What we can do is to give more help to groups and provide a clear way for how they can set up cross-project works if they want to. Also, we can provide information on how to reach to users, ops, and developers and bridge them up. And we can even do a more general guideline or sample on how other SIGs/WGs are doing with their own workflow. Like self-healing SIG working on getting user story and feedback and use them to general better document/guideline for other users. Also, public cloud WG working on collect issues from public cloud providers and bring those issues to projects. Those IMO are great examples that we should put them down somewhere for cross SIGs/WGs consideration. As a further idea, we can even discuss if it's a common interest to have a SIG to help on SIGs. *A workflow for tracking:* This kind of follow above item. If we're going to set up a workflow, what we can add in to help people live an easier life? This is also an idea that no one in the room thinks it's a bad one, so it means in long term, it might worth our time to provide more clear information on what exactly workflow that we suggest everyone use. *Discuss SIG spec repo*: The discussion here is how can we monitoring SIGs/WGs health and track tasks. When talking about tasks we not just talking about bugs, but also features that's been considered as essential tasks for SIGs/WGs. We need a place to put them down in a trackable way (from a user story to a patch for implementation). *Ask foundation about have project update for SIGs/WGs*: One action we can start right now is to let SIGs/WGs present a project update (or even like a session but give each group 5 mins to present). This should help group getting more attention. And even capable to send out messages like what's the most important features or bug fixes they need from project teams, or what's the most important tasks that are under planning or working on. Fortunately, we got Melvin Hillsman (UC) volunteer on this task. We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help. The thing that we also wish to do is to clear the message here. We think most of the tools are already there, so we shouldn't need to ask project teams to do any huge change. But still, we found there are definitely some improvements that we can do to better bridge users, ops, and developers. You might find some information here didn't give you a clear answer. And that's because of we still under open discussion for this. And I assume we gonna keep finding actions from discussions that we can do right away. We will try to avoid that we have to do the exact same session with the same argument over and over again. So please give your feedback, any idea, or give us your help if you also care about this. [1] https://etherpad.openstack.org/p/expose-sigs-and-wgs -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

8 13

[glance]functional-py35 fails due to subunit.praser error
by Abhishek Kekane 13 Dec '18

13 Dec '18

[glance]functional-py35 fails due to subunit.praser error Hi All, >From 7th December 2018, all of sudden functional-py35 check job is failing on current master. Earlier this job was failing intermittently (2-3 times from 100). I have tried to dig into the issue and find out that it is failing obly for ubuntu and working fine with Fedora, centos etc. Below are some of the findings: 1. Even if I add failure tests [1] in black-list file every time other tests reported as failure. 2. When I compared failed tests results [1] with passed tests results [2] I have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in case of failure) 3. I have compared version of subunit, oslo.service, oslo.log, tox with failed [3] and passed [4] logs and they are same. 4. I came across a bug in cinder [5] which talks about excessive logs might cause this error and I have tried to ignore the deprecation warning in tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still shows DeprecationWarning in the logs. 5. I have tried executing tests by setting '--concurrency' to 1 but still the error persists. 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state and sometimes time-outs. I have no clues so far to tackle this issue, kindly provide your inputs for the same. [1] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4… [2] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/3… [3] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4… [4] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/3… [5] https://bugs.launchpad.net/cinder/+bug/1728640 Thanks & Best Regards, Abhishek Kekane

1 0

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

13 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

[manila] no meeting 13 December 2018
by Tom Barron 13 Dec '18

13 Dec '18

Since we have some cores at kubecon and will likely not have a quorum, I'm canceling this week's community manila meeting. Next meeting will be on 20 December at 1500 UTC. You can add agenda items here: https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit&se… As a reminder, milestone 2 for Stein is coming up the week of 7 January. Cores need to help with the access rule priority review [1] as this is work continued from Rocky and we need to move it along. See you on #openstack-manila on freenode in the mean time! -- Tom Barron irc: tbarron [1] https://review.openstack.org/#/c/572283

1 0

Magnum Fedora atomic 27
by Ignazio Cassano 13 Dec '18

13 Dec '18

Hello All, Deploying swarm cluster based on Fedora atomic cloud images, does not work fine in queens. On master node cloud init reports etcd package missing. Does anyone find this issue? Regards Ignazio

3 6

[neutron] gate issue
by Slawomir Kaplonski 13 Dec '18

13 Dec '18

Hi all, Recently we have issue with neutron-tempest-iptables_hybrid job which is failing 100% times. It is related to [1] and there is no need to recheck Your patches if CI failed on this job. To unblock our gate we proposed patch to make this job non-voting for some time [2]. When it will be merged, please rebase Your patches and it should be good then. [1] https://bugs.launchpad.net/os-vif/+bug/1807949 [2] https://review.openstack.org/#/c/624489/ — Slawek Kaplonski Senior software engineer Red Hat

1 1

[vitrage][monasca] Monasca datasource for Vitrage
by Ifat Afek 13 Dec '18

13 Dec '18

Hi, In case you missed it, we have a POC of a Monasca datasource for Vitrage [1] J Thanks Bartosz Zurkowski for the effort! There is one issue that we need to close though – how to connect the Monasca alarms to the resources in Vitrage. In order to connect an alarm to a resource, Vitrage should be able to identify that resource in its entity graph using the dimensions coming from Monasca. I understood that these dimensions are configurable and not pre-defined. Basically, there are two cases. 1. For OpenStack resources, all Vitrage needs to know is the UUID of the resource. I assume that there is always a dimension for that resource, right? Is the dimension always called the same? If not, how can Vitrage identify that this is the interesting dimension (if there are other dimensions for this alarm)? 2. For other resources it is more complicated, as they might not have a natural unique id. For example, a NIC id in Vitrage may be generated out of the host name + NIC name. Monasca alarm may have two separate dimensions for the host and nic. How can Vitrage understand that those two dimensions identify the resource? In other cases, Vitrage may need a resource_type dimension to uniquely identify the resource. Another question: I understood that Monasca can send alarms that originate from other monitors like Ceilometer, Prometheus etc. What are the dimensions in these cases? Monasca team, I’ll be happy to hear your opinion about these questions. If you can provide several different examples it will be very helpful. Thanks, Ifat [1] https://review.openstack.org/#/c/622899

2 2

[Neutron] [Upgrade] No meeting on Dec. 13th
by Lujin Luo 12 Dec '18

12 Dec '18

Hi everyone, Due to some personal reasons, I cannot hold the Neutron Upgrade subteam meeting on Dec. 13th. Let's skip it, and resume on Dec. 20th! Thank you for your understanding. Best regards, Lujin

1 0

[openstack-dev] [magnum] [Rocky] K8 deployment on fedora-atomic is failed
by Vikrant Aggarwal 12 Dec '18

12 Dec '18

Hello Team, Trying to deploy on K8 on fedora atomic. Here is the output of cluster template: ~~~ [root@packstack1 k8s_fedora_atomic_v1(keystone_admin)]# magnum cluster-template-show 16eb91f7-18fe-4ce3-98db-c732603f2e57 WARNING: The magnum client is deprecated and will be removed in a future release. Use the OpenStack client to avoid seeing this message. +-----------------------+--------------------------------------+ | Property | Value | +-----------------------+--------------------------------------+ | insecure_registry | - | | labels | {} | | updated_at | - | | floating_ip_enabled | True | | fixed_subnet | - | | master_flavor_id | - | | user_id | 203617849df9490084dde1897b28eb53 | | uuid | 16eb91f7-18fe-4ce3-98db-c732603f2e57 | | no_proxy | - | | https_proxy | - | | tls_disabled | False | | keypair_id | kubernetes | | project_id | 45a6706c831c42d5bf2da928573382b1 | | public | False | | http_proxy | - | | docker_volume_size | 10 | | server_type | vm | | external_network_id | external1 | | cluster_distro | fedora-atomic | | image_id | f5954340-f042-4de3-819e-a3b359591770 | | volume_driver | - | | registry_enabled | False | | docker_storage_driver | devicemapper | | apiserver_port | - | | name | coe-k8s-template | | created_at | 2018-11-28T12:58:21+00:00 | | network_driver | flannel | | fixed_network | - | | coe | kubernetes | | flavor_id | m1.small | | master_lb_enabled | False | | dns_nameserver | 8.8.8.8 | +-----------------------+--------------------------------------+ ~~~ Found couple of issues in the logs of VM started by magnum. - etcd was not getting started because of incorrect permission on file "/etc/etcd/certs/server.key". This file is owned by root by default have 0440 as permission. Changed the permission to 0444 so that etcd can read the file. After that etcd started successfully. - etcd DB doesn't contain anything: [root@kube-cluster1-qobaagdob75g-master-0 ~]# etcdctl ls / -r [root@kube-cluster1-qobaagdob75g-master-0 ~]# - Flanneld is stuck in activating status. ~~~ [root@kube-cluster1-qobaagdob75g-master-0 ~]# systemctl status flanneld ● flanneld.service - Flanneld overlay address etcd agent Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled; vendor preset: disabled) Active: activating (start) since Thu 2018-11-29 11:05:39 UTC; 14s ago Main PID: 6491 (flanneld) Tasks: 6 (limit: 4915) Memory: 4.7M CPU: 53ms CGroup: /system.slice/flanneld.service └─6491 /usr/bin/flanneld -etcd-endpoints=http://127.0.0.1:2379 -etcd-prefix=/atomic.io/network Nov 29 11:05:44 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:44.569376 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:45 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:45.584532 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:46 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:46.646255 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:47 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:47.673062 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:48 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:48.686919 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:49 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:49.709136 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:50 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:50.729548 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:51 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:51.749425 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:52 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:52.776612 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] Nov 29 11:05:53 kube-cluster1-qobaagdob75g-master-0.novalocal flanneld[6491]: E1129 11:05:53.790418 6491 network.go:102] failed to retrieve network config: 100: Key not found (/atomic.io) [3] ~~~ - Continuously in the jouralctl logs following messages are printed. ~~~ Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-apiserver[6888]: F1129 11:06:39.338416 6888 server.go:269] Invalid Authorization Config: Unknown authorization mode Node specified Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Main process exited, code=exited, status=255/n/a Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.408272 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:463: Failed to list *api.Node: Get http://127.0.0.1:8080/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.444737 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:460: Failed to list *api.Pod: Get http://127.0.0.1:8080/api/v1/pods?fieldSelector=spec.nodeName%21%3D%2Cstatu…: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.445793 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:466: Failed to list *api.PersistentVolume: Get http://127.0.0.1:8080/api/v1/persistentvolumes?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: Failed to start Kubernetes API Server. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Unit entered failed state. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal systemd[1]: kube-apiserver.service: Failed with result 'exit-code'. Nov 29 11:06:39 kube-cluster1-qobaagdob75g-master-0.novalocal kube-scheduler[2540]: E1129 11:06:39.611699 2540 reflector.go:199] k8s.io/kubernetes/plugin/pkg/scheduler/factory/factory.go:481: Failed to list *extensions.ReplicaSet: Get http://127.0.0.1:8080/apis/extensions/v1beta1/replicasets?resourceVersion=0: dial tcp 127.0.0.1:8080: getsockopt: connection refused ~~~ Any help on above issue is highly appreciated. Thanks & Regards, Vikrant Aggarwal __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

2 5

[i18n] Team meeting Thursday 07:00 UTC #openstack-meeting
by Frank Kloeker 12 Dec '18

12 Dec '18

Hello, just a reminder, we want to start this week with our new meeting format with combined meeting between I18n and Docs team. Next meeting would be start Thursday 07:00 UTC in #openstack-meeting. Logistic to see on [1]. Agenda is posted on [2]. Please add your topics if you want to discuss I18n things. kind regards Frank [1] http://eavesdrop.openstack.org/#I18N_Team_Meeting [2] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting

2 1

Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 12 Dec '18

12 Dec '18

Hi All, Let's go with approach 1 means migrating the Devstack and Tempest base jobs to Bionic. This will move most of the jobs to Bionic. We have two patches up which move all Devstack and Tempest jobs to Bionic and it's working fine. 1. All DevStack jobs to Bionic - https://review.openstack.org/#/c/610977/ - This will move devstack-minimal, devstack, devstack-ipv6, devstack-multinode jobs to bionic only for master which means it will be stein onwards. All these jobs will use xenial till stable/rocky. 2. All Tempest base jobs (except stable branches job running on master) to Bionic - https://review.openstack.org/#/c/618169/ - This will move devstack-tempest, tempest-all, devstack-tempest-ipv6, tempest-full, tempest-full-py3, tempest-multinode-full, tempest-slow jobs to bionic. Note- Even Tempest is branchless and these tempest jobs have been moved to Bionic, they will still use xenial for all stable branches(till stable/rocky) testing. with zuulv3 magic and devstack base jobs nodeset for stable branch (xenial) and master (stein onwards -bionic) will take care of that. Tested on [1] and working fine. Thanks corvus and clarkb for guiding to this optimized way. 3. Legacy jobs are not migrated to bionic. They should get migrated to Bionic while they are moved to zuulv3 native. So if your projects have many legacy jobs then, they will still run on xenial. Any job inherits from those base jobs will behave the same way (running on bionic from stein onwards and xenial till stable/rocky). I am writing the plan and next action item to complete this migration activity: 1 Project teams: need to test their jobs 1. which are inherited from devstack/tempest base jobs and should pass as it is 2. Any zuulv3 jobs not using devstack/tempest base job required to migrate to use bionic (Devstack patch provide the bionic nodeset) and test it. Start writing the results on etherpad[2] 2 QA team will merge the above patches by 10th Dec so that we can find and fix any issues as early and to avoid the same during release time. Let's finish the pre-testing till 10th Dec and then merge the bionic migration patches. [1] https://review.openstack.org/#/c/618181/ https://review.openstack.org/#/c/618176/ [2] https://etherpad.openstack.org/p/devstack-bionic -gmann ---- On Wed, 07 Nov 2018 08:45:45 +0900 Doug Hellmann <doug(a)doughellmann.com> wrote ---- > Ghanshyam Mann <gmann(a)ghanshyammann.com> writes: > > > ---- On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski <skaplons(a)redhat.com> wrote ---- > > > Hi, > > > > > > > Wiadomość napisana przez Jeremy Stanley <fungi(a)yuggoth.org> w dniu 06.11.2018, o godz. 22:25: > > > > > > > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: > > > > [...] > > > >> also add jobs like "devstack-xenial" and "tempest-full-xenial" > > > >> which projects can use still for some time if their job on Bionic > > > >> would be broken now? > > > > [...] > > > > > > > > That opens the door to piecemeal migration, which (as we similarly > > > > saw during the Trusty to Xenial switch) will inevitably lead to > > > > projects who no longer gate on Xenial being unable to integration > > > > test against projects who don't yet support Bionic. At the same > > > > time, projects which have switched to Bionic will start merging > > > > changes which only work on Bionic without realizing it, so that > > > > projects which test on Xenial can't use them. In short, you'll be > > > > broken either way. On top of that, you can end up with projects that > > > > don't get around to switching completely before release comes, and > > > > then they're stuck having to manage a test platform transition on a > > > > stable branch. > > > > > > I understand Your point here but will option 2) from first email lead to the same issues then? > > > > seems so. approach 1 is less risky for such integrated testing issues and requires less work. In approach 1, we can coordinate the base job migration with project side testing with bionic. > > > > -gmann > > I like the approach of updating the devstack jobs to move everything to > Bionic at one time because it sounds like it presents less risk of us > ending up with something that looks like it works together but doesn't > actually because it's tested on a different platform, as well as being > less likely to cause us to have to do major porting work in stable > branches after the release. > > We'll need to take the same approach when updating the version of Python > 3 used inside of devstack. > > Doug >

4 8

[oslo][tooz][requirements] Tooz etcd3 tests blocked on grpcio>=1.16.0
by Ben Nemec 12 Dec '18

12 Dec '18

The tooz gate is currently blocked on https://bugs.launchpad.net/python-tooz/+bug/1808046 which seems to have been introduced with grpcio 1.16.0. I need to raise that issue with the grpc folks, but in the meantime should we block the problematic versions? grpcio isn't currently in g-r and I can't remember what our policy on transitive dependencies is, so I thought I'd solicit opinions. Thanks. -Ben

5 8

[oslo][meeting] agenda topics - RFE Configuration mapping tool for upgrade priority tracking
by Herve Beraud 12 Dec '18

12 Dec '18

Hey folks, I've added a topics to the next oslo meeting agenda. I want to discuss about the migration and especially about RFE configuration mapping tool. The main goal is to discuss about it to raise the priority. FYI I summarize some useful elements in this email. Specs: * https://review.openstack.org/#/c/520043/ * https://review.openstack.org/#/c/526314/ * https://review.openstack.org/#/c/526261/ Code reviews: https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+… Some reviews was validated but some others need to be recovered due to the lack of response about the original authors. Do not hesitate to debate about this topics by responding at this thread to help us to have a better big picture before starting the meeting. Thanks folks. -- 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-----

1 0

[ops] [nova] How to get CPUtime and wallclokctime consumed by a project (without using ceilometer) ?
by Massimo Sgaravatto 12 Dec '18

12 Dec '18

Hi I was wondering if nova allows to get the CPUtime and wallclocktime consumed by a project in a certain time period, without using ceilometer Among the data returned by the command "openstack usage show" there is also a "CPU Hours" but, if I am not wrong, this is actually the WallClockTime. Did I get it right ? If so, it is also possible to get the CPUTime ? Thanks, Massimo

3 4

[barbican][castellan] failures in barbican/castellan cross test job
by Doug Hellmann 12 Dec '18

12 Dec '18

The patch https://review.openstack.org/622710 is trying to update the author address in the packaging metadata for castellan. The barbican-simple-crypto-devstack-tempest-castellan-from-git job is failing 5 tests, at least one of which gives the error message "Build of instance f211971d-0214-4b28-9b8c-c9ff92deabce aborted: cannot import name api", which appears to be a real error. Do barbican master and castellan master work together? Is there anyone with time to look into why that job is failing? -- Doug

1 0

[Searchlight][Zuul] tox failed tests at zuul check only
by Trinh Nguyen 12 Dec '18

12 Dec '18

Hello, Currently, [1] fails tox py27 tests on Zuul check for just updating the log text. The tests are successful at local dev env. Just wondering there is any new change at Zuul CI? [1] https://review.openstack.org/#/c/619162/ Thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

3 20

openstack magnum queens swarm error
by Ignazio Cassano 12 Dec '18

12 Dec '18

ello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio

1 0

openstack queens magnum error
by Ignazio Cassano 12 Dec '18

12 Dec '18

Hello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio

1 0

openstack queens magnum swarm error
by Ignazio Cassano 12 Dec '18

12 Dec '18

Hello Everyone, I installed queens on centos with magnum and I am trying to create a swarm cluster with one muster and one node. The image I used is fedora-atomic 27 update 04 The stack generated end with an error and magnum conductor reports: ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key api_address Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_masters Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key swarm_nodes Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not have output_key discovery_url Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.317 17964 ERROR magnum.drivers.heat.driver [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, stack status: CREATE_FAILED, stack_id: 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: WaitConditionFailure: resources.swarm_nodes.resources[0].resources.node_wait_condition: swarm-agent service failed to start. I connected to the master node for verifyng if swarm agent is running. In the cloud init log I found: requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries exceeded with url: /v3//auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] Connection timed out',)) Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 08:45:31 +0000. Up 55.54 seconds. 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-005 [1] /var/lib/cloud/instance/scripts/part-006: line 13: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 26: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-006: line 38: /etc/etcd/etcd.conf: No such file or directory 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-006 [1] Configuring docker network ... Configuring docker network service ... Removed /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. New size given (1280 extents) not larger than existing size (4863 extents) ERROR: There is not enough free space in volume group atomicos to create data volume of size MIN_DATA_SIZE=2G. 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-010 [1] + systemctl stop docker + echo 'starting services' starting services + systemctl daemon-reload + for service in etcd docker.socket docker swarm-manager + echo 'activating service etcd' activating service etcd + systemctl enable etcd Failed to enable unit: Unit file etcd.service does not exist. + systemctl --no-block start etcd Failed to start etcd.service: Unit etcd.service not found. + for service in etcd docker.socket docker swarm-manager + echo 'activating service docker.socket' activating service docker.socket + systemctl enable docker.socket 1) Seems etcd service is not installed , 2) the instance required to contact controller on port 5000 (is it correct ?) Please help me. Regards Ignazio

1 0

[heat] changing our meeting time, and no meeting this week
by Rico Lin 12 Dec '18

12 Dec '18

Dear team As we have some change recently, I will move Heat team meeting time to Wednesday 08:00 UTC, I will send the patch later. We will not hold a meeting today, but we definitely needs a meeting next week so we can spend some time to clear our debt. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update II - Dec 12, 2018
by Chandan kumar 11 Dec '18

11 Dec '18

Hello, Below is the another Iteration of updates on what happened in os_tempest[1.] side. Things got improved till Dec 4 - 12, 2018: * Use tempest run for generating subunit results - https://review.openstack.org/621584 Things still in progress: * Better blacklist and whitelist tests management - https://review.openstack.org/621605 * Use --profile feature for generating tempest.conf by passing all tempestconf named arguments in yaml file: - https://review.openstack.org/623187 - https://review.openstack.org/623413 * Use tempestconf rpm for generating tempest.conf in CentOS/SUSE distro Jobs: https://review.openstack.org/622999 Improvements in python-tempestconf: * Introducing profile feature to generate sample profile in tempestconf as well as user can create the same profile of named arguments and pass it to discover-tempest-config binary. It will help to improve automation across tooling. Next Week: * We will continue working on above in progress tasks. Here is the first update [2] and second update [3] Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136452.html [3.] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000537… Thanks, Chandan Kumar

1 0

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

11 Dec '18

Hi Team, Just a last minute reminder that the IRC is happening in a new time slot this week at 0300 UTC Tuesday (10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) / 11am beijing time (Wednesday)) Agenda for this week's meeting: 1. Finalize https://review.openstack.org/#/c/615462/ 2. Status update on various outstanding work items -- Thank you Regards Li

1 0

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

11 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

[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository[sahara][ops][tripleo][openstack-ansible][puppet-openstack][kolla][i18n] Upcoming split of the sahara repository
by Luigi Toscano 11 Dec '18

11 Dec '18

Hi all, we (sahara developers) are working on splitting the content of sahara.git, moving the code of each plugin to its own respository. Each plugin is used for a different Hadoop/Big Data provider. The change is better described in the following spec, which didn't happen in Rocky: http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outsi… The change is going to impact other projects, but hopefully not the users. I will try to summarize the impact on the various consumers of sahara. == Deployment tools - the devstack plugin in the test repository (see below) was modified to support the installation of all the available plugins previously available in- tree, so devstack users should not notice any change. - puppet-sahara will require changes to install the additional repositories, and we would require and welcome any help; - I hope that the puppet-sahara changes would be enough to make TripleO work, but we would need some help on this. - openstack-ansibe-os_sahara will require changes as well, but we have a bit more expertise on Ansible and we can help with the changes. - kolla will require some changes too, depending on te (apologize if I forgot some project) == Packaging It would be nice if users could get all the plugins packages by installing the same packages as before the split, but I understand that it may be tricky, because each plugin depends on the core of sahara. This means that a binary subpackage like openstack-sahara (RDO) or sahara (Debian) can't depend on the binary packages of the plugins, or that would introduce a circular dependency. I raised the issue on the RDO list to get some initial feedback and the solution that we are going to implement in RDO requires flipping the value of a variable to handle the bootstrap case and the normal case, please check: https://lists.rdoproject.org/pipermail/dev/2018-November/008972.html and the rest of the thread, like: https://lists.rdoproject.org/pipermail/dev/2018-December/008977.html Any additional idea from other packagers would be really appreciated, also because it has a direct impact on at least the puppet modules. == Preview The work-in-progress repositories are available here: Sahara: https://github.com/tellesnobrega/sahara/tree/split-plugins Plugins: * Ambari: https://github.com/tellesnobrega/sahara-plugin-ambari * CDH: https://github.com/tellesnobrega/sahara-plugin-cdh * MapR: https://github.com/tellesnobrega/sahara-plugin-mapr * Spark: https://github.com/tellesnobrega/sahara-plugin-spark * Storm: https://github.com/tellesnobrega/sahara-plugin-storm * Vanilla: https://github.com/tellesnobrega/sahara-plugin-vanilla Any comment is more than welcome! Ciao -- Luigi

3 3

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus, Session Summary: Autoscaling Integration, improvement, and feedback
by Joseph Davis 11 Dec '18

11 Dec '18

I agree with Duc and Witek that this communication could be really good. One of the first items for a new SIG would be to define the relationship with the Self-Healing SIG. The two SIGs have a lot in common but some important differences. They can both use some of the same tools and data (Heat, Monasca, Senlin, Vitrage, etc) to achieve their purpose, but Self-Healing is about recovering a cloud when something goes wrong, while Autoscaling is about adjusting resources to avoid something going wrong. Having a clear statement may help a new user or contributor understand where there interests lie and how they can be part of the group. Writing some clear use cases will be really valuable for all the component teams to reference. It may also be of value to identify a few reference architectures or configurations to illustrate how the use cases could be addressed. I'm thinking of stories like "A cloud with Monasca and Senlin services has 20 active VMs. When Monasca recognizes the 20 VMs have hit 90% utilization each it raises an alarm and Senlin triggers the creation of 5 more VMs to meet expected loads." Plus lots of details I just skipped over. :) joseph On Wed, Nov 28, 2018 at 4:00 AM Rico Lin<rico.lin.guanyu(a)gmail.com> wrote: > > I gonna use this ML to give a summary of the forum [1] and asking for > feedback for the idea of new SIG. > > So if you have any thoughts for the new SIG (good or bad) please share it > here. > > [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback On Thu, 29 Nov 2018 09:32:17 "Bedyk, Witold"<witold.bedyk(a)est.fujitsu.com> wrote: > Hi Rico, > > Thanks for this initiative. I think the SIG could be a good channel to coordinate this work across the projects. > > From Monasca perspective, I would like to make sure that we provide all necessary monitoring data to cover the defined use cases and that Monasca alarms can be seamlessly consumed by the integrated services. > We’re also interested in contributing documentation in the central place. > > I’m sure operators will be thankful for having a channel for providing dedicated feedback. > > Cheers > Witek

3 2

[scientific] No Scientific SIG meeting this week
by Blair Bethwaite 11 Dec '18

11 Dec '18

Hi all, Apologies for the late notice but we have 2 of 3 chairs travelling and one out of timezone this week. Cheers, b1airo

1 0

[neutron][ironic] Add Support for Smart NIC with baremetal
by Moshe Levi 11 Dec '18

11 Dec '18

Hi all, We started working on specs to support baremetal with smart-nic see [1] and [2]. There are some open issue and different approaches that require further discussion see [3]. To resolve them I would like to propose a meeting tomorrow , December 11th, at 15:00 UTC. For those of you interested in joining please use [4] to connect. [1] - https://review.openstack.org/#/c/582767/ [2] - https://review.openstack.org/#/c/619920/ [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics [4] - https://bluejeans.com/u/jkreger Thanks, Moshe (moshele)

2 1

[tc][all] Documenting the role of the TC
by Thierry Carrez 11 Dec '18

11 Dec '18

Hi everyone, At the Berlin Summit there was a Forum session to do a retrospective on the "TC vision for 2019" (written in April 2017). As Julia mentions in her summary[1] of that session, one action out of that session was to start working on a vision for the TC itself (rather than a vision by the TC for OpenStack), as a living document that would describe the role of the TC. Content was collaboratively drafted through an etherpad, then proposed as a governance review a few weeks ago. I just incorporated the latest early feedback in a revision. Please have a look at the current strawman and comment if you feel like something we are doing is missing, or something is there that should not be: https://review.openstack.org/622400 Like the "Technical vision for OpenStack clouds" document[2], this one is expected to be a living document describing the current situation, against which changes can be proposed. Once the initial version is approved, it will let us propose and discuss changes in the role of the TC. Thanks in advance for your comments ! [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000586… [2] https://governance.openstack.org/tc/reference/technical-vision.html -- Thierry Carrez (ttx)

1 0

[os-api-ref][doc] Removing inactive cores
by Stephen Finucane 11 Dec '18

11 Dec '18

We moved the os-api-ref project under the governance of the docs team at the beginning of the year. We've just done some housecleaning of the os-api-ref core list and have removed the following individuals owing to inactivity over the past 180 days. * Anne Gentle * Sean Dague * Karen Bradshaw We would like to thank them for their contributions and welcome them to rejoin the team if their priorities change. Stephen

1 0

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

11 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

[Searchlight] Weekly report for the week of Stein R-19 & R-18
by Trinh Nguyen 10 Dec '18

10 Dec '18

Hello team, Just so you know that we're having an issue with our functional tests [1]. Hopefully, I can fix it at the end of the week. [1] https://www.dangtrinh.com/2018/12/searchlight-weekly-report-stein-r-19-r.ht… Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

The 2nd Vietnam OSUG upstream contribution mentoring webinar
by Trinh Nguyen 10 Dec '18

10 Dec '18

Hello, Yes, we did it, the 2nd time [1] :). In this session, the OpenStack Upstream Contribution Mentoring program of the Vietnam OSUG focus on how to debug the OpenStack projects. We discussed and shared some experiences of using testing and debugging tools (tox, logs, zuul ci, ara, etc.). It was awesome! I also would love to mention Jitsi [2], the free and open source video conferencing tool. We make it through more than 1 hour of video chatting without any limitations or interruptions. The experience was great! I recommend you guys check this tool out if you want to organize video conferences. [1] https://www.dangtrinh.com/2018/12/viet-openstack-now-renamed-viet.html [2] https://jitsi.org/ Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[infra] OpenDev feedback forum session summary
by Jeremy Stanley 10 Dec '18

10 Dec '18

Wednesday afternoon at the OpenStack Summit we met to discuss the plan for the upcoming transition of the OpenStack Infrastructure team to an independent effort named OpenDev. Notes were recorded at https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features and form the basis of the summary with follows. For those unfamiliar with this topic, the announcement at http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html provides some background and context. Much of what follows may be a reiteration of things also covered there, so please excuse any redundancy on my part. To start out, we (re)announced that we have chosen a name (OpenDev) and a domain (opendev.org) so can more effectively plan for DNS changes for most of the services we currently host under the "legacy" (for us) openstack.org domain. It was also pointed out that while we expect to maintain convenience redirects and aliases from old hostnames for all services we reasonably can so as to minimize disruption, there will still be some unavoidable discontinuities for users from time to time as we work through this. We talked for a bit about options for decentralizing GitHub repository mirroring so that the current team no longer needs to maintain it, and how to put it in control of people who want to manage those organizations there for themselves instead. Doing this with a job in Zuul's post pipeline (using encrypted secrets for authentication) was suggested as one possible means to avoid users all maintaining their own separate automation to accomplish the same thing. Interest in bare metal CI nodes in nodepool was brought up again. To reiterate, there's not really any technical reason we can't use them, more that prior offers to donate access to Nova/Ironic-managed nodes for this purpose never panned out. If you work for an organization which maintains a "bare metal cloud" we could reach over the open Internet and you'd consider carving out some of your capacity for our CI system, please do get in touch with us! We spent a bit of time covering user concerns about the transition to OpenDev and what reassurances we ought to provide. For starters, our regular contributors and root systems administrators will continue to be just as reachable and responsive as ever via IRC and mailing lists, even if the names of the channels and MLs may change as part of this transition. Similarly, our operations will remain as open and transparent as they are today... really nothing about how we maintain our systems is changing substantively as a part of the OpenDev effort, though certainly the ways in which we maintain our systems do still change and evolve over time as we seek to improve them so that will of course continue to be the case. Paul Belanger raised concerns that announcing OpenDev could result in a flood of new requests to host more projects. Well, really, I think that's what we hope for. I (apparently) pointed out that even when StackForge was first created back at the beginning of 2012, there wasn't much restriction as to what we would be willing to host. As interest in OpenDev spreads to new audiences, interest in participating in its maintenance and development should too grow. That said, we acknowledge that there are some scalability bottlenecks and manual/human steps in certain aspects of new project onboarding for now, so should be very up-front with any new projects about that fact. We're also not planning for any big marketing push to seek out additional projects at this point, but are happy to talk to any who discover us and are interested in the services we offer. Next, Paul Belanger brought up the possibility of "bring your own cloud" options for projects providing CI resources themselves. While we expect nodepool to have support for tenant-specific resources in the not-too-distant future, Jim Blair and Clark Boylan agreed the large pool of generic resources we operate with now is really where we see a lot of benefit and ability to drive efficiencies of scale. Then Monty Taylor talked for a while, according to the notes in the pad, and said things about earmarked resources potentially requiring a sort of "commons tax" or... something. Jim Rollenhagen asked whether we would potentially start to test and gate projects on GitHub too rather than just our Gerrit. Clark Boylan and Jim Blair noted that the current situation where we're testing pull requests for Kata's repositories is a bit of an experiment in that direction today and the challenges we've faced suggest that, while we'll likely continue to act as a third-party CI system for some projects hosted on GitHub (we're doing that with Ansible for example), we've discovered that trying to enforce gating in code review platforms we don't also control is not likely something we'll want to continue in the long term. It came up that our earlier ideas for flattening our Git namespace to reduce confusion and minimize future repository renames is now not looking as attractive. Instead we're probably going to need to embrace an explosion of new namespaces and find better ways to cope with the pain of renames in Gerrit as projects want to move between them over time. We're planning to only run one Gerrit for simplicity, so artificially creating "tenants" in it through prefixes in repository names is really the simplest solution we have to avoid different projects stepping on one another's toes with their name choices. Then we got into some policy discussions about namespace creation. Jim Blair talked about the potential to map Git/Gerrit repository namespaces to distinct Zuul tenants, and someone (might have been me? I was fairly jet-lagged and so don't really remember) asked about who decides what the requirements are for projects to create repositories in a particular namespace. In the case of OpenStack, the answer is almost certainly the OpenStack Technical Committee or at least some group to whom they delegate that responsibility. The OpenStack TC needs to discuss fairly early what its policies are for the "openstack" namespace (whether existing unofficial projects will be allowed to remain, whether addition of new unofficial projects will be allowed there) as well as whether it wants to allow creation of multiple separate namespaces for official OpenStack projects. The suggestion of nested "deep" namespaces like openstack/nova/nova came up at this point too. We also resolved that we need to look back into the project rename plugin for Gerrit. The last time we evaluated it, there wasn't much there. We've heard it's improved with newer Gerrit releases, but if it's still lacking we might want to contribute to making it more effective so we can handle the inevitable renames more easily in the future. And finally, as happens with most forum sessions, we stopped abruptly because we ran over and it was Kendall Nelson's turn to start getting ops feedback for the Contributor Guide. ;) -- Jeremy Stanley

2 1

[loci] How to add some agent to loci images
by SIRI KIM 10 Dec '18

10 Dec '18

Hello, Jean. I tried to add lbaas-agent and fwaas-agent to official loci neutron image. To pass openstack-helm gate test, I need lbaas-agent and fwaas-agent. I found your openstack source repository is repository: 172.17.0.1:5000/loci/requirements Please let me know I can I add lbaas-agent and fwaas-agent to official loci neutron image. Thanks, Siri

4 4

[nova][dev] Stein blueprint tracking status
by melanie witt 10 Dec '18

10 Dec '18

Hey all, Similar to previous cycles, I've created an etherpad for tracking status of Approved blueprints for Stein: https://etherpad.openstack.org/p/nova-stein-blueprint-status Please feel free to use it to help with code reviews and make notes on the pad if there's info to add. I'll keep the pad updated as we progress through the rest of the cycle. Cheers, -melanie

1 0

[tc][forum] Summary for "community outreach when cultures, time zones, and languages differ" session
by Julia Kreger 10 Dec '18

10 Dec '18

Leading up to the Summit a number of us in the TC discussed how to improve outreach and thus communications outside of what we would consider our normal circles. The focus was how to better enable asynchronous communication. How do we share context? Ultimately we are talking about bridge building. The discussion went in many directions and we kind of started out discussing items that make our preferred communication methods a bit difficult. Thierry really focused us back to reality pointing out that "the earth is round". As the community has recognized before, time zones are absolutely a thing and that we shouldn't try and force people to be up at 3 AM to attend a meeting every week. As this discussion went on, a number of note worthy ideas began to surface. * Teams should likely reconsider meeting times periodically. Some teams have found success with alternating, but other teams have found that few attend the second time slot. * That it is easier to form a group of people in a specific time zone as they bring their established culture and don't have to integrate into another culture which is easier for them. The down side of this is that this leads to those people focusing on that specific project. * IRC is "super-addictive". ** The real time value of IRC is recognized, however on-boarding people into it can sometimes be a time consuming effort for some projects. ** Many, the TC included, have been trying to push more deep discussions to the mailing list or having someone summarize the outcome of conversations to the mailing list. ** IRC communication is often viewed as "too fast" of a discussion if your not a native speaker of the language being used in IRC. By the time you or software translates a statement, the discussion has moved on. * No matter what we do, there are two styles of communication that we need to be mindful of both asynchronous and synchronous communication. ** Some communities, such as the Linux kernel, have adopted fully asynchronous communication to handle the fact that the world is round. ** Projects have a tendency to use any communication method available. *** Some projects use etherpads for short term status on items, where others focus on its use for thought process preservation. *** Some projects try to drive such thought processes to an IRC discussion and then that often ends up as a discussion in gerrit. A point was eventually raised that meetings can still be useful, standing issues aside, as long as context is known in advance. The advance context does allow a team to determine in advance if a meeting is even required. Todo's and what can be done! * Simple reminders have apparently helped some meeting moderators keep people in attendance. * We reached consensus to encourage moderators to provide context in advance of meetings. This is in order to assist everyone to be more informed and hopefully shorten the exercise of trying to understand the issue as opposed to understand others impressions and reaching consensus. ** We also reached consensus that moderators should cancel a meeting if there is nothing on the agenda. * We want to encourage outreach messaging. This is not just the sub-communities making themselves known to the larger community, but raising awareness of "what is going on" or "what is new?" either in a project or portion of the community. Ultimately this falls into the category of "we do not know, what we do not know" and as such it is upon all of us to attempt to better communicate where we see gaps. As for specific action items, after re-reading the notes, I think that is up to us as a community to determine our next steps. We recorded no action items so I think further discussion may be needed. Perhaps all The etherpad can be found at https://etherpad.openstack.org/p/BER-tc-community-outreach. -Julia

1 0

[neutron][ironic] Add Support for Smart NIC with baremetal
by Moshe Levi 10 Dec '18

10 Dec '18

Hi all, We started working on specs to support baremetal with smart-nic see [1] and [2]. There are some open issue and different approaches that require further discussion see [3]. To resolve them I would like to propose a meeting tomorrow , December 11th, at 15:00 UTC. For those of you interested in joining please use [4] to connect. [1] - https://review.openstack.org/#/c/582767/ [2] - https://review.openstack.org/#/c/619920/ [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics [4] - https://bluejeans.com/u/jkreger Thanks, Moshe (moshele)

1 0

On trust and risk, Australia's Assistance and Access Bill
by Jeremy Stanley 10 Dec '18

10 Dec '18

I've seen concern expressed in OpenStack and other free/libre open source software communities over the recent passage of the "Assistance and Access Bill 2018" by the Australian Parliament, and just want to say that I appreciate the trust relationships we've all built with our colleagues in many countries, including Australia. As someone who doesn't particularly agree with many of the laws passed in his own country, while I'm not going to encourage civil disobedience, I do respect that many have shown preference for it over compelled compromise of our community's established trust. I, for one, don't wish to return to the "bad old days" of the crypto wars, when major projects like OpenBSD refused contributions from citizens and residents of the USA. It's bad for project morale, excludes valuable input from people with a variety of perspectives, and it's just downright inefficient too. The unfortunate truth is that anyone can be pressured at any time to derail, backdoor or otherwise compromise software and systems. A new law in one country doesn't change that. There are frequent news stories about government agencies installing covert interfaces in enterprise and consumer electronic devices alike through compulsion of those involved in their programming, manufacture and distribution. There's evidence of major standards bodies being sidetracked and steered into unwittingly approving flawed specifications which influential actors already know ways to circumvent. Over the course of my career I've had to make personal choices regarding installation and maintenance of legally-mandated systems for spying on customers and users. All we can ever hope for is that the relationships, systems and workflows we create are as resistant as possible to these sorts of outside influences. Sure, ejecting people from important or sensitive positions within the project based on their nationality might be a way to send a message to a particular government, but the problem is bigger than just one country and we'd really all need to be removed from our posts for pretty much the same reasons. This robust community of trust and acceptance we've fostered is not a risk, it's another line of defense against erosion of our ideals and principles. Entrenched concepts like open design and public review help to shield us from these situations, and while there is no perfect protection it seems to me that secret compromise under our many watchful eyes is a much harder task than doing so behind the closed doors of proprietary systems development. I really appreciate all the Australians who toil tirelessly to make OpenStack better, and am proud to call them friends and colleagues. I certainly don't want them to feel any need to resign from their valuable work because they're worried the rest of us can no longer trust them. -- Jeremy Stanley

5 4

[k8s] K8s-SIG-OpenStack Update
by Chris Hoge 10 Dec '18

10 Dec '18

Hi everyone, a quick update on SIG-OpenStack/K8s as we head into KubeCon. To start with, today David and I are at the contributors summit and will be available to catch up on any topics you're interested in personally. The only other event we have scheduled for KubeCon is the SIG Intro session[1], Tuesday at 2:35 PM in room 3A/B. Given the smaller turnout for the deep-dive session in Copenhagen, we opted to skip the deep dive session this time around. As such, the first half of the intro will serve as the official SIG-Update, then we will reserve the end of the time for collaboration and planning. If you're involved or interested in SIG-OpenStack at all, please be sure to make this session. Following up from the OpenStack Summit, we had a productive planning session and set a number of goals and tasks[2]. Top at the list is the rotation of the SIG leadership. We're currently accepting nominations to replace David Lyle and Robert Morse. Many thanks to both for serving this last year. Currently we have nominations for * Flavio Percoco * Melvin Hillsman If you would like to be considered for SIG leadership, or would like to nominate someone, please do so in this thread or personally to me. Another item on the agenda is the rebooting of the SIG-OpenStack/K8s meetings. We will return the previously scheduled time of Wednesdays at 4 PM PT, starting January 9. I'll be sending out agendas and reminders as we get closer to the date, and will be asking some sub-project owners to attend and contribute updates. Work on the cloud provider and associated code has been moving well, and the external provider has moved well beyond the capabilities of the now-deprecated in-tree provider. If you haven't started your migration plan off of the in-tree code, please start doing so now. We're targeting full removal in 2019. The OpenStack provider for the new Cluster API has started, and we are looking for more developers to get involved. This, and a possible Ironic provider, are important for the SIG to be involved with in the coming year. If SIG-Cluster-Lifecycle reaches its goals, the Cluster API will be one of the most valuable developments for operators and users in 2019. Finally, I continue to engage with SIG-Cloud-Provider as a co-lead to advocate for consistent provider development. One of the original goals was to wind down all provider SIGS. However, as the SIGs move beyond just provider code to larger support of a user and developer community, this plan is being reconsidered. I'll keep you updated on the developments. Thanks to everyone for your ongoing contributions, and I'm looking forward to seeing the folks who are attending KubeCon in Seattle. -Chris [1] Intro OpenStack SIG: https://sched.co/Grbk [2] SIG-K8s Berlin Summit Session: https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit

1 0

Re: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full?
by Ghanshyam Mann 10 Dec '18

10 Dec '18

---- On Tue, 02 Oct 2018 00:28:51 +0900 Matt Riedemann <mriedemos(a)gmail.com> wrote ---- > On 10/1/2018 8:37 AM, Ghanshyam Mann wrote: > > +1 on adding multiattach on integrated job. It is always good to cover more features in integrate-gate instead of separate jobs. These tests does not take much time, it should be ok to add in tempest-full [1]. We should make only really slow test as 'slow' otherwise it should be fine to run in tempest-full. > > > > I thought adding tempest-slow on cinder was merged but it is not[2] > > > > [1]http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-… > > [2]https://review.openstack.org/#/c/591354/2 > > Actually it will be enabled in both tempest-full and tempest-slow, > because there is also a multiattach test marked as 'slow': > TestMultiAttachVolumeSwap. > > I'll push patches today. While reviewing your patch and checking multiattach slow test on stable branch as part of tempest-slow job, I found that tempest-slow (tempest-multinode-full) job does not run on nova stable branches (even nova .zuul.yaml has that job to run for stable branch) which we can say bug on Tempest side because tempest-slow job definition is to run only on master [1]. I am trying to enable that for all stable branches[2]. I am getting few failure on tempest-slow (tempest-multinode-full) for stable branches which might take time to fix and till then let's keep nova-multiattach on stable branches and remove only for master. [1] https://github.com/openstack/tempest/blob/a32467c4c515dff325e6b4b5ce7af24a0… [2] https://review.openstack.org/#/q/topic:tempest-multinode-slow-stable+(statu… -gmann > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

2 2

Openstacl magnum Queens api error
by Ignazio Cassano 10 Dec '18

10 Dec '18

Hi All, I installed magnum in queens with Centos 7 and I am facing with the same issue descrive here: https://bugs.launchpad.net/magnum/+bug/1701381 Please, anyone solved it? Regards Ignazio

1 1

[charms] No meetings until January 7th
by Frode Nordahl 10 Dec '18

10 Dec '18

Dear charmers and community at large, We will be taking a break from our weekly meetings and will reconvene after the holidays. First weekly meeting will be Monday January 7th. In the meantime, do not hesitate to contact us in #openstack-charmers on Freenode or by sending e-mail to the OpenStack Discuss mailinglist using the [charms] tag in the subject line. Cheers all! -- Frode Nordahl

2 1