- openstack-discuss - lists.openstack.org

[tripleo] undercloud / standalone have switched to podman by default
by Emilien Macchi 17 Dec '18

17 Dec '18

For your information, default deployment of Undercloud and Standalone are now using Podman instead of Docker by default. The switch doesn't affect the Overcloud yet but we also aim to change the default before the end of Stein release. If you still want to use docker: * For Undercloud: undercloud.conf : container_cli = docker * For Standalone: in your environment: ContainerCli: docker Please let us know any problem regarding that change. -- Emilien Macchi

2 1

[neutron] Bug deputy report, December 10 - December 16
by Bernard Cafarelli 17 Dec '18

17 Dec '18

Hi neutron folks, we started a new rotation of bug deputies, which means it was my turn to watch over new bugs. Here is the list of reported bugs, I highlighted those worth another look (other high bugs already have pending patches) *Undecided* * https://bugs.launchpad.net/neutron/+bug/1808731 - Needs the method to stop metadata proxy Latest bug, discussion in progress - feedback welcome *High* * https://bugs.launchpad.net/neutron/+bug/1808136 - l2 pop doesn't always provide the whole list of fdb entries on OVS restart A follow-up to https://bugs.launchpad.net/neutron/+bug/1804842, patch proposed at https://review.openstack.org/#/c/624669/ * https://bugs.launchpad.net/neutron/+bug/1808595 - fullstack test neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_gateway_ip_changed failed intermittently Gate failure with patch proposed at https://review.openstack.org/#/c/625359/ * https://bugs.launchpad.net/neutron/+bug/1808541 - Openflow entries are not totally removed for stopped VM OVS flows issue (possible race condition?) - Has reproducer, details and logs but needs another pair of eyes *Medium* * https://bugs.launchpad.net/neutron/+bug/1808112 - rule:shared is not respected in port/subnet create waiting for feedback from policy experts * https://bugs.launchpad.net/neutron/+bug/1808171 - TaggedBootDevicesTest.test_tagged_boot_devices intermittently fails waiting for network-vif-plugged event which neutron does not send Intermittent gate failure in nova * https://bugs.launchpad.net/python-neutronclient/+bug/1808451 - Add Support for Querying Quotas with Usage CLI support for quotas detail, patch proposed at https://review.openstack.org/#/c/621507/ *RFE* * https://bugs.launchpad.net/neutron/+bug/1808062 - Limit VXLAN to within Neutron availability zones * https://bugs.launchpad.net/neutron/+bug/1808594 - Limit Geneve to within Neutron availability zones Clone of the previous one, for OVN (I added networking-ovn in affected projects) *Low* * https://bugs.launchpad.net/neutron/+bug/1807673 - Networking (neutron) concepts in neutron Easy doc fix ("facets" term use explanation) *Incomplete* * https://bugs.launchpad.net/neutron/+bug/1807483 - networksegments table in neutron can not be cleared automatically * https://bugs.launchpad.net/bugs/1808504 - the ip of port which device type is dhcp is null -- Bernard Cafarelli

1 0

[mistral] Standing down as PTL
by Dougal Matthews 17 Dec '18

17 Dec '18

Hey everyone, I am announcing that I am going to stand down as Mistral PTL. Due to a change in priorities I am no longer able to give the project the time it needs and deserves. This change will come into effect immediately. Being PTL has been a pleasure and a great learning experience for me. I have had the chance to work with a number of great folks and I am saddened to hang up the hat, particularly mid-cycle. However, I don't plan on going anywhere, I'll still be around and hope to remain an active member of the core team. Renat Akhmerov will be taking the role on again[1]. It is likely you will all know him as the previous Mistral PTL and therefore know the project will be in safe hands. Thanks everyone, Dougal [1]: https://review.openstack.org/#/c/625537/

2 1

[dev] [neutron] policy-in-code status update
by Akihiro Motoki 17 Dec '18

17 Dec '18

Hi neutrinos, I am working on policy-in-code support in neutron and have a good progress these weeks. [Progress] - The basic policy-in-code in neutron repo was merged. Several follow-up improvements and cleanup will be coming in the neutron repo. - policy-in-code support in several neutron related projects are proposed. There are found at https://review.openstack.org/#/q/topic:bp/neutron-policy-in-code+(status:op… [Request to neutron related project maintainers] neutron-dynamic-routing, neutron-fwaas,neutron-vpnaas, networking-bgpvpn, networking-sfc and vmware-nsx: I proposed patches. Review and testing from each team would be appreciated. networking-midonet and networking-cisco In my understanding, they defines its own resources and attributes, so their own policies exists. My bandwidth cannot cover them. Could you take over policy-in-code support? I belileve the above gerrit link would provide good examples. networking-ovn, networking-odl and networking-bagpipe In my understanding, they defines no extra resources and attributes, so there is no policies specific to them and policy-in-code support is unnecessary. Could you confirm my understanding is correct. If you need some policy definition, it means you need some work on policy-in-code. If you have questions, feel free to ask me. Best Regards, Akihiro Motoki (IRC: amotoki)

1 0

[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