August 2020 - openstack-discuss - lists.openstack.org

[nova][ops] Live migration and CPU features
by Belmiro Moreira 21 Aug '20

21 Aug '20

Hi, in our infrastructure we have always compute nodes that need a hardware intervention and as a consequence they are rebooted, bringing a new kernel, kvm, ... In order to have a good compromise between performance and flexibility (live migration) we have been using "host-model" for the "cpu_mode" configuration of our service VMs. We didn't expect to have CPU compatibility issues because we have the same hardware type per cell. The problem is that when a compute node is rebooted the instance domain is recreated with the new cpu features that were introduced because of the reboot (using centOS). If there are new CPU features exposed, this basically blocks live migration to all the non rebooted compute nodes (those cpu features are not exposed, yet). The nova-scheduler doesn't know about them when scheduling the live migration destination. I wonder how other operators are solving this issue. I don't like stopping OS upgrades. What I'm considering is to define a "custom" cpu_mode for each hardware type. I would appreciate your comments and learn how you are solving this problem. Belmiro

5 6

[glance][horizon][ops] Dashboard show Forbidden 403 but openstack cli works fine
by Amjad Kotobi 21 Aug '20

21 Aug '20

Hi, We are running Train release, currently facing below error when change to “Images” panel on the project which I have “User” role. The image is visibility is public. Error: Forbidden. Insufficient permissions of the requested operation Error: Unable to retrieve the project. By using openstack-cli everything works and I do not face “Forbidden” 403, but in dashboard “access.log” it shows "GET /dashboard/api/keystone/projects/7331defd55ef479fbf0a9a1ac3fe9055 HTTP/1.1” 403 http://xxxxxx/dashboard/project/images” I checked: 1. glance: policy.json from both dashboard and api/registry hosts are same. 2. From dashboard API images is 2 As soon as I change the OWNER of image to the project which my role = USER the error disappears. Any ideas or previous encounter similar to this issue? Thanks Amjad

1 0

Using os_token
by Eric K. Miller 21 Aug '20

21 Aug '20

Hi, It looks like the OS_TOKEN environment variable can be set so a token can be re-used instead of a new authentication for each CLI command with the OpenStack Client. I'm a little confused as to how this works and haven't found any good documentation on the subject. I would have expected to be able to: 0) set appropriate OS_* variables for password authentication 1) create a token using "openstack token issue" 2) unset all OS_* environment variables 3) set OS_TOKEN to the token's value provided in #1 4) set OS_AUTH_TYPE to "v3token" 5) set OS_AUTH_URL to the respective KeyStone endpoint 6) set OS_IDENTITY_API_VERSION to "3" 7) use the CLI as normal However, I get a "The service catalog is empty." message. Maybe I'm missing something above or am I completely misunderstanding the purpose of the OS_TOKEN variable? >From examples I have seen, it looks like the token can be used in a REST API call. Is there a way to use an existing token with the CLI, instead, so a new token is not issued for every CLI command instantiation? Thanks! Eric

1 0

Re: [requirements][oslo] Inclusion of CONFspirator in openstack/requirements
by Adrian Turjak 21 Aug '20

21 Aug '20

On 21/08/20 9:16 am, Ben Nemec wrote: > > In general, given the complexity of what you're talking about I think > a driver plugin would be the way to go, as opposed to trying to fit > this all in with the core oslo.config functionality (assuming you/we > decide to pursue integrating at all). > > There were a few other things you mentioned as features of the > library. The following are some off-the-cuff thoughts without having > looked too closely at the library, so if they're nonsense that's my > excuse. > > "because I have plugins that need to dynamically load config on > startup, which then has to be lazy_loaded" > > Something like this could probably be done. I believe this is kind of > how the castellan driver in oslo.config works. Config values are > looked up and cached on-demand, as opposed to all at once. This one is a little weird, but essentially the way this works this in Adjutant: I load the config so I can start the app and go through base logic and loading plugins, but the config groups that are pulled from plugins aren't added to my config group tree until AFTER the config has already been loaded. So part of the config is usable, but some hasn't yet fully been loaded until after the plugins are done, and then that subtree will lazy_load itself when first accessed. It means that until a given lazy_loaded group is actually accessed as config, the config tree underneath it can still have config options added. It's likely not too crazy to do this in oslo, and have groups only read from the cached source (loaded file dict) when first accessed. > > "I also have weird overlay logic for defaults that can be overridden" > > My knee-jerk reaction to this is that oslo.config already supports > overriding defaults, so I assume there's something about your use case > that didn't mesh with that functionality? Or is this part of > oslo.config that you reused? Sooo, this one is a little special because what this feature lets you do is take any group in the config tree once loaded, and call the overlay function on it with either a dict, or another group. The returned value will be a deep copy of the config tree with the values present in the given dict/group overlaid on that original group. As in a depth first dict update, where only keys that exist on the overriding dict will be updated in the copy of the original dict. I need to write the docs for this... with a sane example, but here is my unit test for it: https://gitlab.com/catalyst-cloud/confspirator/-/blob/master/confspirator/t… I use this in Adjutant by having some config groups which are a default for something, and another place where many things can override that default via another group in the config, so I create an overlay copy and pass that to the place that needs the config it it's most specific case when the code actually pulls values from the conf group I passed it. See: https://opendev.org/openstack/adjutant/src/branch/master/adjutant/actions/v… I hope that helps, because it is in my mind a little odd to explain, but it allows some useful things when reusing actions in different tasks. > "I also have nested config groups that need to be named dynamically to > allow plugin classes to be extended without subclasses sharing the > same config group name." > > Minus the nesting part, this is also something being done with > oslo.config today. The config driver feature actually uses dynamically > named groups, and I believe at least Cinder is using them too. They do > cause a bit of grief for some config tools, like the validator, but it > is possible to do something like this. Cool! yeah I implemented that feature in my code because I ran into a case of confliciting namespaces and needed to find a better way to handle subclasses that needed to have different dynamic names for their config groups. > > Now, as to the question of whether we should try to integrate this > library with oslo.config: I don't know. Helpful, right? That's mostly where we got to last time I asked in #openstack-oslo! > > I think answering that question definitively would take a deeper dive > into what the new library is doing differently than I can commit to. > As I noted above, I don't think the things you're doing are so far out > in left field that it would be unreasonable to consider integrating > into oslo.config, but the devil is in the details and there are a lot > of details here that I don't know anything about. For example, will > the oslo.config data model even accommodate nested groups? I suspect > it doesn't now, but could it? Probably, but I can't say how > difficult/disruptive it would be. I looked into it briefly, and to do what I wanted, while also maintaining oslo.config how it was... ended up a bit messy, so I gave up because it would take too long and the politics of trying to get it merged/reviewed wouldn't be worth the effort most likely. > > If someone wanted to make incremental progress toward integration, I > think writing a basic YAML driver for oslo.config would be a good > start. It would be generally useful even if this work doesn't go > anywhere, and it would provide a basis for a hypothetical future > YAML-based driver providing CONFspirator functionality. From there we > could start looking to integrate more advanced features one at a time. > > Apologies for the wall of text. I hope you got something out of this > before your eyes glazed over. > > -Ben > Thanks for the wall of text! It was useful! I think ultimately it may be safer just maintaining my own separate library. For people who don't want to use .ini and prefer yaml/toml it's simpler, and for people who prefer .ini and don't need nesting etc, it's safer to keep oslo.config as it is. If someone does find anything I've done that makes sense in oslo.config I'd be happy to work porting it over, but I don't want to make structural changes to it. I'll always keep an eye on oslo.config, and may occasionally steal the odd idea if you add something cool, but I think other than my use of types.py and some of the Opt classes as a base, my code has diverged quite a bit.

1 0

per user quota not working properly
by its-openstack＠zohocorp.com 21 Aug '20

21 Aug '20

Dear openstack, We are facing a peculiar issue with regards to users quota of resources. e.g: s.no project user instance quota no instance created 1 test - 10 2 test user1 2 2 3 test user2 2 error "quota over" 4 test user3 3 able to create only 1 instance 5 test user4 no user quota defined able to create 10 instance As you see from mentioned table. when user1,user2, has instance quota of 2 and when user1 has created 2 instance, user2 unable to create instance. but user3 able to create only 1 more instance, user 4 has no quota applied so project quota 10 will be applied and he can create 10 instance. the quota is applied to each user but not tracked for each user, so this defeats the purpose of per user quota. Please help us with resolving this issue. Regards, sysadmin team

