- openstack-discuss - lists.openstack.org

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

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

15 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

[openlab] Maintenance Notification
by Melvin Hillsman 15 Dec '18

15 Dec '18

Hi everyone, Maintenance will be happening 12/19/2018 and 12/20/2018 so if you experience any issues we do apologize. Not everyone will be affected but it is just good to know these things even if you are not. Additionally we will not be able to onboard any new requests/projects/individuals during this time more than likely but please do fill out any requests and we will proceed as normal. If there is an issue we will work through as much as we can to fulfill requests. Kind regards, OpenLab

1 0

bug openstack queens magnum
by Ignazio Cassano 15 Dec '18

15 Dec '18

Hi All, I am facing the same issue wrote at this link: https://ask.openstack.org/en/question/116465/magnum-kubernetes-cluster-stuc… It happens for swarm and kubernets but works in swarm-mode. Please, help me Regards Ignazio

1 0

Re: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.
by Torin Woltjer 14 Dec '18

14 Dec '18

Looks like putting the same option on the other compute nodes did the trick. Originally I did that and it made no difference, but that must've been me not rebooting the test instances that were on that node during the change. Doing a cold migrate correctly updates the XML, so I'll have to cold migrate all of the production instances before I can live migrate them.

1 0

[neutron][stadium] Switch from ryu to os-ken
by Hongbin Lu 14 Dec '18

14 Dec '18

Hi all, Due to the advice that Ryu library won't be maintained at the end of 2018, the neutron team decided to fork the Ryu library and maintain the fork, which is called os-ken [1], from now on. Right now, both neutron [2] and neutron-dynamic-routing [3] is switching over to os-ken. If other projects want to do the same, please feel free to handout to the openstack-neutron channel for helps or information. You can also find more in here: https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-tra… . [1] https://github.com/openstack/os-ken [2] https://review.openstack.org/#/c/607008/ [3] https://review.openstack.org/#/c/608357/ Best regards, Hongbin

2 1

Open Infrastructure Summit Denver Contributor Discount Information
by Kendall Waters 14 Dec '18

14 Dec '18

Hi everyone, There have been a lot of questions about discounts for the upcoming Open Infrastructure Summit so I have outlined the contributor discounts that we will be giving out below. Contributor Discount (formally known as ATC or AUC discount) 50% off any 1 ticket type until online sales close (please note ticket prices are tiered so the earlier you use your discount code, the cheaper the ticket will be) - To qualify for this discount, you will need to either have contributed at least one commit which merged to an official governed OSF project or pilot project in the last 6 months as of January 1, 2019 or qualify as an AUC: http://superuser.openstack.org/articles/auc-community/ <http://superuser.openstack.org/articles/auc-community/> - Discount codes will be sent by the end of January Denver 2018 PTG Attendees 82% off the early bird price of the Summit + PTG combo ticket until early bird ends - To qualify for this discount, you must have attended the Denver PTG in September 2018 - Discount codes will be sent by the end of January Please let me know if you have any questions. Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall(a)openstack.org

2 2