December 2018 - openstack-discuss

[magnum] Core reviewers update
by Spyros Trigazis 17 Dec '18

17 Dec '18

Hello list, During 2018 magnum's repos became more active with notable contributions, in alphabetical order, from Blizzard, Catalyst Cloud and StackHPC. At the same time part of the core reviewers group was inactive. Adrian Otto, Eli Qiao, Jaycen Grant, Madhuri Kumari and Ton Ngo have agreed to step down and make room for new contributors. Thank you for all your contributions! I would like to encourage current core reviewers to participate in the project. Let's evaluate the status of the core team in three months (end of March 2019). Cheers, Spyros

1 0

Magnum queens requirements
by Ignazio Cassano 17 Dec '18

17 Dec '18

Hi All, Does magnum require etcd installed on controller and computes nodes? Which opentack services require etcd on controllers and computes? Recards ignazio

2 3

[dev][openstacksdk] openstacksdk and dogpile 0.7.0+ cache errors
by Ian Wienand 17 Dec '18

17 Dec '18

Hi, Just a heads up that the latest version of dogpile (0.7.0 onwards) have become incompatible with openstacksdk. This is causing a few issues for jobs. As usual, it's a little complex :) The error you will see is something like user_func.set = set_ AttributeError: 'method' object has no attribute 'set' The following are related: https://review.openstack.org/624697 : requirements change to pin https://review.openstack.org/624485 : openstacksdk pin https://review.openstack.org/624855 : fixes a nodepool job that openstacksdk depends on (note 624485 turns the job non-voting to break the circular dependency). The issue is being tracked in: https://storyboard.openstack.org/#!/story/2004605 : related story https://github.com/sqlalchemy/dogpile.cache/issues/140 : upstream github issue Thanks, -i

4 11

[Devstack][Freezer] ElasticSearch installation fails
by Trinh Nguyen 17 Dec '18

17 Dec '18

Dear devstack team, Recently, the ElasticSearch installation fails and that makes Freezer (e.g., [1]) or any other services that depend on ElasticSearch fail the CI tests. A preliminary investigation suggests that it may cause by the test environment was switched to Ubuntu 18.04 (i.e., bionic). I made some modifications to the installation script in [2] hopefully will fix the problem. If someone in the Devstack team can have look at [2], it would be great. [1] http://logs.openstack.org/49/624549/3/check/freezer-tempest-agent/d0a52d0/j… [2] https://review.openstack.org/#/c/625174/ Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[Searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 17 Dec '18

17 Dec '18

Hi team, We will have a team meeting today at 13:30 UTC on the #openstack-searchlight channel. Please join me for updates and discussion about the next steps of Searchlight. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

Re: [vitrage][monasca] Monasca datasource for Vitrage
by Joseph Davis 16 Dec '18

16 Dec '18

I left Bartosz some comments on his review, and I'll add a few things below. joseph On 12/13/18 12:52 AM, openstack-discuss-request(a)lists.openstack.org wrote > From: Ifat Afek <ifatafekn(a)gmail.com> > Message-ID: > <CALxdkcxxrtYYv+f4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg(a)mail.gmail.com> > > Hi Witek, > > On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold <witold.bedyk(a)est.fujitsu.com> > wrote: > > >>> 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. >> Correct. To make the picture complete: every alarm contains an associated >> `metric name` and a set of dimensions which identify the monitored >> resource. Both metric name and dimensions could potentially be used in >> Vitrage. >> >> >> >> 1. For OpenStack services we typically use dimension keys `hostname` and >> `service`. Examples would be: >> >> `name`: `http_status`, `dimensions`: {`hostname`: `node1`, >> `service`: `keystone`, `url`: `http://node1/identity` >> <http://node1/identity>} >> >> >> >> Libvirt metrics all have the dimension keys `hostname`, >> `service`=`compute`, `resource_id`=instance_id >> > > By instance_id do you mean the libvirt id or the OpenStack UUID? In order > to correlate the id with the vm that exists in Vitrage, we need the Nova > UUID. > Another question: are these dimensions names always the same? Is it > possible to change their names? > I believe it is the OpenStack id in each case. Dimension names are always the same per type of metric, but different metrics can define different dimensions. For example, the http_status metric has a 'url' but disk.space_used_perc has a 'device' and cpu.idle_perc has neither. All metrics have 'hostname', 'service', and a few other dimensions in common. >> 2. For other resources I’m not sure if we can define a general rule for >> assignments. As you have said, the unique information may be included in >> more the one dimension. >> >> >> >> For Prometheus, we use labels on each metric as dimensions. Additional >> dimensions can be configured in agent per Prometheus endpoint. >> We also have a monasca-ceilometer component (aka. Ceilosca) that can send metrics from Ceilometer to Monasca. These metrics include the OpenStack resource_id of the source of the metric. Any alarms created from Ceilometer data can carry through that resource_id. From what I've seen we don't currently include a resource_type, but that should be something we can configure in the metric. If nothing else, we may be able to statically define the resource_type as part of the metric definition (each alarm will be specific to the type of resource anyway). But don't hold me to that - I have some more reading to do to understand the nuances. :) The dimensions from the metrics are carried over to the alarms. > <snip> > Can you give us some more examples of Monasca dimensions? As Witek said, the metric dimensions are pretty flexible. You can see some of the dimensions mentioned in my answer above. I can try to pull a list of some standard alarm definitions and associated metrics from a SUSE install, or if we have a particular few alarms we want to start with then we can focus on those.