1 0

[largescale-sig] RPC ping
by Arnaud Morin 21 Aug '20

21 Aug '20

Hey all, TLDR: I propose a change to oslo_messaging to allow doing a ping over RPC, this is useful to monitor liveness of agents. Few weeks ago, I proposed a patch to oslo_messaging [1], which is adding a ping endpoint to RPC dispatcher. It means that every openstack service which is using oslo_messaging RPC endpoints (almosts all OpenStack services and agents - e.g. neutron server + agents, nova + computes, etc.) will then be able to answer to a specific "ping" call over RPC. I decided to propose this patch in my company mainly for 2 reasons: 1 - we are struggling monitoring our nova compute and neutron agents in a correct way: 1.1 - sometimes our agents are disconnected from RPC, but the python process is still running. 1.2 - sometimes the agent is still connected, but the queue / binding on rabbit cluster is not working anymore (after a rabbit split for example). This one is very hard to debug, because the agent is still reporting health correctly on neutron server, but it's not able to receive messages anymore. 2 - we are trying to monitor agents running in k8s pods: when running a python agent (neutron l3-agent for example) in a k8s pod, we wanted to find a way to monitor if it is still live of not. Adding a RPC ping endpoint could help us solve both these issues. Note that we still need an external mechanism (out of OpenStack) to do this ping. We also think it could be nice for other OpenStackers, and especially large scale ops. Feel free to comment. [1] https://review.opendev.org/#/c/735385/ -- Arnaud Morin

10 31

[requirements][oslo] Inclusion of CONFspirator in openstack/requirements
by Adrian Turjak 21 Aug '20

21 Aug '20

Hey OpenStackers! I'm hoping to add CONFspirator to openstack/requirements as I'm using it Adjutant: https://review.opendev.org/#/c/746436/ The library has been in Adjutant for a while but I didn't add it to openstack/requirements, so I'm trying to remedy that now. I think it is different enough from oslo.config and I think the features/differences are ones that are unlikely to ever make sense in oslo.config without breaking it for people who do use it as it is, or adding too much complexity. I wanted to use oslo.config but quickly found that the way I was currently doing config in Adjutant was heavily dependent on yaml, and the ability to nest things. I was in a bind because I didn't have a declarative config system like oslo.config, and the config for Adjutant was a mess to maintain and understand (even for me, and I wrote it) with random parts of the code pulling config that may or may not have been set/declared. After finding oslo.config was not suitable for my rather weird needs, I took oslo.config as a starting point and ended up writing another library specific to my requirements in Adjutant, and rather than keeping it internal to Adjutant, moved it to an external library. CONFspirator was built for a weird and complex edge case, because I have plugins that need to dynamically load config on startup, which then has to be lazy_loaded. I also have weird overlay logic for defaults that can be overridden, and building it into the library made Adjutant simpler. I also have nested config groups that need to be named dynamically to allow plugin classes to be extended without subclasses sharing the same config group name. I built something specific to my needs, that just so happens to also be a potentially useful library for people wanting something like oslo.config but that is targeted towards yaml and toml, and the ability to nest groups. The docs are here: https://confspirator.readthedocs.io/ The code is here: https://gitlab.com/catalyst-cloud/confspirator And for those interested in how I use it in Adjutant here are some places of interest (be warned, it may be a rabbit hole): https://opendev.org/openstack/adjutant/src/branch/master/adjutant/config https://opendev.org/openstack/adjutant/src/branch/master/adjutant/feature_s… https://opendev.org/openstack/adjutant/src/branch/master/adjutant/core.py https://opendev.org/openstack/adjutant/src/branch/master/adjutant/api/v1/op… https://opendev.org/openstack/adjutant/src/branch/master/adjutant/actions/v… https://opendev.org/openstack/adjutant/src/branch/master/adjutant/actions/v… https://opendev.org/openstack/adjutant/src/branch/master/adjutant/tasks/v1/… https://opendev.org/openstack/adjutant/src/branch/master/adjutant/tasks/v1/… If there are strong opinions about working to add this to oslo.config, let's chat, as I'm not against merging this into it somehow if we find a way that make sense, but while some aspects where similar, I felt that this was cleaner without being part of oslo.config because the mindset I was building towards seemed different and oslo.config didn't need my complexity. Cheers, Adrian

2 1

[cloudkitty] Resuming CloudKitty IRC meetings
by Pierre Riteau 21 Aug '20

21 Aug '20

Hello, We are resuming IRC meetings for the CloudKitty project using the existing calendar schedule. The first meeting will be on Monday August 24 at 1400 UTC in #cloudkitty on freenode, then every two weeks. Everyone is welcome: contributors, users, and anyone who would like to contribute or use CloudKitty but doesn't know how to get started. The agenda is available on Etherpad [1]. The meeting description [2] was stating that meetings were on the first and third Monday of the month, but the calendar schedule was using odd weeks. I've submitted a change [3] to synchronise the description: let's meet on odd weeks instead of using a month-based schedule. Thanks in advance to all of you helping to keep the project going. Pierre Riteau (priteau) [1] https://etherpad.opendev.org/p/cloudkitty-meeting-topics [2] http://eavesdrop.openstack.org/#CloudKitty_Team_Meeting [3] https://review.opendev.org/#/c/747256/

3 6

[Neutron] Drivers meeting agenda
by Slawek Kaplonski 21 Aug '20

21 Aug '20

Hi, Here is agenda for tomorrow's drivers meeting. We have 2 RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1891334 - [RFE] Enable change of CIDR on a subnet * https://bugs.launchpad.net/neutron/+bug/1892200 - Make keepalived healthcheck more configurable There are also some points from Rodolfo on the on demand agenda but Rodolfo is on PTO this week so probably we will discuss those topics finally next week. See You on the meeting tomorrow and have a nice day :) -- Slawek Kaplonski Principal software engineer Red Hat

1 0

[release] Release countdown for week R-7 Aug 24 - 28
by Sean McGinnis 21 Aug '20

21 Aug '20

Development Focus ----------------- We are entering the last weeks of the Victoria development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-ATC freeze, in preparation for future elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote. This is done by adding extra-atcs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on August 28. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (Sept 3). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (Sept 10) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, Sept 10. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (Sept 24) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (Oct 8) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (Sept 10). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: September 3 (R-6 week) Client library freeze: September 10 (R-5 week) Victoria-3 milestone: September 10 (R-5 week) Victoria release: October 14

1 0

[all] Proposed Wallaby cycle schedule
by Sean McGinnis 21 Aug '20

21 Aug '20

