- openstack-discuss - lists.openstack.org

[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 12 Dec '18

12 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 12 Dec '18

12 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 12 Dec '18

12 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