2 1

[magnum] cluster node fail to establish connection (wrong IP address)
by Zufar Dhiyaulhaq 16 Dec '18

16 Dec '18

Hi I am creating a swarm cluster with this command : - openstack coe cluster template create swarm-cluster-template --image fedora-atomic-latest --external-network external --dns-nameserver 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode --docker-volume-size 4 --docker-storage-driver=devicemapper - openstack coe cluster create swarm-cluster --cluster-template swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. I get this : - requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] Connection timed out',)) - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 17:36:44 +0000. Up 33.29 seconds. Swarm Instance try to open connection to 10.60.60.10 which is my management ip address on OpenStack. But it cannot (by design it cannot, I try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 which is my floating IP and external IP for OpenStack cluster, it works. Anyone know how to change the cloud-init to curl into 10.61.61.10? Best Regards, Zufar Dhiyaulhaq

2 10

[magnum] region_name needs to be configured in magnum.conf
by Zufar Dhiyaulhaq 16 Dec '18

16 Dec '18

I am following installation guide from magnum documentation. but I get an error when trying to create kubernetes cluster. *region_name needs to be configured in magnum.conf* this is my full log : [root@zu-bssn-controller1 opt]# openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster bfdf76df-8b43-44e3-a094-90a76189610a accepted [root@zu-bssn-controller1 opt]# openstack coe cluster list +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | uuid | name | keypair | node_count | master_count | status | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey | 1 | 1 | CREATE_FAILED | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ [root@zu-bssn-controller1 opt]# openstack coe cluster show kubernetes-cluster +---------------------+---------------------------------------------------+ | Field | Value | +---------------------+---------------------------------------------------+ | status | CREATE_FAILED | | cluster_template_id | 560f72a9-d6ac-4404-ad9e-3cd129496022 | | node_addresses | [] | | uuid | bfdf76df-8b43-44e3-a094-90a76189610a | | stack_id | None | | status_reason | region_name needs to be configured in magnum.conf | | created_at | 2018-12-14T11:25:37+00:00 | | updated_at | 2018-12-14T11:25:40+00:00 | | coe_version | None | | labels | {} | | faults | {} | | keypair | mykey | | api_address | None | | master_addresses | [] | | create_timeout | 60 | | node_count | 1 | | discovery_url | None | | master_count | 1 | | container_version | None | | name | kubernetes-cluster | | master_flavor_id | amphora | | flavor_id | amphora | +---------------------+---------------------------------------------------+ [root@zu-bssn-controller1 opt]# Anyone know what is happening? Best Regards, Zufar Dhiyaulhaq

2 8

Re: [openstack-community] Asking for suggestion of video conference tool for team and webinar
by Trinh Nguyen 15 Dec '18

15 Dec '18

I just tried Jitsi and the experience was amazing! Thank everyone for the suggestion! :) On Sat, Nov 17, 2018 at 9:59 AM Trinh Nguyen <dangtrinhnt(a)gmail.com> wrote: > Thank Thierry, Arun, and everybody for all the suggestions. My team will > try these tools. > > On Thu, Nov 8, 2018 at 3:23 AM Arun Kumar Khan <arun.k.khan(a)gmail.com> > wrote: > >> >> On Tue, Nov 6, 2018 at 5:36 AM Trinh Nguyen <dangtrinhnt(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> I tried several free tools for team meetings, vPTG, and webinars but >>> there are always drawbacks ( because it's free, of course). For example: >>> >>> - Google Hangout: only allow a maximum of 10 people to do the video >>> calls >>> - Zoom: limits about 45m per meeting. So for a webinar or conference >>> call takes more than 45m we have to splits into 2 sessions or so. >>> >>> If anyone in the community can suggest some better video conferencing >>> tools, that would be great. So we can organize better communication for our >>> team and the community's webinars. >>> >> >> All good suggestions. >> >> A couple of other options: >> >> 1. https://hubl.in -- open source i.e. you can host your own or use the >> hosted version at https://hubl.in/ >> 2. Wire.com -- open source with mobile apps. >> >> Let us know which solution works out for you. >> >> -- Arun Khan >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz <https://www.edlab.xyz>* > > -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[OpenStack][RabbitMQ] nove-compute running on controller node can not connect to rabbitmq
by Soheil Pourbafrani 15 Dec '18

15 Dec '18

Hi, I have 2 nodes on my OpenStack cluster. One act as both the controller node and the compute node and the other act as the compute node. All services were running well for days until I activate a new NIC interface to the controller node. Now the problem is the nova-compute service of the compute node can connect to the RabittMQ server but the nova-compute service of the controller node connecting to the RabiitMQ server got an error and fails. Here are the RabbitMQ logs when I start nova-compute service on the controller node: =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471 =INFO REPORT==== 15-Dec-2018::11:02:15 === accepting AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672 - nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672 - nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee): client unexpectedly closed TCP connection =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672 - nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672 - nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f): client unexpectedly closed TCP connection What is the problem?

1 0