Hey everyone, The Victoria cycle is going by fast, and it's already time to start planning some of the early things for the Wallaby release. One of the first steps for that is actually deciding on the release schedule. Typically we have done this based on when the next Summit event was planned to take place. Due to several reasons, we don't have a date yet for the first 2021 event. The current thinking is it will likely take place in May (nothing is set, just an educated guess, so please don't use that for any other planning). So for the sake of figuring out the release schedule, we are targeting a release date in early May. Hopefully this will then align well with event plans. I have a proposed release schedule up for review here: https://review.opendev.org/#/c/744729/ For ease of viewing (until the job logs are garbage collected), you can see the rendered schedule here: https://0e6b8aeca433e85b429b-46fd243db6dc394538bd0555f339eba5.ssl.cf1.rackc… There are always outside conflicts, but I think this has aligned mostly well with major holidays. But please feel free to comment on the patch if you see any major issues that we may have not considered. Thanks! Sean

1 2

[tripleo] Moving tripleo-ansible-inventory script to tripleo-common?
by Cédric Jeanneret 20 Aug '20

20 Aug '20

Hello there! I'm wondering if we could move the "tripleo-ansible-inventory" script from the tripleo-validations repo to tripleo-common. The main motivation here is to make things consistent: - that script calls content from tripleo-common, nothing from tripleo-validations. - that script isn't only for the validations, so it makes more sense to install it via tripleo-common - in fact, we should probably push that inventory thing as an `openstack tripleo' sub-command, but that's another story So, is there any opposition to this proposal? Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

4 5

[neutron] Disable dhcp drop rule
by Eugen Block 20 Aug '20

20 Aug '20

Hi *, we recently upgraded our Ocata Cloud to Train and also switched from linuxbridge to openvswitch. One of our instances within the cloud works as DHCP server and to make that work we had to comment the respective part in this file on the compute node the instance was running on: /usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_firewall.py Now we tried the same in /usr/lib/python3.6/site-packages/neutron/agent/linux/openvswitch_firewall/firewall.py /usr/lib/python3.6/site-packages/neutron/agent/linux/iptables_firewall.py but restarting openstack-neutron-openvswitch-agent.service didn't drop that rule, the DHCP reply didn't get through. To continue with our work we just dropped it manually, so we get by, but since there have been a couple of years between Ocata and Train, is there any smoother or better way to achieve this? This seems to be a reoccuring request but I couldn't find any updates on this topic. Maybe someone here can shed some light? Is there more to change than those two files I mentioned? Any pointers are highly appreciated! Best regards, Eugen

2 3

OpenStack with Nginx
by HARISH KUMAR Ivaturi 20 Aug '20

20 Aug '20

Hi I am Harish Kumar, Master Student at BTH, Karlskrona, Sweden. I am working on my Master thesis at BTH and my thesis topic is Performance evaluation of OpenStack with HTTP/3. I have successfully built curl and nginx with HTTP/3 support and I am performing some commands using curl for generating tokens so i could access the services of OpenStack. OpenStack relies with the Apache web server and I could not get any results using Nginx HTTP/3 . I would like to ask if there is any official documentation on OpenStack relying with Nginx?, I have searched in the internet reg. this info but could not get any, I would like to use nginx instead of apache web server , so I could get some results by performing curl and commands and nginx web server (with http/3 support). Please let me know and if there is any content please share with me. I hope you have understood this. It would be helpful for my Master Thesis. BR Harish Kumar

2 1

[upstream-institute] Virtual training sign-up and planning
by Ildiko Vancsa 20 Aug '20

20 Aug '20

Hi mentors, I’m reaching out to you as the next Open Infrastructure Summit is approaching quickly so it is time to start planning for the next OpenStack Upstream Institute. As the next event will be virtual we will need to re-think the training format and experience to make sure our audience gets the most out of it. I created a new entry on our training occasions wiki page here: https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions#Virt… Please __sign up on the wiki__ if you would like to participate in the preparations and running the virtual training. As it is still vacation season I think we can target the last week of August or first week of September to have the first prep meeting and can collect ideas here or discuss them on the #openstack-upstream-institute IRC channel on Freenode in the meantime. Please let me know if you have any questions or need any help with signing up on the wiki. Thanks and Best Regards, Ildikó

1 1

[neutron][ops] API for viewing HA router states
by Mohammed Naser 20 Aug '20

20 Aug '20

Hi all, Over the past few days, we were troubleshooting an issue that ended up having a root cause where keepalived has somehow ended up active in two different L3 agents. We've yet to find the root cause of how this happened but removing it and adding it resolved the issue for us. As we work on improving our monitoring, we wanted to implement something that gets us the info of # of active routers to check if there's a router that has >1 active L3 agent but it's hard because hitting the /l3-agents endpoint on _every_ single router hurts a lot on performance. Is there something else that we can watch which might be more productive? FYI -- this all goes in the open and will end up inside the openstack-exporter: https://github.com/openstack-exporter/openstack-exporter and the Helm charts will end up with the alerts: https://github.com/openstack-exporter/helm-charts Thanks! Mohammed -- Mohammed Naser VEXXHOST, Inc.

5 12

[cinder][ops] "Berlin" 2020 Virtual Forum - Cinder brainstorming
by Brian Rosmaita 20 Aug '20

20 Aug '20

This message is aimed at anyone with an interest in the OpenStack Block Storage Service, whether as an operator, a user, or a developer. Like all the other teams, Cinder would like to get feedback from operators and users about the current state of the software, get some ideas about what should be in the next release, and have some strategic discussion about The Future. So if you have some ideas you'd like to be considered, feel free to propose a topic: https://etherpad.opendev.org/p/2020-Wallaby-cinder-brainstorming You only need to add a sentence or two describing your topic and it doesn't have to be very polished, so if you have an idea, just go to the etherpad and slap it down now while you're thinking about it. The deadline for proposals to the Foundation is 14 September, so if you could get your idea down on the etherpad before the Cinder weekly meeting on Wednesday 9 September 14:00 UTC, that will give the Cinder team time to look them over. thanks! brian

1 0

[tripleo][ci] container pulls failing
by Wesley Hayutin 19 Aug '20

19 Aug '20

FYI... If you find your jobs are failing with an error similar to [1], you have been rate limited by docker.io via the upstream mirror system and have hit [2]. I've been discussing the issue w/ upstream infra, rdo-infra and a few CI engineers. There are a few ways to mitigate the issue however I don't see any of the options being completed very quickly so I'm asking for your patience while this issue is socialized and resolved. For full transparency we're considering the following options. 1. move off of docker.io to quay.io 2. local container builds for each job in master, possibly ussuri 3. parent child jobs upstream where rpms and containers will be build and host artifacts for the child jobs 4. remove some portion of the upstream jobs to lower the impact we have on 3rd party infrastructure. If you have thoughts please don't hesitate to share on this thread. Very sorry we're hitting these failures and I really appreciate your patience. I would expect major delays in getting patches merged at this point until things are resolved. Thank you! [1] HTTPError: 429 Client Error: Too Many Requests for url: http://mirror.ca-ymq-1.vexxhost.opendev.org:8082/v2/tripleotrain/centos-bin… [2] https://bugs.launchpad.net/tripleo/+bug/1889122

8 20

[neutron] CI meeting cancelled
by Slawek Kaplonski 19 Aug '20

19 Aug '20

Hi, I have today some internal meeting in the same time as Neutron CI meeting is. Also, some of the team members who are usually attending this meeting are on pto this week so lets cancel it. If You see any CI related issue, please open LP and ping me on IRC. -- Slawek Kaplonski Principal software engineer Red Hat

1 0

[cloudkitty][tc] Cloudkitty abandoned?
by Sean McGinnis 19 Aug '20

19 Aug '20

Posting here to raise awareness, and start discussion about next steps. It appears there is no one working on Cloudkitty anymore. No patches have been merged for several months now, including simple bot proposed patches. It would appear no one is maintaining this project anymore. I know there is a need out there for this type of functionality, so maybe this will raise awareness and get some attention to it. But barring that, I am wondering if we should start the process to retire this project. From a Victoria release perspective, it is milestone-2 week, so we should make a decision if any of the Cloudkitty deliverables should be included in this release or not. We can certainly force releases of whatever is the latest, but I think that is a bit risky since these repos have never merged the job template change for victoria and therefore are not even testing with Python 3.8. That is an official runtime for Victoria, so we run the risk of having issues with the code if someone runs under 3.8 but we have not tested to make sure there are no problems doing so. I am hoping this at least starts the discussion. I will not propose any release patches to remove anything until we have had a chance to discuss the situation. Sean

11 20

[cloudkitty][rdo] Broken cloudkitty RPMs on CentOS8
by Pierre Riteau 19 Aug '20

19 Aug '20

Hello, This issue was discovered on Kolla train-centos8 images, but I assume it applies to both Train and Ussuri for CentOS 8 in general, not just to Kolla. CloudKitty became timezone-aware in Train: https://review.opendev.org/#/c/669192/ This code references tz.UTC from the dateutil library. However, this was added only in dateutil 2.7.0, while train-centos8 Kolla images use package python3-dateutil-2.6.1-6.el8.noarch.rpm, causing the error captured at the end of this message [2]. I submitted a patch to raise the minimum requirement for dateutil in cloudkitty: https://review.opendev.org/#/c/742477/ However, how are those requirements taken into consideration when packaging OpenStack in RDO? RDO packages for CentOS7 provide python2-dateutil-2.8.0-1.el7.noarch.rpm, but there is no such package in the CentOS8 repository. Would it be better to just remove the use of tz.UTC? I believe we could use dateutil.tz.tzutc() instead. Thanks, Pierre Riteau (priteau) [1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-train/Packages/p/ [2] Error trace below: 2020-07-22 16:33:11.207 26 ERROR wsme.api [req-3c49884a-1412-42bb-a57e-e7c731360148 ef450a969a2945928d3ade785eaae860 19df0f36ede14c29be9ca476222f8ba9 default - -] Server-side error: "module 'dateutil.tz' has no attribute 'UTC'". Detail: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/wsmeext/pecan.py", line 85, in callfunction result = f(self, *args, **kwargs) File "/usr/lib/python3.6/site-packages/cloudkitty/api/v1/controllers/storage.py", line 71, in get_all paginate=False) File "/usr/lib/python3.6/site-packages/cloudkitty/storage/v2/influx.py", line 311, in retrieve begin, end = self._check_begin_end(begin, end) File "/usr/lib/python3.6/site-packages/cloudkitty/storage/v2/influx.py", line 271, in _check_begin_end end = tzutils.get_next_month() File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line 150, in get_next_month return add_delta(start, datetime.timedelta(days=month_days)) File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line 104, in add_delta return utc_to_local(local_to_utc(dt, naive=True) + delta) File "/usr/lib/python3.6/site-packages/cloudkitty/tzutils.py", line 52, in local_to_utc output = dt.astimezone(tz.UTC) AttributeError: module 'dateutil.tz' has no attribute 'UTC'

1 0

[openstack-helm] openstack-helm-images release stable/ussuri loci images building issue
by Hemant Sonawane 19 Aug '20

19 Aug '20

Hello, I am trying to build a *loci openstack-helm-images release stable/ussuri *but there is an issue with each image I am building which could be related to the python version and pip package but I am really not sure about it. I also tried to update the python version for each package in requirements repo but it didn't help. Is there any way to upgrade the python version and pip as well in requirements? or does anybody know how to resolve this issue while building openstack-helm-images? I have attached logs for your ready reference. Help will be much appreciated thanks :) -- Thanks and Regards, Hemant Sonawane

1 0

VM doesn't have internet - OpenStack Ussuri with OVN networking
by Reza Bakhshayeshi 19 Aug '20

19 Aug '20

Hi all, I've set up OpenStack Ussuri with OVN networking manually, VMs can ping each other through an internal network. I've created a provider network with valid IP subnet, and my problem is VMs don't have internet access before and after assigning floating IP. I've encountered the same problem on TripleO (with dvr), and I just wanted to investigate the problem by manual installation (without HA and DVR), but the same happened. Everything seems working properly, I can't see any error in logs, here is agent list output: [root@controller ~]# openstack network agent list +--------------------------------------+------------------------------+------------------------+-------------------+-------+-------+-------------------------------+ | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | +--------------------------------------+------------------------------+------------------------+-------------------+-------+-------+-------------------------------+ | 1ade76ae-6caf-4942-8df3-e3bc39d2f12d | OVN Controller Gateway agent | controller.localdomain | n/a | :-) | UP | ovn-controller | | 484f123f-5935-44ce-aee7-4102271d9f11 | OVN Controller agent | compute.localdomain | n/a | :-) | UP | ovn-controller | | 01235c13-4f32-4c4f-8cf6-e4b8d59a438a | OVN Metadata agent | compute.localdomain | n/a | :-) | UP | networking-ovn-metadata-agent | +--------------------------------------+------------------------------+------------------------+-------------------+-------+-------+-------------------------------+ On the controller I got br-ex with a valid IP address. here is the external-ids table on controller and compute node: [root@controller ~]# ovs-vsctl get Open_vSwitch . external-ids {hostname=controller.localdomain, ovn-bridge=br-int, ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="10.0.0.11", ovn-encap-type=geneve, ovn-remote="tcp:10.0.0.11:6642", rundir="/var/run/openvswitch", system-id="1ade76ae-6caf-4942-8df3-e3bc39d2f12d"} [root@compute ~]# ovs-vsctl get Open_vSwitch . external-ids {hostname=compute.localdomain, ovn-bridge=br-int, ovn-encap-ip="10.0.0.31", ovn-encap-type=geneve, ovn-remote="tcp:10.0.0.11:6642", rundir="/var/run/openvswitch", system-id="484f123f-5935-44ce-aee7-4102271d9f11"} and I have: [root@controller ~]# ovn-nbctl show switch 72fd5c08-6852-4d7e-b9b4-7e0a1ccdd976 (neutron-b8c66c3d-f47a-42a5-bd2d-c40c435c0376) (aka net01) port cf99f43b-0a18-4b91-9ca5-b6ed3f86d994 type: localport addresses: ["fa:16:3e:d0:df:82 192.168.0.100"] port 4268f511-bee3-4da0-8835-b9a8664101c4 addresses: ["fa:16:3e:35:f2:02 192.168.0.135"] port 846919e8-cde5-4ba3-b003-0c06e73676ed type: router router-port: lrp-846919e8-cde5-4ba3-b003-0c06e73676ed switch bb22224e-e1d1-4bb2-b57e-1058e9fc33a7 (neutron-9614546f-b216-4554-9bfe-e8d6bb11d927) (aka provider) port 2f05c7bc-ad0f-4a41-bbd8-5fef1f5bfd2c type: localport addresses: ["fa:16:3e:17:7b:5b X.X.X.X"] port provnet-9614546f-b216-4554-9bfe-e8d6bb11d927 type: localnet addresses: ["unknown"] port 23fcdc9d-2d11-40c9-881e-c78e871a3314 type: router router-port: lrp-23fcdc9d-2d11-40c9-881e-c78e871a3314 router 0bd35585-b0a3-4c8f-b71b-cb87c9fad060 (neutron-8cdcd0d2-752c-4130-87bb-d2b7af803ec9) (aka router01) port lrp-846919e8-cde5-4ba3-b003-0c06e73676ed mac: "fa:16:3e:4d:c3:f9" networks: ["192.168.0.1/24"] port lrp-23fcdc9d-2d11-40c9-881e-c78e871a3314 mac: "fa:16:3e:94:89:8e" networks: ["X.X.X.X/22"] gateway chassis: [1ade76ae-6caf-4942-8df3-e3bc39d2f12d 484f123f-5935-44ce-aee7-4102271d9f11] nat 8ef6167a-bc28-4caf-8af5-d0bf12a62545 external ip: " X.X.X.X " logical ip: "192.168.0.135" type: "dnat_and_snat" nat ba32ab93-3d2b-4199-b634-802f0f438338 external ip: " X.X.X.X " logical ip: "192.168.0.0/24" type: "snat" I replaced valid IPs with X.X.X.X Any suggestion would be grateful. Regards, Reza

1 1

[scientific-sig] IRC meeting starting shortly
by Stig Telfer 19 Aug '20

19 Aug '20

Hi All - We have a Scientific SIG IRC meeting starting shortly in channel #openstack-meeting. Everyone is welcome. This week's agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_August_18th_2020 We'd like to cover some upcoming (virtual) events - Supercomputing 2020 and the OpenStack PTG. Cheers, Stig

1 0

[monasca] Setup Monasca from scratch
by Antonios Dimtsoudis 19 Aug '20

19 Aug '20

Hi all, i am trying to set up Monasca from scratch. Is there a good introduction / point to start of you would recommend? Thanks in advance, Antonios.

2 1

[tripleo] Help needed to write a Third Party integration guide
by Emilien Macchi 19 Aug '20

19 Aug '20

Hi people, We have been requested several times (for good reasons) about how to write out-of-tree files for TripleO integration (Heat templates, Ansible roles, Container Images layouts, etc). For example, Dell has an external repository ( https://github.com/dell/tripleo-powerflex) where they have pretty much all they need to install their services in out-of-tree fashion (I'm sure there are more examples, this one is just the most recent in my knowledge). This model is recommended for the third party services that aren't part of TripleO but still want to be integrated with it. This usually fits when the service can't be maintained by the TripleO team but there is a desire from outside of the community to maintain some integration (e.g. vendors). We haven't done a good job at providing a full end to end guide on how to achieve this and very often asked people to just do it. I propose that we work on this guide together and today I'm gathering for volunteers who have knowledge on that field or are interested to learn about it and contribute it back directly into a new guide, hosted on tripleo-docs repo. https://bugs.launchpad.net/tripleo/+bug/1892072 This will probably involve a bunch of linking to existing docs but also a good opportunity to update what is outdated in our content and provide more information where needed. Thanks for letting us know if you're interested to be actively contributing into that effort, -- Emilien Macchi

2 1

GHC Mentors Needed for OpenStack
by Amy Marrich 19 Aug '20

19 Aug '20

Grace Hopper Conference is going virtual this year and once again OpenStack is participating as one of the Open Source Day projects. We are hoping to do some peer programming (aka mentees shadowing folks while they work through a patch) as part of the day. Mentors receive a full conference pass and AnitaB.org membership. Please check out the requirements <https://ghc.anitab.org/get-involved/volunteer/committee-members-and-scholar…>{0} and apply <https://ghc.anitab.org/get-involved/volunteer/committee-members-and-scholar…>(1) by August 19, 2020. We are also figuring a way for more folks to be able to mentor, so if you'd like to help but aren't interested in the conference please reach out to me or Victoria(vkmc) by email or on IRC. Thanks and apologies for the short deadline though I can probably get let additions in:) Amy (spotz) 0- Grace Hopper mentorship requirements: https://ghc.anitab.org/get-involved/volunteer/committee-members-and-scholar… 1- Grace Hopper mentorship application: https://ghc.anitab.org/get-involved/volunteer/committee-members-and-scholar…

2 2

[all][PTL][TC] Forum Brainstorming
by Kendall Nelson 18 Aug '20

18 Aug '20

Hello Everyone! The Virtual Forum is approaching. We would love 1 volunteer from the community for the Forum Selection Committee. Ideally, the volunteer would already be serving in some capacity in a governance role for your project. In addition to calling for volunteers for the Forum selection committee, this email kicks off the brainstorming period before the CFP tool opens for formal Forum submissions. The categories for brainstorming etherpads have already been setup here[1]. Please add your etherpads and ideas there! The CFP tool will open on August 31st and will close September 14th. For information on the upcoming virtual Summit[2]. For more information on the Forum[3]. Please reach out to jimmy(a)openstack.org or knelson(a)openstack.org if you're interested. Volunteers should respond on or before August 31, 2020. Thanks! Kendall (diablo_rojo) [1] Virtual Forum 2020 Wiki: https://wiki.openstack.org/wiki/Forum/Virtual2020 [2] Virtual Open Infra Summit Site: https://www.openstack.org/summit/2020 [3] General Forum Wiki: https://wiki.openstack.org/wiki/Forum

1 0

[tc] weekly update
by Mohammed Naser 18 Aug '20

18 Aug '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Reviews - Move towards single office hour https://review.opendev.org/745200 - Drop all exceptions for legacy validation https://review.opendev.org/745403 - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 - Fix names inside check-review-status https://review.opendev.org/745913 - Resolution to define distributed leadership for projects https://review.opendev.org/744995 - Move towards dual office hours in diff TZ https://review.opendev.org/746167 - [draft] Add assert:supports-standalone https://review.opendev.org/722399 ## Project Updates - Add python-dracclient to be owned by Hardware Vendor SIG https://review.opendev.org/745564 ## General Changes - Add legacy repository validation https://review.opendev.org/737559 - Clean up expired i18n SIG extra-ATCs https://review.opendev.org/745565 - Sort SIG names in repo owner list https://review.opendev.org/745563 - Drop neutron-vpnaas from legacy projects https://review.opendev.org/745401 - Pierre Riteau as CloudKitty PTL for Victoria https://review.opendev.org/745653 - Declare supported runtimes for Wallaby release https://review.opendev.org/743847 ## Abandoned Changes - Move towards dual office hours https://review.opendev.org/745201 # Email Threads - Zuul Native Jobs Goal Update #2: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016561.h… - Masakari Project Aliveness: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016520.h… - vPTG October 2020 Signup: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016497.h… - OpenStack Client vs python-*clients: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016409.h… # Other Reminders - Virtual Summit Community voting closes Monday, August 17 at 11:59pm Pacific Time Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[oslo] Feature Freeze is approaching
by Ben Nemec 18 Aug '20

18 Aug '20

Hi Oslo contributors, Oslo observes a feature freeze that is earlier than other projects. This is to allow time for features in Oslo to be adopted in the services before their feature freeze. And it's coming up soon. Aug. 28th is the Oslo feature freeze date for this cycle. That leaves about two weeks for features to be merged in Oslo libraries. After that, any features to be merged will require a feature freeze exception, which can be requested on the list. If you have any questions about this feel free to contact me here or on IRC (bnemec in #openstack-oslo). Thanks! -Ben

1 0

cross-team action items
by Corey Bryant 17 Aug '20

17 Aug '20

These were the items from the cross team today that need action from our team: Bootstack: What’s the plan for Ceph-osd w/ openstack-on-lxd for Bluestore? Can we give an answer as to whether we plan to deprecate or solve this, one way or another? Bootstack: Gnocchi thread - can we respond to thread to make official decision so they can plan accordingly? ie. if upstream is not supported, we likely won't support, so if we can clarify then bootstack can remove from standard deploys. SEG: LP#1891096 <https://bugs.launchpad.net/charm-ceph-mon/+bug/1891096> - configuration database support for mimic+: Any value that exists in the configuration database will no longer receive updates from ceph.conf. Will be subscribed to field-high. Thanks, Corey

1 0

[all][goals] Switch legacy Zuul jobs to native - update #2
by Luigi Toscano 17 Aug '20

17 Aug '20

Hi, Much progress has happened since the first report, almost 4 weeks ago. Let's summarize the main documents: - the goal: https://governance.openstack.org/tc/goals/selected/victoria/native-zuulv3-j… - the document above now includes the reference to the up-to-date Zuul v3 porting guide: https://docs.openstack.org/project-team-guide/zuulv3.html - the etherpad which tracks the current status: https://etherpad.opendev.org/p/goal-victoria-native-zuulv3-migration - the previous report: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016058.html If you still have legacy jobs around, please prioritize this porting work. Victoria branching is not far away (actually, quite close for client libraries). This is the list of projects which still need to complete the work. Most of the legacy jobs derive from legacy-dsvm-base, and those are the most important ones. There is a limited amount of jobs which derive from legacy-base that should be taken into account as well, though. - barbican (*) - blazar (*) - cinder (/) (-> yes, this is my fault for the record :) - designate (+) - ec2-api (*) - freezer (*) - heat (/) - infra (/) - ironic (*) - karbor (*) - magnum (*) - manila (/) - but only devstack-base - monasca (+) - murano (/) - neutron (*) - nova (*) - oslo (*) - senlin - trove (+) - vitrage - zaqar The symbol close to the project name provides more detals about the status: (+) means that the project cores are at least aware of the issue, (*) means that there was active pending reviews for some of the remaining jobs, (/) means that there was past activity but no open reviews currently I'd just like to remind everyone that, while not part of the main goal, backporting the new jobs to the older branches when possible will make future maintenance easier. Ciao -- Luigi

1 0

[neutron] bug deputy report for week of 2020-08-10
by Bence Romsics 17 Aug '20

17 Aug '20

Hi, This is last week's buglist. Probably due to summer vacations but we have a few bugs without an owner. High: * https://bugs.launchpad.net/neutron/+bug/1891307 SSH fails in neutron-ovn-tripleo-ci-centos-8-containers-multinode job gate-failure, unassigned * https://bugs.launchpad.net/neutron/+bug/1891309 Designate integration - internal server error in Neutron gate-failure, unassigned * https://bugs.launchpad.net/neutron/+bug/1891517 neutron.tests.unit.common.test_utils.TimerTestCase.test__enter_with_timeout fails once in a while gate-failure, proposed fix: https://review.opendev.org/746154 * https://bugs.launchpad.net/neutron/+bug/1891673 qrouter ns ip rules not deleted when fip removed from vm proposed fix: https://review.opendev.org/746336 Needs further triage by someone knowing the designate integration better than I do: * https://bugs.launchpad.net/neutron/+bug/1891333 strange behavior of dns_domain with designate multi domain * https://bugs.launchpad.net/neutron/+bug/1891512 neutron designate DNS dns_domain assignment issue Low: * https://bugs.launchpad.net/neutron/+bug/1891243 neutron tempest failure: neutron_tempest_plugin.api.test_extensions.ExtensionsTest.test_list_extensions_includes_all OVN sample devstack conf did not enable all service plugins needed for tempest tests proposed fix: https://review.opendev.org/745829 Whishlist: * https://bugs.launchpad.net/neutron/+bug/1891360 Floating IP agent gateway IP addresses not released when deleting dead DVR L3 agents unassigned * https://bugs.launchpad.net/neutron/+bug/1891448 L3 agent mode transition between dvr and dvr_no_external unassigned RFE: * https://bugs.launchpad.net/neutron/+bug/1891334 [RFE] Enable change of CIDR on a subnet Best regards, Bence (rubasov)

1 0

[glance] Virtual PTG October 2020
by Abhishek Kekane 17 Aug '20

17 Aug '20

Hi Team, There is a project signup process going on for virtual PTG October 2020. I will like to book slots for the same between 1400 UTC to 1700 UTC. Please let me know your convenience for the same. Thanks & Best Regards, Abhishek Kekane

1 0

[neutron] How to specify overlay network interface when using OVN and Geneve?
by Popoi Zen 17 Aug '20

17 Aug '20

Hi, I have used my google fu but I cant find any reference. Just want to know how to specify overlay network when Im using geneve as my overlay protocol?

4 4

[neutron][ovn][sfc] Is it possible to use SFC (Service Function Chaining) on provider network?
by Popoi Zen 16 Aug '20

16 Aug '20

I have look some guide about SFC, but it seems that SFC only used on private/selfservice network. Is it possible to steer traffic between instance when they use provider network? I always getting error when using provider network. Maybe, can I push flow rule direct on OVN database or something like that?

1 0

[Interop-WG] Inviting cross-projects discussions for new re-branding efforts (Oct 26)
by prakash RAMCHANDRAN 16 Aug '20

16 Aug '20

Hi all, I have booked for two hours slot to enable re-branding efforts we are looking to unleash in early 2021.As part of "Open Infrastructure Summit" we kick-start with Inter-op for next decade. Monday October 26 13UTC - 15UTC InteropWG We would like to encourage Open Infrastructure Projects to enlighten the stage with Out-of-Box thinking & requests for Interop in Marketplace in OSF. - Integrated Projects in OpenStack have well served thru last decades dream team, that has stood the Tempest tests for RefStackV1 being base for OPNFV-CNTT / ONAP/ and CVP/OVP1 of LFN - Its the turn to the Open Infra Projects like Kata, Airship, Zuul, StarlingX and potential https://openinfralabs.org/ to innovate and suggest the world How OSF can leverage next-gen Infra with k8s cluster as baseline for Milt-cluster , Hybrid Cloud, Muti-cloud RefStackV2 for upstream usage for Telco and Edge Clouds We need all Graduated and Incumbent Projects to propose how we can Re-Brand them for Open Infra Containerized workloads. Do you want to use Magnum, Zun, Kolla & Kuryer - refer https://etherpad.opendev.org/p/interop Should we collaborate with LFN re-imagining efforts via our RefStack2 plans as base for Open Infra Summit efforts to give Industry a wake up call to collaborate? Please reply with comments below, where are the global innovators hiding behind Alps & Himalaya, come and swing your ping pongs balls or Cricket Bats. The Rocky mountains curve balls will always haunt you if you don't speak-up./*================================================================================================================Your comments +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ Lets join the collaboration for unfinished transition to Containers world with Interoperability. Our committee members are all aligned to back you on our journey and ensure we bring the ideas that matter and execution that lits fire.https://www.openstack.org/summit/2020/vote-for-presentations#/24735 ThanksPrakash RamchandranFor Interop WG / OSF

2 1

[openstack-ansible] New core on board!
by Dmitriy Rabotyagov 16 Aug '20

16 Aug '20

Hey everyone! Today we have several reasons to celebrate! First of all, we have released OSA Ussuri with tag 21.0.0 (better late than never :p). And even more exciting announcement, that Andrew Bonney is our new OpenStack-Ansible Core reviewer! Even though usual proposal process has been skipped this time, I think everyone will agree that Andrew deserved it and it's high time we congratulated him with becoming part of our team. Welcome on board, Andrew! -- Kind Regards, Dmitriy Rabotyagov

3 2

Trouble to launch a instance in open stack
by Midhunlal Nb 15 Aug '20

15 Aug '20

Hi all, --> I created an openstack set up in my networking lab. ---> Vmware installed in one of the blade server then ubuntu 18.04 installed as OS. ---> openstack 5.3.1 version successfully installed in this os ---> In my lab we are using 192.168.x.x/16 network ---> In openstack I created an external network with 192.168.x.x/16 ----> In openstack I created an internal network with 172.16.x.x/16(for testing) -----> then I created 1 external network(provider network),1 router,1 private cloud . ------> In internal network I created 2 instance (172.16.0.2&172.16.0.3)this two instance pinging each other and i am able assign floating ip(192.168.x.x) to this instance ----> Now my problem is I created a original instance with my network(192.168.x.x)in provider network(that instance directly attached to external (provider network)) --->This instance launched successfully and interface ip also our internal ip and dns also showing correct but i am not able to ping our any one of the lab network ip,internet also not available. please help me on this Thanks & Regards Midhunlal N B +918921245637

1 0

[release] Release countdown for week R-8 Aug 17 - 21
by Sean McGinnis 14 Aug '20

14 Aug '20

General Information ------------------- We are getting close to some of the end of cycle deadlines. Please be aware of the upcoming non-client library freeze on September 3. The following cycle-with-intermediary deliverables only did one release during the ussuri cycle, and have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we have suggested [1] as a potential release model change for the following deliverables: adjutant-ui adjutant cloudkitty heat-agents magnum-ui monasca-thresh monasca-ui [1] https://review.opendev.org/#/q/topic:victoria-cwi PTLs and release liaisons for each of those deliverables can either +1 the release model change, or propose an intermediary release for that deliverable. In absence of answer by the end of R-8 week we'll abandon the patch. We also published a couple of options for a proposed release schedule for the upcoming Wallaby cycle. Please check out the separate thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016391.h… 26 week schedule: https://review.opendev.org/745911/ 29 week schedule: https://review.opendev.org/744729/ Upcoming Deadlines & Dates -------------------------- Non-client library freeze: September 3 (R-6 week) Client library freeze: September 10 (R-5 week) Victoria-3 milestone: September 10 (R-5 week) Victoria release: October 14

1 0

Re: [Telemetry] Error when sending to prometheus pushgateway
by Samuel Mutel 14 Aug '20

14 Aug '20

Hello, I didn't find the issue. Somebody could help me ? Thanks. Le mer. 8 juil. 2020 à 17:55, Samuel Mutel <samuel.mutel(a)gmail.com> a écrit : > Hello, > > Thanks for your help. I tried to test the pushgateway manually and it > seems to work fine. The pushgateway wrote some things on the stdout. > But when I start the ceilometer, nothing happens. I tried to change the IP > to use 127.0.0.1 but nothing. > > Here is my ceilometer.conf: > >> [DEFAULT] >> auth_strategy = keystone >> debug = False >> event_dispatchers = gnocchi >> meter_dispatchers = gnocchi >> transport_url = rabbit://openstack:xxxxxx@xx.xx.x.xx >> ,openstack:xxxxxxx@xx.xx.x.xx,openstack:xxxxxxxxx@xx.xx.x.xx/ >> >> [cache] >> backend = dogpile.cache.memcached >> enabled = True >> memcache_servers = xx.xx.x.xx:11211,xx.xx.x.xx:11211,xx.xx.x.xx:11211 >> >> [keystone_authtoken] >> auth_type = password >> auth_uri = https://xxxxxxxxxxxx:5000/v3 >> auth_url = https://xxxxxxxxxxxx:5000 >> memcached_servers = xx.xx.x.xx:11211,xx.xx.x.xx:11211,xx.xx.x.xx:11211 >> password = xxxxxx >> project_domain_id = default >> project_name = service >> region_name = RegionOne >> user_domain_id = default >> username = ceilometer >> www_authenticate_uri = https://xxxxxxxxxxxx:5000 >> >> [notification] >> pipelines = meter >> >> [oslo_messaging_notifications] >> driver = messagingv2 >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [publisher] >> telemetry_secret = xxxxxxxxx >> >> [service_credentials] >> auth_type = password >> auth_url =https://xxxxxxxxxxxx:5000 >> password = xxxxxxxxx >> project_domain_id = default >> project_name = service >> region_name = RegionOne >> user_domain_id = default >> username = ceilometer >> > > Here is my event_pipeline.yaml: > >> sources: >> - name: meter_file >> events: >> - "*" >> sinks: >> - prometheus >> >> sinks: >> - name: prometheus >> publishers: >> - prometheus://127.0.0.1:9091/metrics/job/ceilometer >> > > Here is my pipeline.yaml: > >> sources: >> - name: meter_file >> interval: 30 >> meters: >> - "*" >> sinks: >> - prometheus >> >> sinks: >> - name: prometheus >> publishers: >> - prometheus://127.0.0.1:9091/metrics/job/ceilometer >> > > Here is my polling.yaml: > >> --- >> sources: >> - name: some_pollsters >> interval: 300 >> meters: >> - cpu >> - cpu_l3_cache >> - memory.usage >> - network.incoming.bytes >> - network.incoming.packets >> - network.outgoing.bytes >> - network.outgoing.packets >> - disk.device.read.bytes >> - disk.device.read.requests >> - disk.device.write.bytes >> - disk.device.write.requests >> - hardware.cpu.util >> - hardware.memory.used >> - hardware.memory.total >> - hardware.memory.buffer >> - hardware.memory.cached >> - hardware.memory.swap.avail >> - hardware.memory.swap.total >> - hardware.system_stats.io.outgoing.blocks >> - hardware.system_stats.io.incoming.blocks >> - hardware.network.ip.incoming.datagrams >> - hardware.network.ip.outgoing.datagrams >> > > Here is my ceilometer-rootwrap: > >> # Configuration for ceilometer-rootwrap >> # This file should be owned by (and only-writeable by) the root user >> >> [DEFAULT] >> # List of directories to load filter definitions from (separated by ','). >> # These directories MUST all be only writeable by root ! >> filters_path=/etc/ceilometer/rootwrap.d,/usr/share/ceilometer/rootwrap >> >> # List of directories to search executables in, in case filters do not >> # explicitely specify a full path (separated by ',') >> # If not specified, defaults to system PATH environment variable. >> # These directories MUST all be only writeable by root ! >> exec_dirs=/sbin,/usr/sbin,/bin,/usr/bin,/usr/local/sbin,/usr/local/bin >> >> # Enable logging to syslog >> # Default value is False >> use_syslog=False >> >> # Which syslog facility to use. >> # Valid values include auth, authpriv, syslog, user0, user1... >> # Default value is 'syslog' >> syslog_log_facility=syslog >> >> # Which messages to log. >> # INFO means log all usage >> # ERROR means only log unsuccessful attempts >> syslog_log_level=ERROR >> > > What configuration is wrong ? > > Le ven. 3 juil. 2020 à 13:53, Matthias Runge <mrunge(a)matthias-runge.de> a > écrit : > >> Okay, that doesn't really help with debugging though. >> >> Method not allowed is returned eg. when the endpoint expected an http >> push where your browser did an http get (that's correct). >> >> What I'd do next is to configure ceilometer to send to a different http >> endpoint (like a webserver on your workstation, just for debugging >> purposes). >> >> Verify that the push gateway works as expected, >> https://github.com/prometheus/pushgateway >> has some curl commands mentioned for debugging purposes. >> >> >> Matthias >> >> On 03/07/2020 13:07, Samuel Mutel wrote: >> > If I go to http://10.60.4.11:9091/metrics/job/ceilometer with the web >> > browser I receive: Method Not Allowed but i think it's normal. >> > http://10.60.4.11:9091/metrics is working with metrics. >> > >> > The pushgateway and the ceilometer is working on the same host for my >> > test so no network/firewall issue. >> > >> > Logs of the pushgateway is only these ones: >> > level=info ts=2020-07-03T11:04:35.907Z caller=main.go:83 msg="starting >> > pushgateway" version="(version=1.2.0, branch=HEAD, >> > revision=b7e0167e9574f4f88404dde9653ee1d3c940f2eb)" >> > level=info ts=2020-07-03T11:04:35.908Z caller=main.go:84 >> > build_context="(go=go1.13.8, user=root@0e823ccfff84, >> > date=20200311-18:51:01)" >> > level=info ts=2020-07-03T11:04:35.911Z caller=main.go:137 >> > listen_address=:9091 >> > >> > Le ven. 3 juil. 2020 à 12:14, Matthias Runge <mrunge(a)matthias-runge.de >> > <mailto:mrunge@matthias-runge.de>> a écrit : >> > >> > On 03/07/2020 11:25, Samuel Mutel wrote: >> > > Hello, >> > > >> > > I have two questions about ceilometer (openstack version rocky). >> > > >> > > * First of all, it seems that ceilometer is sending metrics >> > every hour >> > > and I don't understand why. >> > > * Next, I am not able to setup ceilometer to send metrics to >> > > prometheus pushgateway. >> > > >> > > Here is my configuration: >> > > >> > > sources: >> > > - name: meter_file >> > > interval: 30 >> > > meters: >> > > - "*" >> > > sinks: >> > > - prometheus >> > > >> > > sinks: >> > > - name: prometheus >> > > publishers: >> > > - >> > prometheus://10.60.4.11:9091/metrics/job/ceilometer >> > <http://10.60.4.11:9091/metrics/job/ceilometer> >> > > <http://10.60.4.11:9091/metrics/job/ceilometer> >> > > >> > > >> > > Here is the error I received: >> > > >> > > vcpus{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2 >> > > # TYPE memory gauge >> > > memory{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} >> 2048 >> > > # TYPE disk.ephemeral.size gauge >> > > >> > >> disk.ephemeral.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} >> > > 0 >> > > # TYPE disk.root.size gauge >> > > >> > disk.root.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} >> 0 >> > > : HTTPError: 400 Client Error: Bad Request for url: >> > > http://10.60.4.11:9091/metrics/job/ceilometer >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> > > Traceback (most recent call last): >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> > File >> > > >> "/usr/lib/python2.7/dist-packages/ceilometer/publisher/http.py", >> > > line 178, in _do_post >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> >> > > res.raise_for_status() >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> > File >> > > "/usr/lib/python2.7/dist-packages/requests/models.py", line >> > 935, in >> > > raise_for_status >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> >> > > raise HTTPError(http_error_msg, response=self) >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> > > HTTPError: 400 Client Error: Bad Request for url: >> > > http://10.60.4.11:9091/metrics/job/ceilometer >> > > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http >> > > >> > > >> > > Thanks for your help on this topic. >> > >> > >> > Hi, >> > >> > first obvious question: >> > >> > are you sure that there is something listening under >> > http://10.60.4.11:9091/metrics/job/ceilometer ? >> > >> > Would you have some error logs from the other side? It seems that >> > ceilometer is trying to dispatch as expected. >> > >> > Matthias >> > >> >>

1 0

[neutron] Implementing BGP over network:routed for IPv6 in Neutron, with DVR capabilities
by Thomas Goirand 14 Aug '20

14 Aug '20

Hi, When these patches are approved: https://review.opendev.org/486450 https://review.opendev.org/669395 we will effectively have BGP announcing for floating IPs and router gateways, with a provider network as next BGP HOP. I tested in experimentally, and it does work. There's more work to be done on it to make it better (like, eliminating GARP requests and getting neutron-dynamic-routing to know when a floating moves from one segment to another), as seen in the commends of #669395, but it works. Now, I'd like to have the same feature for IPv6. Having a segmented IPv6 L2 network already works, though isn't this always going through the network nodes still? I see no reason why IPv6 would always go through network nodes, and I would like to eliminate this SPOF. Has anyone worked on this? Or is there anyone with some advice on how to start? Is there some blueprints somewhere? I'm not sure what this implies, and where to start my research on this. But I really would love, moving forward, to have such a feature. Would anyone (try to) contribute this with me? Cheers, Thomas Goirand (zigo)

1 0

[tripleo] Specify different interface name in single nic vlans without external network installation
by Marco Marino 14 Aug '20

14 Aug '20

Hi, I'm trying to install openstack using tripleo on preprovisioned servers. My (desired) environment is quite simple: 1 controller and 1 compute node. Here is what I did: - Installed undercloud with 192.168.25.0/24 as a ctlplan subnet. local_ip = 192.168.25.2; undercloud_public_host=192.168.25.4; undercloud_admin_host = 192.168.25.3 - Installed 2 servers (compute and controller) with centos 8. Hardware requirements are satisfied (32 GB of ram, 100GB disk....) - Manually created user stack on compute and controller and added it to the sudoers list. - Manually Installed openstack repositories (sudo -E tripleo-repos -b ussuri current-tripleo-rdo) - Manually installed openstack required openstack packages: sudo yum install python3-heat-agent* -y Now I'd like to use 192.168.25.0/24 as "installation network" (network used by ansible) and I'm trying to configure one single nic with vlans. Please note that on all servers (undercloud included) I have 2 physical interfaces with the same name: enp1s0 and enp7s0. enp1s0 is used for a completely openstack-detached network: 192.168.2.0/24 and enp7s0 is used for 192.168.25.0/24 More precisely: Controller-0 = 192.168.25.10 Compute-0 = 192.168.25.20 Furthermore, I confirm that I can reach <local_ip> from both nodes using ping and curl (on port 8004). And I added 2 lines in /etc/hosts on undercloud: 192.168.25.10 controller-0 192.168.25.20 compute-0 Now I'm really confused about what to do. I tried with: openstack overcloud deploy --templates --disable-validations -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e templates/network-environment-overrides.yaml -e templates/ctlplane-assignment.yaml -e templates/nameservers.yaml -e templates/node-info.yaml -e templates/hostnamemap.yaml -n templates/network_data.yaml node-info.yaml: http://paste.openstack.org/show/796840/ hostnamemap.yaml: http://paste.openstack.org/show/796841/ network-environment-overrides.yaml: http://paste.openstack.org/show/796842/ ctlplane-assignment.yaml: http://paste.openstack.org/show/796843/ nameservers.yaml: http://paste.openstack.org/show/796844/ network_data.yaml: http://paste.openstack.org/show/796845/ How can I specify nic2 for single nic vlans without external network? Please can you provide an example with "openstack overcloud deploy" complete command? I'm reading documentation but I do not understand how to do and it's really frustrating. Thank you, Marco

1 0

Openstack-Train VCPU issue in Hyper-V
by its-openstack＠zohocorp.com 14 Aug '20

14 Aug '20

Dear Team, We are using Openstack-Train in our organization.We have created windows server 2016 Std R2 instances with this flavor m5.xlarge ( RAM - 65536 , Disk - 500 , VCPUs - 16 ).Once Hyper-V future enabled in this instances VCPU count is automatically reduced to 1 core after restart.Even we have enabled nested virtualisation in openstack compute server.Please help us to short out this issue. #cat /sys/module/kvm_intel/parameters/nested Y Regards, Sysadmin.

2 1

[masakari] Meetings
by Radosław Piliszek 14 Aug '20

14 Aug '20

Hello Fellow cloud-HA-seekers, I wanted to attend Masakari meetings but I found the current schedule unfit. Is there a chance to change the schedule? The day is fine but a shift by +3 hours would be nice. Anyhow, I wanted to discuss [1]. I've already proposed a change implementing it and looking forward to positive reviews. :-) That said, please reply on the change directly, or mail me or catch me on IRC, whichever option sounds best to you. [1] https://blueprints.launchpad.net/masakari/+spec/customisable-ha-enabled-ins… -yoctozepto

2 2

[Ocata][Heat] Strange error returned after stack creation failure -r aw template with id xxx not found
by Laurent Dumont 14 Aug '20

14 Aug '20

Hi! We are currently troubleshooting a Heat stack issue where one of the stack (one of 25 or so) is failing to be created properly (seemingly randomly). The actual error returned by Heat is quite strange and Google has been quite sparse in terms of references. The actual error looks like the following (I've sanitized some of the names): Resource CREATE failed: resources.potato: Resource CREATE failed: resources[0]: raw template with id 22273 not found heat resource-list STACK_NAME_HERE -n 50 > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | resource_name | physical_resource_id | resource_type > | resource_status | updated_time | stack_name > | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | potato | RESOURCE_ID_HERE | OS::Heat::ResourceGroup | > CREATE_FAILED | 2020-07-18 T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | potato_server_group | RESOURCE_ID_HERE | OS::Nova::ServerGroup | > CREATE_COMPLETE | 2020-07-21T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | 0 | | potato1.yaml > | CREATE_FAILED | 2020-07-18T19:52:12Z | nested_stack_2_STACK_NAME_HERE > | > | 1 | | potato1.yaml > | INIT_COMPLETE | 2020-07- 18 T19:52:12Z | > nested_stack_2_STACK_NAME_HERE | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > The template itself is pretty simple and attempts to create a ServerGroup and 2 VMs (as part of the ResourceGroup). My feeling is that one the creation of those machines fails and Heat get's a little cooky and returns an error that might not be the actual root cause. I would have expected the VM to show up in the resource list but I just see the source "yaml". Has anyone seen something similar in the past? Thanks!

2 3

[cinder] driver maintainers: 3rd party CI checkpoint reminder
by Brian Rosmaita 14 Aug '20

14 Aug '20

Hello Cinder driver maintainers, Around the time of the Feature Freeze (10 September), the Cinder team will be looking at the Third Party CIs to assess compliance [0]. Out of compliance drivers will be marked as 'unsupported' in the Victoria release. We can avoid a lot of unpleasantness if you take this opportunity to review the current situation of your driver's CI [1] and, if necessary, take appropriate steps to get it back into compliance before 10 September. cheers, brian [0] https://docs.openstack.org/cinder/latest/drivers-all-about.html#driver-comp… [1] http://cinderstats.ivehearditbothways.com/cireport.txt

1 0

[cinder] driver features declaration for victoria next week
by Brian Rosmaita 14 Aug '20

14 Aug '20

Hello Cinder driver maintainers, This is a reminder that new features added to Cinder drivers for the Victoria release must be merged at the time of the OpenStack-wide Feature Freeze, which is coming up soon (10 September, to be specific). In order to avoid the Festival of Insane Driver Reviewing that we had last cycle, if you have un-merged driver features that you would like to land in Victoria, please post a blueprint in Launchpad listing the Gerrit reviews of the associated patches before the next Cinder weekly meeting (that is, before 19 August at 1400 UTC). This will help the team prioritize reviews and give you candid early feedback on whether the features look ready. You can look among the Ussuri blueprints for examples; contact me in IRC if you have any questions. Due to the 7 September holiday in the USA, there will be reduced reviewing bandwidth right around the Feature Freeze, so that's why I'm asking you to plan ahead. cheers, brian

1 0

[cinder] victoria new feature status checkpoint next week
by Brian Rosmaita 14 Aug '20

14 Aug '20

If you are working on a Cinder feature for Victoria that hasn't merged yet, please add it to the agenda for next week's cinder weekly meeting on 19 August at 1400 UTC: https://etherpad.opendev.org/p/cinder-victoria-meetings If your feature requires client support, keep in mind that the final release for client libraries is in four weeks. Any client changes must be reviewed, tested, and merged before 10 September. Keep in mind that 7 September is a holiday for many Cinder core reviewers, so it is likely that we will have reduced reviewer bandwidth around the time of the Feature Freeze. So please plan ahead. cheers, brian

1 0

[cinder] victoria os-brick release coming soon
by Brian Rosmaita 14 Aug '20

14 Aug '20

Just a quick reminder that the victoria os-brick release is 3 weeks away. Reviews may be a bit slower than usual given that people may be taking some end-of-the-summer vacation, so if you have an important patch for os-brick, please take the initiative to raise awareness in the #openstack-cinder IRC channel if it's not getting the attention it deserves. cheers, brian

1 0